Learn before you mock
How technical interviews actually work
The shape of an EngMock session
Before the interview
You choose the scenario, target level, duration, and — for coding tracks — the language, editor mode, and validation mode. These settings change the bar the interviewer holds you to, so pick the level you are actually interviewing for.
The interview
A voice interviewer runs a timed session with a track-specific workspace. It asks one focused question at a time, follows your whiteboard or editor state, and adapts follow-ups to what you have actually demonstrated.
After the interview
You receive an evidence-based report scored against the scenario rubric and your target level, plus a replay of the session. The report cites what you said and did rather than giving a generic score.
What the interviewer does — and does not do
The interviewer behaves like a real engineer conducting a real loop. Knowing its boundaries stops you from waiting for help that will never come.
It will
- Ask one focused question at a time and let you drive the solution.
- Probe your assumptions, trade-offs, and edge cases with follow-ups.
- Give progressively stronger hints only after you are genuinely stuck.
- Nudge you on pacing if you spend too long in one part of the interview.
- Stay silent while you are thinking, coding, testing, or drawing.
It will not
- Teach you the underlying concepts — this is a mock, not a lesson.
- Provide finished pseudocode, exact code, or a canonical solution.
- Draw your architecture unless you explicitly ask and confirm.
- Treat AI-assistant output as your own achievement.
- Summarize your performance out loud; that belongs in the report.
What each level is graded against
The target level you pick before the session changes the depth expected, the difficulty of follow-ups, and the final recommendation. Everyone is not silently graded against Senior.
A correct, coherent basic solution with understandable decisions and clear communication.
Independence: Bounded interviewer prompts are acceptable and do not disqualify you.
An independently produced working solution with edge cases, basic estimation or complexity, and one meaningful deep dive.
Independence: You should need few prompts and recover from them quickly.
Independent framing, explicit assumptions, production-ready design or robust code, multiple deep dives, and well-defended trade-offs.
Independence: You are expected to drive the session with minimal interviewer steering.
Ambiguity resolution plus cross-cutting reasoning: multi-region reliability, cost, migrations, operability, organizational boundaries, and long-term platform trade-offs.
Independence: You set the agenda; follow-ups are deliberately harder and more open-ended.
Six habits that separate strong candidates
These apply to every track. Most failed interviews are lost here, not on missing knowledge.
Clarify before you solve
Spend the first minutes agreeing on scope, users, and constraints. Interviewers consistently score requirement discipline higher than early technical detail.
State assumptions out loud
An explicit wrong assumption is recoverable; a hidden one looks like a gap. Say what you are assuming and why, then move on.
Think aloud, but structure it
Narrate decisions, not keystrokes. "I am choosing X over Y because Z" is signal. Silence during a long implementation is a missed opportunity.
Defend trade-offs, do not just list them
Naming two options is a Mid-level answer. Choosing one, explaining the cost you accept, and stating when you would switch is a Senior answer.
Validate your own work
Do not wait to be asked. Run your code, walk a concrete example, or test your design against a failure. Self-validation is one of the strongest seniority signals.
Manage the clock
Leave room for the parts that carry the most signal — deep dives in System Design, validation and complexity in coding. Perfecting an early section at the cost of the last one lowers your score.
The System Design timeline is enforced
System Design sessions move through six phases in order. The interviewer will not skip or go backwards, and it will nudge you if a phase overruns. Here is roughly how a 45-minute session is allocated.
| Phase | Share | ~45 min | Goal |
|---|---|---|---|
| Functional Requirements | 8% | 4 min | Agree on the core user flows the system must support, in your own words. |
| Non-Functional Requirements | 10% | 5 min | Turn quality attributes into numbers you will design against. |
| Back-of-the-envelope Estimation | 10% | 5 min | Size the system enough to justify later storage, cache, and partitioning decisions. |
| API & Data Model | 12% | 5 min | Define the contract and the data before the boxes and arrows. |
| High-Level Design | 25% | 11 min | Draw an end-to-end architecture where every component exists for a stated reason. |
| Deep Dives, Reliability & Trade-offs | 35% | 16 min | Go deep on the parts that carry the real risk, and show you understand failure. |
Coding, OOD, and AI-assisted coding sessions are not phase-gated in the same way, but each follows a realistic flow described in its guide.
Track guides
Each guide covers the flow, what strong and weak answers look like at every step, the bar for your level, and a short readiness checklist.
System Design
A timed, six-phase conversation where you own the architecture and defend every trade-off.
Read the guide →Coding / DSA
Not just a correct solution — a stated approach, clean implementation, real validation, and honest complexity.
Read the guide →OOD
Modeling responsibilities and boundaries in a real multi-file workspace — not reciting design patterns.
Read the guide →AI-Assisted Coding
The AI writes code. You own the decisions, the review, the verification, and the explanation.
Read the guide →Ready to be interviewed?
Pick a scenario, set your target level, and treat it like the real thing. Your report cites evidence from your session, so the closer you play it to a real loop, the more useful it is.
Browse scenarios