How to Prepare for a Technical Interview at International Tech Companies (and How to Practice LeetCode)
How to prepare for a technical interview: what it assesses
In the previous article I covered how to measure your offer rate and where to improve it. This one is about the practical details: how to prepare for a technical interview. As I mentioned, interviews mainly include three kinds of questions: self-introduction, technical questions and behavioral questions (BQs).
First, here’s what a technical test mainly assesses:
- Technical ability: whether you solved the problem, or how far you got (for example, 80% of test cases passing).
- How you react to problems: we don’t expect you to be so strong that you solve every question. What we care about is what you do when you face something unknown or something you can’t solve.
- Communication during the process: whether you can clearly explain your thinking, talk with the interviewer, ask for more information and clarify things.
These three apply to most technical roles. In keeping with this series, I’ll use software engineers as the example.
To improve the first two, practicing coding problems is basically enough. The third is better practiced through mock interviews, where you get feedback.
Practicing coding problems
You’ve probably heard of “grinding” coding problems. It mostly means practicing coding questions on LeetCode. The questions vary in type and difficulty, and a single question can test algorithms, clarity of logic, writing code and data structures all at once.
Why practice coding problems?
- Right now, the main way large companies test candidates is with coding problems. When I interviewed at Google and Amazon, the tests were mostly coding problems.
- More and more companies have stopped using them (see poteto/hiring-without-whiteboards), but the mainstream big companies still mostly do.
- One main reason is that the evaluation is more consistent. When my team was hiring, I could trust the other interviewers’ assessments, instead of everyone asking an open-ended question and scoring it differently.
- Another reason is that the scope is clearer. Compared with, say, practicing the top 100 common JavaScript interview questions, where it’s hard to judge what counts as good, coding problems are pass or fail. The approach you used and whether you passed all the test cases are obvious at a glance.
What to practice
The key question is: which types of questions do you need to work on right now?
- If you have a target company, start with that company’s past interview questions.
- Big companies have lists of common questions, and you can find them on LeetCode.
- I suggest filling gaps across the common question types. Get through Easy first, then move on to Medium and Hard.
- Build confidence first so you don’t burn out.
More specifically, you can pick questions from common question lists. Later in my own prep I used Google’s interview materials, which I got directly from a recruiter (allow me to show off a little).
This is the resource they gave me. I practiced data structures and algorithms from here:
https://techdevguide.withgoogle.com/paths/data-structures-and-algorithms/
I suggest you start from this one too. You can see it lists the main data structures and algorithms Google considers important.
Use these lists to rate how familiar you are with each topic. Again, you can use a traffic light:
- Green: mastered
- Yellow: OK, good enough for an interview
- Red: not familiar at all
How to improve as you practice
Once you’ve picked your questions, I usually suggest tracking the following as you practice:
- Which types of questions should you prioritize? Base it on the companies you’re interviewing with, or on your weakest areas. Specifically:
- Easy questions you can’t finish within 30 minutes
- Medium questions where you can’t work out an approach within 30 minutes
- For each practice session: time spent, question type, result and notes
Here’s an example log:
| Item | Type | Time spent | Result |
|---|---|---|---|
| Algorithm question | Binary tree | 40 minutes | Not finished |
| System design | Distributed system architecture | 1 hour | Partly successful |
- Question type: what kind of question are you working on? Which data structure or algorithm does it test?
- Time spent: I mainly check whether it was done within 30 minutes. If an Easy question wasn’t, or a Medium question was far off, I ask what happened.
- Result: did you solve it? Were there test cases that didn’t pass?
- Notes: what research and review you did afterward.
I usually ask my mentees to share this data with me. It makes it easy to analyze where to focus next.
What if the interview isn’t coding problems?
Some companies really don’t test with coding problems. This is often called an unstructured interview, which means the questions don’t follow a set pattern and the scope is harder to predict.
In that case, start with past interview questions or common interview questions.
Summary
Improving how you answer technical questions is a key part of interview prep.
Get clear on where you stand now, and use a suitable way to track your progress and keep moving. That’s how you keep improving and land the offer you want.