Technical Interview Preparation Guide

Technical interviews test problem-solving process as much as they test knowledge. Companies want to hire engineers who think clearly, communicate their reasoning, and handle ambiguity — not just engineers who memorised algorithm patterns. This distinction is the key to performing well, and understanding it changes how you prepare.

Part 1: Algorithmic and Coding Interviews

Coding rounds typically run 45–60 minutes, present 1–2 problems, and are evaluated on correctness, efficiency, and communication. Preparation time determines your scope: you cannot cover everything, but you can cover the highest-frequency patterns.

The Preparation Timeline

• 4+ weeks: Cover all major data structures and algorithm topics systematically. Work through the Blind 75, then expand to NeetCode 150.
• 2 weeks: Focus on the highest-frequency patterns: arrays, hash maps, two pointers, binary search, trees, and basic graphs.
• Less than a week: Focus entirely on the 10 most common patterns and make sure you can communicate your approach clearly, even on problems you cannot fully solve.

The Core Topics (Priority Order)

1. 1Arrays and strings — appears in approximately 40% of coding rounds
2. 2Hash maps and sets — the most commonly useful data structure
3. 3Two pointers and sliding window
4. 4Binary search
5. 5Linked lists
6. 6Trees and graphs (DFS/BFS)
7. 7Dynamic programming (medium-level)
8. 8Stacks and queues
9. 9Sorting and searching
10. 10Recursion and backtracking

The 4-Step Problem-Solving Framework

Use this on every single coding problem, regardless of difficulty.

1. 1Clarify — Repeat the problem back in your own words and ask about edge cases, constraints, and input size. Never start coding before you have confirmed your understanding. "Can the input array be empty? Can values be negative?"
2. 2Plan — Talk through your intended approach before writing a line of code. Mention the time and space complexity of your approach. "I'm thinking of a hash map approach that would give me O(n) time and O(n) space — does that direction make sense to you?"
3. 3Code — Write clean, readable code. Name variables descriptively. Talk through what you are doing as you write. If you deviate from your plan, say why.
4. 4Test — Walk through your solution with 2–3 test cases, including at least one edge case. "Let me trace through this with an empty array to verify my boundary conditions..."

Part 2: System Design Interviews

System design rounds test your ability to design scalable, reliable, and maintainable systems given a deliberately vague prompt. They are typically required for mid-to-senior level roles (3+ years of experience). The question is always vague: "Design Twitter" or "Design a URL shortener." That ambiguity is intentional — your first job is to define the problem.

The RESHADED Framework

Use this structured approach to navigate any system design question without losing your thread.

• Requirements — clarify functional requirements (what must the system do?) and non-functional requirements (how must it perform? availability, consistency, latency?)
• Estimations — rough traffic, storage, and bandwidth calculations. Order-of-magnitude thinking: "100M requests/day = ~1,200/second. Read-to-write ratio of 100:1."
• Storage schema — data models and database choices. When would you choose PostgreSQL vs. Cassandra vs. DynamoDB?
• High-level design — draw the core components and their interactions
• API design — define the key endpoints, request/response shapes
• Detailed design — deep-dive on the two or three most critical or interesting components
• Edge cases — failure modes, bottlenecks, tradeoffs you are explicitly accepting
• Discussion — defend your design choices and acknowledge the alternatives you considered

What Interviewers Are Evaluating in System Design

• Do you clarify scope and constraints before diving into a solution?
• Can you estimate order-of-magnitude numbers without a calculator?
• Do you know when to use SQL versus NoSQL, and can you justify the choice?
• Can you articulate tradeoffs clearly — consistency versus availability, latency versus throughput, build versus buy?
• Do you proactively identify failure modes and bottlenecks?

Part 3: Role-Specific Technical Preparation

Software Engineering (SWE)

Allocate approximately 60% of your preparation time to data structures and algorithms. The remaining 40% should cover system design (especially for senior roles), language-specific questions (Python gotchas, Java concurrency, etc.), and at least one full mock behavioural interview. Know Big-O notation cold — interviewers expect you to state it without being asked.

Data Science and Machine Learning Engineering

Expect SQL queries (window functions, joins, aggregations), statistics questions (probability, distributions, hypothesis testing, A/B test design), machine learning concepts (bias-variance tradeoff, overfitting, regularisation, feature engineering), and frequently a take-home case study. Less LeetCode; more applied thinking about real business problems.

DevOps, Platform, and SRE

Expect infrastructure design scenarios, Linux fundamentals, networking (DNS resolution, TCP/IP, load balancers, CDNs), CI/CD pipeline architecture, on-call incident response scenarios, and post-mortem frameworks. System design rounds in this space often focus on reliability, observability, and graceful degradation rather than pure scale.

FAANG-Style vs. Startup Technical Interviews

The format, expectations, and preparation strategy differ significantly between large structured companies and earlier-stage startups. Knowing which you are walking into changes how you prepare.

The Behavioural Loop in Technical Interviews

Most technical interview loops include at least one behavioural round, even for pure engineering roles. Use the STAR framework — Situation, Task, Action, Result — for all behavioural questions. The STAR structure (which you can build for each question using the STAR Method Masterclass) ensures your answers are specific, personal, and outcome-focused. This matters even in a technical context: companies are hiring whole people, not just coding machines.

