Technical interviews test more than your ability to write code — they test how you think, communicate under pressure, and recover when you're stuck. Most candidates fail not because they can't solve the problems, but because they didn't know what format to expect or what interviewers are actually scoring.
Here's what this guide covers:
- The four types of technical interviews and what each one tests
- The most common coding patterns (arrays, hash maps, recursion, BFS/DFS)
- Behavioral questions that show up in tech rounds
- How to prepare efficiently without grinding 500 LeetCode problems
- What to do when you genuinely don't know the answer
The Four Types of Technical Interviews
Not all technical rounds are the same. Knowing which format you're walking into changes how you prepare.
Coding / Algorithmic Rounds
This is the format most people picture when they hear "technical interview." You're given a problem, usually on a shared coding environment or whiteboard, and asked to solve it within 30–45 minutes.
The interviewer watches your entire process — not just the final solution. They want to see you break the problem down, identify edge cases, and write clean, working code. Algorithms are the foundation here: sorting, searching, graph traversal, and dynamic programming all appear regularly.
What to expect:
- One or two problems per session (easy + medium, or two mediums)
- Live coding in a shared editor (CoderPad, HackerRank, or similar)
- Time complexity discussion after you solve it
System Design Rounds
System design interviews ask you to architect a large-scale system from scratch — think "design Twitter's feed" or "design a URL shortener." These typically happen at mid-to-senior levels.
You're evaluated on breadth: can you reason about data structures, databases, caching, load balancing, and trade-offs without someone walking you through it? There's no single correct answer — the interviewer is looking for structured thinking and the ability to justify your choices.
If you're preparing for this format, see our deeper breakdown in the system design interview questions guide.
Take-Home Assignments
A company sends you a project to complete in 24–72 hours. These are common at startups or for roles that emphasize practical output over puzzle-solving ability.
Take-homes are less stressful in the moment, but they're a time commitment. Treat them like production code: clean structure, error handling, a README, and working tests. Reviewers often look harder at code quality here than in a live session.
Technical Phone Screen
Usually the first filter before an on-site. A recruiter or engineer asks 3–5 conceptual questions to confirm you're not misrepresenting your background. Typical questions: explain REST vs. GraphQL, how does a hash map work, what's the difference between a process and a thread.
These are quick — 20 to 30 minutes — and mostly vocabulary. Brush up on definitions and be ready to explain concepts out loud without code.
Common Coding Patterns You'll Actually See
Most coding problems aren't original. They map to a small set of patterns. Learn the pattern, and you can apply it to dozens of different questions.
Arrays and Strings
The most common category. Problems involve searching, reversing, rotating, or transforming a sequence. Two-pointer and sliding window techniques solve the majority of these.
Two-pointer example: given a sorted array, find two numbers that sum to a target. Start one pointer at each end and move them inward based on whether the current sum is too high or too low. O(n) time, O(1) space.
Sliding window example: longest substring without repeating characters. Expand the window right, and shrink from the left when a duplicate appears.
Hash Maps
Hash maps trade space for speed. Whenever a brute-force solution iterates twice — once to build context, once to query it — a hash map can often flatten that to a single pass.
Classic problem: two-sum. Instead of checking every pair, store each value you've seen and look up whether the complement exists in one pass. O(n) time.
Hash maps also solve frequency counts, anagram detection, and "first non-repeating character" problems. If you're unsure how they work under the hood, hash tables are worth a quick read.
Recursion and Dynamic Programming
Recursion) breaks a problem into a base case and a recursive step. Dynamic programming (DP) is recursion with memoization — you store subproblem results so you don't recompute them.
Common DP problems: fibonacci, coin change, climbing stairs, longest common subsequence. The key habit: define the subproblem clearly before you write any code.
BFS and DFS
Graph traversal problems — trees, grids, connected components — almost always use either breadth-first search (BFS) or depth-first search (DFS).
- BFS (queue-based): best for shortest-path problems or level-order traversal
- DFS (stack or recursion): best for exploring all paths, cycle detection, or backtracking
A 2D grid where you need to count connected regions of 1s? That's DFS. Shortest path from cell A to cell B? BFS.
Sorting and Binary Search
Sorting algorithms aren't usually implemented from scratch, but you need to understand what built-in sort gives you (typically O(n log n)) and when it's appropriate to use it.
Binary search applies any time you're searching in a sorted structure and can eliminate half the options at each step. Know the template cold — the off-by-one errors in binary search trip up even experienced engineers.
How to Prepare Without Burning Out
Grinding 500 LeetCode problems is not a strategy. It's exhaustion. A focused approach beats brute-force volume.
Pattern-first, not problem-first. Pick one pattern per week — two-pointer, hash map, BFS — and solve 8–10 problems that use it. Once you recognize the pattern, the implementation follows.
Practice [Big O notation](https://en.wikipedia.org/wiki/Big_O_notation) until it's automatic. After every problem, state the time and space complexity without prompting. Interviewers ask this every time. If you hesitate, it signals you don't fully understand your own solution.
Use a timer. Most coding rounds are 30–45 minutes. If you're spending 90 minutes on each practice problem, you're training the wrong skill. Set 35 minutes. If you don't finish, review the solution and note why.
Talk out loud during practice. Put yourself on a video call with a study partner or just narrate your thinking to the wall. The ability to explain your reasoning while you code is its own skill — it doesn't happen automatically.
Don't skip mock interviews. Solving problems in a quiet room is not the same as solving them while someone watches. At least two or three sessions with a real person, under time pressure, before your actual interview.
Behavioral Questions in Technical Rounds
Technical interviewers ask behavioral questions too — usually at the start or end of the session. These aren't filler. They're evaluating whether you can work on a team, handle ambiguity, and grow from failure.
The most common ones:
- "Tell me about a bug that took you longer than expected to fix."
- "Describe a time you disagreed with a technical decision. How did you handle it?"
- "Walk me through a project you're most proud of."
- "How do you approach learning a new technology you've never used before?"
Use the STAR format (Situation, Task, Action, Result) but don't make it obvious you're using a framework. The best answers sound like stories, not structured responses.
For "tell me about a hard bug": choose something where the bug was genuinely non-obvious — a race condition, a memory leak, a subtle off-by-one in a distributed system. Walk through your debugging process: what you suspected, what you ruled out, what finally surfaced the root cause. The journey matters more than the resolution.
What Interviewers Are Actually Scoring
Most technical interviews use a rubric that breaks down into a few core dimensions:
| Dimension | What the interviewer is looking for |
|---|---|
| Problem-solving | Do you break the problem down before coding? |
| Communication | Can you explain your thinking clearly? |
| Code quality | Is the solution readable and maintainable? |
| Correctness | Does it handle edge cases and produce right answers? |
| Efficiency | Do you know the time/space complexity? |
| Coachability | Do you respond well to hints? |
Coachability is underrated. When an interviewer offers a hint, candidates who get defensive or ignore it lose points. The right response: "That's a good point — let me think about how that changes the approach."
How to Recover When You're Stuck
Being stuck is normal. What you do next is what separates candidates.
Narrate the block. "I know I need to track which elements I've visited — I'm trying to figure out whether a set or a map is the right structure here." This shows you're thinking, not frozen.
Restate the problem. Sometimes the constraint you forgot is the key. Say the problem back in plain language. Interviewers often drop hints through their response.
Start with brute force. A working O(n²) solution is better than a beautiful O(n) solution you never finish. Say explicitly: "Let me start with the naive approach, get it working, then optimize." Most interviewers respect this.
Ask a clarifying question. "Can I assume the input is always sorted?" or "Should I handle empty arrays?" is not a sign of weakness. It's professional engineering behavior.
Preparing for the Specific Person Interviewing You
Most interview prep is generic — and that's the ceiling it hits. You can know every JavaScript interview question pattern cold and still walk into a room unprepared for *this* person at *this* company.
Find out who's interviewing you before the call. Look at their background: what they've built, what they've written, what they cared about in previous roles. If your interviewer spent three years on distributed systems, expect that to come up. If they're a frontend engineering manager, they probably care more about component architecture than low-level memory management.
Articuler's AI meeting-prep tool — the Playbook — builds a background briefing on any person in minutes: what they've worked on, what they care about, potential common ground, and tailored conversation starters. For a technical interview, that context helps you calibrate which depth of answer to give and which examples land best.
And if you want to get ahead of the interview entirely — by reaching the hiring manager directly before the role even posts — Articuler's semantic search can surface the right person at a target company and draft outreach that actually gets a reply.
FAQ
How many LeetCode problems should I solve before an interview?
Quality beats quantity. 50–80 problems across all major patterns is more effective than grinding 500 random ones. Focus on understanding why a pattern applies, not just memorizing solutions.
What's the most common mistake candidates make in coding interviews?
Jumping straight into code without understanding the problem. Spend the first 3–5 minutes clarifying constraints, walking through an example, and sketching your approach before writing a single line.
How important is Big O analysis in technical interviews?
Very. Most interviewers ask about time and space complexity for every problem. Practice stating it automatically after each solution — it signals that you understand your own code.
Do I need to memorize sorting algorithms?
You need to understand what built-in sort gives you (O(n log n)) and be able to implement a basic algorithm like merge sort or quicksort if asked. Full memorization of all variants isn't necessary.
How do I handle a question I've never seen before?
Start by identifying what category it looks like (graph? string? DP?). Apply the pattern you know for that category. If nothing fits, talk through the brute-force approach and look for optimization from there.