Pass a Senior Engineering Interview

Proof required

Submit: a document or repository listing 50 solved problems with the problem name, your solution code, and a 2–3 sentence complexity analysis for each; and a 200-word reflection naming the category that was hardest and why, and one pattern you now recognise automatically that you did not before.

What gets checked

• 50 problems are listed with real solution code — not links to accepted submissions, not pseudocode, but actual runnable code
• Complexity analysis is present for each: O(n) or O(n log n) with a brief explanation of why, not just a label
• Reflection names a specific pattern (e.g. sliding window, two pointers, DFS template) and explains how recognising it now changes how the submitter approaches a new problem

Common mistakes

• Solving easy problems only to hit the count quickly — the distribution should include at least 15 medium-difficulty problems
• Looking at the solution before attempting the problem seriously — the complexity analysis will be hollow if the understanding was not earned
• Treating this as a memorisation exercise — the goal is pattern recognition, which only develops from deliberate practice with time limits and self-explanation

Resources

What a verifier looks for

• Pick a random problem from the list and ask the submitter to explain the complexity analysis from memory — they should be able to without looking at the document
• Ask what the hardest category was and what changed about how they approach it now — a specific answer shows genuine pattern learning
• Ask what the most important pattern they learned was — a vague answer ('I got better at DP') is weaker than a specific one ('I now recognise which DP problems need a 2D table')
• Count the medium-difficulty problems in the list — fewer than 15 suggests the submitter avoided the problems that drive the most skill development

You'll sign in first, then come straight back here.

Proof required

Submit: the video recording (unlisted YouTube or a file share link) showing you building the diagram live while explaining your reasoning; the final diagram exported as an image; and a 200-word self-assessment naming your weakest section in the session and what you would do differently.

What gets checked

• Diagram is built live during the recording — a pre-made diagram presented in a monologue is not a system design interview
• Trade-off discussion is present: at least one point where you explicitly choose between two approaches and explain why (e.g. SQL vs. NoSQL, consistent vs. available, push vs. pull)
• Self-assessment names a specific weak section with a reason: 'my capacity estimation was off because I forgot to account for replication factor' is specific; 'I need to improve' is not

Common mistakes

• Jumping to the solution without clarifying requirements — a senior interview expects you to ask questions before drawing anything
• Designing in component boxes without explaining how data flows between them — the evaluator needs to understand the data model and the read/write paths
• Recording the first attempt without practice — the recording should be your best effort after at least 3–4 practice runs on other problems

Resources

What a verifier looks for

• Watch 15 minutes of the recording — does the submitter clarify requirements before drawing? Do they reason about trade-offs explicitly?
• Ask about a trade-off in the diagram: why did they choose that database, that caching layer, or that queue? A good answer names the alternative considered
• Ask what the weakest part of the session was and why — their self-assessment should match what you observed in the recording
• Ask what they would estimate differently now — capacity estimation is the part most candidates underestimate in M2

You'll sign in first, then come straight back here.

Proof required

Submit one of: an offer letter (company name and date, redact salary); a recruiter confirmation email showing you completed the interview loop with a summary of feedback; or a written assessment from an internal principal/staff engineer who conducted a structured interview panel and provided a hire/no-hire verdict with reasons.

What gets checked

• Evidence is from a real company or a real internal senior engineer — a mock interview service or a peer practice partner does not qualify for M3
• If not an offer: feedback is specific enough to act on — 'we went with someone stronger' without reasons does not count; the feedback must name what was missing
• If internal: the assessor's seniority is stated (principal or staff+ title) and the assessment covers both algorithmic and system design ability

Common mistakes

• Applying only to companies where you have an inside connection and the interview is not rigorous — the evidence of hiring-bar calibration comes from the company's standard process
• Receiving an offer and not documenting it — the offer letter is the cleanest proof and should be kept
• Treating a recruiter screen as the interview loop — M3 requires technical rounds with engineers, not a phone conversation about experience

Resources

What a verifier looks for

• Verify the offer letter or recruiter email is real: check for a company domain in the email address and a plausible interview timeline
• If internal: confirm the assessor's title shows principal engineer or above and that the assessment covers technical substance, not just cultural fit
• Ask what the hardest question in the loop was — a specific answer about a real question (with the problem statement recalled) confirms the experience was real
• Ask what they would prepare differently if they did the loop again — specific answer shows genuine learning from the experience

You'll sign in first, then come straight back here.