Communicating When You Are Stuck

Getting stuck is expected and factored into the interviewer's assessment. How you handle it is what they are actually measuring. Candidates who panic, go silent, or give up are easy to reject. Candidates who stay calm, think methodically, and communicate clearly while stuck often receive positive signals even without solving the problem.

1. 1State what you know: "I know I need to track something as I iterate — that suggests a hash map or a set. I'm not yet sure which."
2. 2Ask for a nudge explicitly: "I'm not immediately seeing the optimal substructure here — can you give me a hint in the right direction?"
3. 3Move to brute force: "Let me code the O(n²) solution first to confirm my understanding, and then we can work backward to optimise."

Before your technical loop, also review the Complete Interview Prep Guide for the non-technical preparation — story preparation, question strategy, logistics — that most engineers skip and then regret.

Take-Home Assignments vs. Live Coding Rounds

Technical interviews increasingly take two distinct forms: asynchronous take-home assignments and synchronous live coding. Each has different dynamics, and conflating them as the same type of challenge leads to under-performing in both.

Take-Home Assignments

Take-home assignments give you time and a private environment — which means the bar for code quality is significantly higher than in a live session. The interviewer will review your work with the assumption that you had full access to documentation, Stack Overflow, and all the time you needed. Untidy code, missing edge cases, or absent tests are harder to excuse in a take-home.

• Treat the brief as a real engineering problem, not a puzzle. Read it multiple times. Identify what is explicitly required and what is implicitly expected (tests, documentation, error handling).
• Submit code you are genuinely proud of. This is a portfolio piece. Structure, naming, and clarity matter as much as correctness.
• Write a short README. Explain your approach, the tradeoffs you made, and what you would improve with more time. This demonstrates engineering maturity — the ability to reason about your own work.
• Time-box it. Most take-homes come with a suggested time estimate. Exceeding it significantly can actually work against you — it may signal you struggle to scope your work.

Live Coding Rounds

Live coding under observation is a genuinely different skill from coding alone. The primary difference is that communication becomes a first-order requirement — silence is your biggest enemy.

Data Science and ML Interview Specifics

Data science and machine learning interviews have a distinct profile from software engineering interviews. Knowing the difference prevents over-preparing on the wrong material.

The DS/ML Interview Stack

• SQL — Nearly universal. Expect window functions (RANK, LAG, LEAD), GROUP BY with HAVING, self-joins, and subqueries. Practice on real schemas, not toy tables.
• Statistics and probability — Expect questions on A/B test design, confidence intervals, p-values, the difference between Bayesian and frequentist approaches, and common distributions. These are often asked verbally, not in code.
• Machine learning fundamentals — Bias-variance tradeoff, regularisation (L1 vs L2), overfitting and how to detect it, feature importance, cross-validation strategies, evaluation metrics beyond accuracy (precision, recall, F1, AUC).
• Coding — Usually Python, typically data manipulation (pandas, numpy) rather than pure algorithms. Some roles include a coding test at the difficulty level of LeetCode Easy-to-Medium.
• Business case study — Many DS interviews include an open-ended business problem: "How would you measure success for this new feature?" or "We see a 15% drop in conversion — how would you investigate?" Structure your answer before diving in.

Mock Interview Resources and Platforms

Deliberate practice through structured mock interviews is the fastest route to technical interview improvement. The best resources by format:

• LeetCode — The industry standard for coding problems. Filter by company tags for targeted preparation. Premium membership unlocks company-specific question sets.
• NeetCode — Free structured curriculum with 150 curated problems organised by pattern. Includes video solutions with clear explanations. Widely regarded as the most efficient LeetCode supplement.
• Interviewing.io — Anonymous mock technical interviews with engineers from top companies. Provides feedback after each session. One of the highest-quality live practice resources available.
• Pramp — Free peer-to-peer mock interviews. You both interview and are interviewed — the dual role builds both skills simultaneously.
• DesignGurus / Grokking — System design courses structured around common patterns. More digestible than raw system design books for most preparation timelines.

When Things Go Wrong Mid-Interview

Every technical interviewer has watched candidates freeze, write buggy code, or realise halfway through a problem that they misunderstood the requirements. How you respond in those moments is as important — sometimes more important — than the quality of your solution.

Freezing on a Problem

Freezing usually happens when you are trying to generate the full solution in your head before saying anything. The fix is to start talking immediately, even if you have nothing useful yet: "Let me think through the constraints here. The input is an unsorted array of integers. The brute force approach would be a nested loop at O(n²), which is probably too slow. I am thinking about whether there is a hash map-based approach that could get this to O(n)..." Narrating your search process is not weakness — it is the interview.

Discovering a Bug Mid-Solution

Realising You Misunderstood the Requirements

This happens to nearly every candidate at least once. The recovery script is: stop, acknowledge it briefly, restate your new understanding, and ask if you are now aligned before continuing. "Wait — I think I have been solving for the wrong case. I was assuming the list is sorted, but I do not think that is guaranteed. Let me restate what I think the problem is and check: [restate]. Is that right?" Pausing to correct is far better than continuing in the wrong direction for five more minutes.