Software engineering interview practice
Published by MockReps.
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.
A worked example: count requests in a rolling window
This is a fictional interview exercise, not a report of a customer session. Assume timestamps arrive in non-decreasing order. At time t, count requests whose timestamps are greater than t − 60 and less than or equal to t. Every request counts, including requests sharing a timestamp. Clarify that boundary with the interviewer before choosing a data structure.
A first answer: “I would store the timestamps in a list and remove old requests.” That gives a direction but leaves ordering, expiry and cost unclear.
A more complete explanation: “For this ordered stream, I would keep a queue of unexpired timestamps. For each new request at time t, remove entries at or before t − 60, append the request and report the queue length. The invariant is that the queue contains exactly the requests inside the window. Each timestamp enters and leaves once; a deque with constant-time operations gives amortised constant work per request. A single request may still trigger many removals.”
Trace timestamps 0, 30, 60 and 60. The counts after each arrival are 1, 2, 2 and 3. At time 60, the request at 0 has expired, while both requests at 60 count separately. This small case tests both the lower boundary and duplicate timestamps.
Challenge the assumptions
- Out-of-order events: A queue ordered by arrival is no longer enough. Ask whether the requirement uses arrival time or event time, and how late events should affect a previously returned answer.
- A quiet interval: If callers can query without sending a request, expire entries at query time too. An old stored count does not become current merely because no new event arrived.
- A traffic spike: Memory grows with the requests in the window. Ask whether the requirement permits approximation before replacing exact timestamps with coarse time buckets.
- Shared state: Multiple workers need an agreed consistency model. An in-memory queue in one process does not provide a global count.
For self-review, keep the declared interval, the trace and one counterexample. A strong next attempt explains which change in requirements would invalidate the chosen approach. The exercise does not require building a distributed service when the original problem only describes a local ordered stream.
For a production-focused conversation, try the DevOps rollout and incident scenarios. They use the same habit: state the boundary, choose evidence and explain what would change your decision.
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.