How MockReps feedback works
Use feedback to choose what to practise next, then check it against your answer. MockReps uses AI to assess interview answers and guided technical work. The feedback can be incomplete or wrong; its scores do not measure your worth, certify your skills or predict an employer's decision.
Interview answers
Answer feedback considers technical or domain accuracy, depth of knowledge, clarity and completeness. Communication guidance also looks at structure, concision, supporting evidence and handling follow-up questions. A question rubric describes expected points, and the assessment can combine model judgement, rubric coverage and semantic similarity.
Similarity is not proof of correctness. Mentioning a topic or using the expected keywords does not establish that an explanation is safe or accurate. Role context, question difficulty and the question itself affect the assessment, so scores from different sessions are not a controlled ranking of candidates.
For personal or behavioural answers, suggested improvements are intended to preserve the experience and facts you supplied. Check every rewrite. If an action, metric or outcome is unsupported, remove it or supply the missing fact yourself; do not adopt an invented achievement.
Guided technical workspaces
System-design reviews use these dimensions:
- Requirements and scope.
- Architecture and data flow.
- Trade-offs.
- Reliability and operations.
- Interview closure: how you summarise and identify the next questions.
Technical-practice reviews use problem framing, solution quality, testing and edge cases, review discipline, and explanation and trade-offs. These reviews assess the submitted work; they are not a guarantee that a design will operate correctly or that a solution is production-ready. Validate important technical claims independently.
A fictional feedback walkthrough
This is an editorial example of useful reflection, not an actual model response, customer result or numeric score.
Question: How would you handle duplicate notification jobs?
Sample answer: “I would put jobs on a queue. A worker sends the email and then marks the job complete.”
What is present: There is a basic asynchronous flow, and the answer identifies where delivery happens.
What needs work: It does not address a worker crashing after the provider accepts the email but before the completion record is saved. A redelivered job could send another email.
A useful next step: Explain the delivery guarantee and whether the provider accepts a stable idempotency key. If it does not, describe the remaining duplicate risk rather than promising exactly-once delivery. Then trace the timeout and retry path.
How to use this: Revise that part of the explanation and challenge it with a different failure. Do not add services merely to make the answer longer. The system-design exercise works through this scenario in more detail.
Review with care
Check whether the feedback quotes or summarises what you actually said, addresses the question and recommends a change you can explain. Disagree where you have evidence, verify uncertain claims and ask a trusted person to review consequential preparation decisions. A more fluent answer is not necessarily a more accurate one.
Share only the context needed for practice. Remove confidential information from job descriptions and career examples where possible. An original uploaded CV is temporary; the product is designed to delete it after processing and retain a minimised career profile for practice. See the privacy notice for details and contact support to report a problem without sending passwords or confidential answers.
Explore the product, free practice questions or public help.