Practise this next
Specificity
Average 1.0 / 4
Practise Specificity: Name the system, the number and the constraint. One concrete detail beats three adjectives.
A practice session, start to finish
This is a sample session with answers written for the demo. The candidate is fictional. No language model was called to show this page.
Session report
21 Oct 2026 · Full-stack, Mid-level · Behavioral, Technical concepts, System design lite · 3/3 answered · Seed 5a3c0e11
Summary
Your strongest area was Ownership; focus next on Specificity.
You have completed a practice session and have a baseline for your next attempt. Use the focus areas below to make your next answers more concrete.
- Average
- 2.6 / 4
- Answered
- 3 / 3
- Retries
- 0
Also worth a session
Impact
Average 1.0 / 4
Practise Impact: End with a result you can measure or check, and what changed because of it.
Every answer at a glance
Best attempt shown · darker is better
| Question | Structure | Specificity | Ownership | Impact | Relevance | Clarity | Tries |
|---|---|---|---|---|---|---|---|
| Describe documentation you wrote because an operational task was going wrong. What made it useful in practice? | 3 | 1 | 4 | 1 | 4 | 4 | 1 |
| Two models behave differently on the same product task. How would you choose between them without relying on a general benchmark? | 1 | 1 | 4 | 1 | 4 | 4 | 1 |
| Design a personal bookmark library with tags and search. What would the smallest useful implementation look like? | 1 | 1 | 4 | 1 | 4 | 4 | 1 |
Delivery
Total words 577 · Average pace 147 words per minute · Filler words 1 · Longest pause 4.0 s
Next practice
Run another session with the same question types and aim to improve Specificity.
Answers
Question 1: Describe documentation you wrote because an operational task was going wrong. Wh… · 2.8 / 4 · 1 try
Feedback on question 1Sample feedback
Your answer is assessed for concrete numbers.
Overall 2.8 / 4
Change one thing · Specificity
Your answer is assessed for concrete numbers.
This older feedback has no targeted rewrite. Use the guidance above and try again.
Your answer, marked up
- Strong detail
- Vague
- Filler
Our small team was repeatedly restoring the wrong version of a background worker during incidents. The deployment dashboard showed several similar build names, and the existing instructions assumed that everyone remembered which queue each worker served. During one incident I watched an experienced colleague follow the page correctly and still restart the wrong service. I treated that as a documentation problem rather than an individual mistake. I owned the replacement runbook and first walked through the task with someone who had never performed it. I wrote down the decisions they had to make, added a short check of the queue name before any command, and included the expected output after each step. I separated diagnosis from recovery and added a clear stop point when the observed output did not match. I also put the rollback command beside the deployment command so it was available under pressure. Before publishing, I tested the instructions in a staging environment and asked two teammates to complete the exercise without my help. Their questions showed that one screenshot concealed an important environment label, so I replaced it with a text example. Over the next six weeks, the median recovery exercise fell from eighteen minutes to seven, and nobody selected the wrong worker. The useful part was not the length of the document. It was that each action had a visible check and a safe next step.
The dashed parts are where the score dropped. Replace them with what you actually changed and what happened next.
They’ll probably ask next
What would you do differently next time?
Why these scores
- Structure: 3 / 4
Your answer is assessed for context, action and result markers.
- Specificity: 1 / 4
Your answer is assessed for concrete numbers.
- Ownership: 4 / 4
Your answer is assessed for personal and team contributions.
- Impact: 1 / 4
Your answer is assessed for results and their measurement.
- Relevance: 4 / 4
Your answer is assessed for overlap with the question.
- Clarity: 4 / 4
Your answer is assessed for length and sentence structure.
What worked
- You described a concrete situation.
Our small team was repeatedly restoring the wrong
What to improve
- Quantify the result.
A number makes the impact easy to remember.
Try saying:
As a result, [metric] went from [before] to [after].
Outline of a strong answer
- Set the scene and explain your responsibility.
- Describe the actions you took and why.
- Close with the result and what you learnt.
What interviewers listen for
- Names a recurring task and a concrete failure mode
- Describes actionable instructions tested by another person
- Explains ownership or a trigger for updating the document
How this was scored
Scored by mock · rubric feedback-v1 · 0.3 s
One language-model call with a fixed six-part rubric, checked against your transcript. Delivery numbers are counted in your browser.
Scores are a coaching aid from a language model, not a prediction of how an interviewer will judge you.
Question 2: Two models behave differently on the same product task. How would you choose bet… · 2.5 / 4 · 1 try
Feedback on question 2Sample feedback
Your answer is assessed for context, action and result markers.
Overall 2.5 / 4
Change one thing · Structure
Your answer is assessed for context, action and result markers.
This older feedback has no targeted rewrite. Use the guidance above and try again.
Your answer, marked up
- Strong detail
- Vague
- Filler
I would start with examples of the actual product task rather than a general leaderboard. For a support drafting feature, I would collect a set of fictional messages covering common requests, missing information and cases where the model should decline to guess. I would run both models with the same instructions and compare the drafts against a short checklist. The checklist would include whether the answer addresses the request, whether it invents facts and whether a person could use it with a small edit. I would also measure response time and the cost per draft, because a slightly better answer might not justify a much slower experience. I would ask another person to review some outputs without knowing which model produced them. Then I would choose the model that fits the product requirements and test it on more examples. I have not yet decided how many examples would be enough or what difference would count as meaningful. I would probably begin with the cheaper model if the results looked similar, while keeping the option to change it later.
The dashed parts are where the score dropped. Replace them with what you actually changed and what happened next.
They’ll probably ask next
What would you do differently next time?
Why these scores
- Structure: 1 / 4
Your answer is assessed for context, action and result markers.
- Specificity: 1 / 4
Your answer is assessed for concrete numbers.
- Ownership: 4 / 4
Your answer is assessed for personal and team contributions.
- Impact: 1 / 4
Your answer is assessed for results and their measurement.
- Relevance: 4 / 4
Your answer is assessed for overlap with the question.
- Clarity: 4 / 4
Your answer is assessed for length and sentence structure.
What worked
- You described a concrete situation.
I would start with examples of the actual
What to improve
- Quantify the result.
A number makes the impact easy to remember.
Try saying:
As a result, [metric] went from [before] to [after].
Outline of a strong answer
- Define the concept and explain how it works.
- Give a concrete example of when to use it.
- Discuss trade-offs and limitations.
What interviewers listen for
- Uses representative task-specific evaluation with consistent criteria
- Compares quality, latency and cost under realistic conditions
- Documents decision limits and a repeatable regression process
How this was scored
Scored by mock · rubric feedback-v1 · 0.3 s
One language-model call with a fixed six-part rubric, checked against your transcript. Delivery numbers are counted in your browser.
Scores are a coaching aid from a language model, not a prediction of how an interviewer will judge you.
Question 3: Design a personal bookmark library with tags and search. What would the smallest… · 2.5 / 4 · 1 try
Feedback on question 3Sample feedback
Your answer is assessed for context, action and result markers.
Overall 2.5 / 4
Change one thing · Structure
Your answer is assessed for context, action and result markers.
This older feedback has no targeted rewrite. Use the guidance above and try again.
Your answer, marked up
- Strong detail
- Vague
- Filler
I would make a page where you can paste a link and give it a title. There would be a list of the links and a box at the top for searching them. Tags would be useful because people could group their bookmarks by topic. I think a relational database would work, although I would need to look into exactly how the tables should be arranged. The interface should be simple and show the most recent bookmarks first. You could click a tag to see matching links, and perhaps change the title after saving. For search, I would initially try matching the text that the user typed against the title. There are probably issues with duplicate links and links that stop working, but I would leave those until later. I would also want the app to work on a phone. I have not thought through signing in, keeping different users separate or what should happen if a save request fails. Those details would need more design before implementation.
The dashed parts are where the score dropped. Replace them with what you actually changed and what happened next.
They’ll probably ask next
What would you do differently next time?
Why these scores
- Structure: 1 / 4
Your answer is assessed for context, action and result markers.
- Specificity: 1 / 4
Your answer is assessed for concrete numbers.
- Ownership: 4 / 4
Your answer is assessed for personal and team contributions.
- Impact: 1 / 4
Your answer is assessed for results and their measurement.
- Relevance: 4 / 4
Your answer is assessed for overlap with the question.
- Clarity: 4 / 4
Your answer is assessed for length and sentence structure.
What worked
- You described a concrete situation.
I would make a page where you can
What to improve
- Quantify the result.
A number makes the impact easy to remember.
Try saying:
As a result, [metric] went from [before] to [after].
Outline of a strong answer
- Clarify requirements and expected scale.
- Describe components and the flow of data.
- Discuss trade-offs and failure modes.
What interviewers listen for
- Defines bookmarks and tags without unnecessary complexity
- Explains create, edit, search and delete flows
- Handles duplicate input and unavailable destinations
How this was scored
Scored by mock · rubric feedback-v1 · 0.4 s
One language-model call with a fixed six-part rubric, checked against your transcript. Delivery numbers are counted in your browser.
Scores are a coaching aid from a language model, not a prediction of how an interviewer will judge you.