Software engineering interview practice
Start with the conversation you need to improve. Rehearse one realistic problem, explain your reasoning aloud, then repeat the weakest part with a specific change. A list of memorised answers cannot tell you whether you can clarify an unfamiliar requirement or defend a trade-off.
This is a suggested practice routine, not a description of every employer's process. Confirm the format, timing and permitted tools with your recruiter or interviewer.
Choose a practice focus
| Focus | Try this | Listen for |
|---|---|---|
| Coding and problem solving | Given timestamped requests, count requests in a rolling time window. Clarify ordering, duplicate timestamps and boundary inclusion before coding. | A stated invariant, a correct example and tests that could disprove the solution |
| Technical reasoning | An API becomes slow during peak traffic. Decide which measurements would separate application delay, database delay and a downstream dependency. | Evidence before a fix, a safe experiment and a way to detect regression |
| System design | Design a notification service that must absorb a short traffic spike. | Explicit delivery expectations, capacity assumptions and failure recovery |
| Behavioural | Describe a technical decision you changed your mind about. | Your own contribution, the evidence that changed your view and an honest outcome |
If a topic does not appear in your expected interview, spend that time on the topics that do. Practise at the level of responsibility the role actually requires.
A 35-minute rehearsal
- Five minutes: frame the task. Restate the problem. Write down two questions whose answers could change your approach. Declare any assumptions you must make.
- Fifteen minutes: work through one solution. Explain decisions as you make them. For code, trace a small example before optimising. For design, follow one request through storage and processing. For a career story, distinguish your actions from the team's.
- Five minutes: challenge it. Change a constraint, add a failure or ask what you would do differently. Avoid restarting with an unrelated rehearsed answer.
- Five minutes: review. Identify one claim you supported well and one you could not defend. Use the checklist below.
- Five minutes: repeat the weak section. Make one concrete improvement. Keep the original constraints so you can compare the reasoning.
These timings are an adaptable exercise, not a recommended duration for every real interview. If you only have ten minutes, frame one question, answer it and review one weakness.
Review an attempt without inventing a score
| Question | Evidence to keep | Next rehearsal if missing |
|---|---|---|
| Did I establish what success means? | Requirements, boundaries and stated assumptions | Ask two clarifying questions before proposing a solution |
| Can I explain why the approach works? | An invariant, a request trace or a concrete example | Walk through a small case one step at a time |
| Did I test the uncomfortable case? | An empty input, concurrent update, failed dependency or counterexample | Choose one failure and explain detection and recovery |
| Did I justify a trade-off? | An alternative and the constraint that ruled it out | Explain what change would make the alternative preferable |
| Was my contribution clear? | Specific actions and an outcome you can substantiate | Replace vague “we” statements with an accurate account of your responsibility |
Use “clear”, “partial” or “missing” as notes for yourself. This worksheet is not an employer grading standard or a prediction of an offer.
Build the next session from the evidence
If the answer was technically sound but difficult to follow, practise its structure rather than adding more facts. If a design failed under retries, work through that failure before drawing a larger architecture. If you cannot remember the outcome of a career story, find your original notes; do not invent a metric.
Continue with the notification-service system-design exercise or behavioural interview practice. You can also use nine sample questions without an account.
MockReps offers role-specific text or voice sessions, a Story Bank and technical workspaces. AI feedback can help identify a next step, but can be wrong. See the tools, how feedback works and one-off pack pricing before choosing paid practice.