🗺️ How to prepare the technical interview
A strategic approach to prepare your interviews + 🎁 Free Notion interview tracker I used to prepare my interview
Writing this newsletter has been a challenge for the last couple of months. I was preparing for an internal interview loop to switch teams.
I had to be very deliberate on this one. I was hired as a new grad SDE-1 at Amazon, so I didn’t have a system design interview or expectation to talk from experience in other companies. Now I’m an SDE-2 and both are expected for my level.
I’m happy to share that I passed my interviews with the team I wanted. During the next month, I’ll share 4 posts about how to prepare these interviews:
🗺️ How to prepare the technical interview (this post).
🚲 Initial preparation
🏁 Start with the end in mind
Let’s define the goals of the interview loop:
1️⃣ Make the interviewer’s emotional brain feel that you are the kind of person they want to work with.
Because it was an internal transfer, I went 45 minutes overtime in 2 out of 3 loops because we ended up chatting about the product in the new team, the org structure…
This may not seem too important. But believe me, nobody would dedicate the extra time to someone hard to work with.
In one of these, I had a hard time with a coding problem. But it’s not an excuse to shut down the conversation. These situations happen at work. You want to work with someone who remains a team player even in the face of a challenge.
2️⃣ Make the interviewer’s rational brain receive enough signals so they can justify hiring you.
The goal is not this final result of the problem, but your thought process of how you got there. Solving perfectly a problem in silence doesn’t mean you’ll get hired.
You want to verbalize all your thought processes, like if the interviewer plugged their headphones into your brain and could listen to your inner voice.
Walk them through your thinking.
Neuroscience tells us that you are not going to get the problem right by being silent, but by talking and aiming to connect ideas. Ogi Ogas won half a million dollars in Who Wants to Be a Millionaire. His strategy was talking a lot to the host before guessing, hoping to get the spark on the neural network that drives him to the right answer (listen about it here)
💡 Understand the interviewer’s point of view
External candidates have an extra screening process (online assessments, phone screens…). In my case for internal transfer, only the onsite round applies.
For each candidate doing an onsite, interviewers go through this process:
Pre-brief: Interviewers, the hiring manager, and the recruiter craft an interview schedule that covers all major competencies needed for the role.
Interview loops: This is what the candidate sees. Multiple 1-hour rounds. Depending on the company there are one or two questions. In Amazon, each 1-hour loop is half behavioral and half technical.
The goal of the interviewer is to collect signals on the competencies they were assigned in the pre-brief. They don’t care too much about how amazingly you are solving another competency, they care about theirs.
Make the interview a conversation. Read between the lines of the interviewer. Don’t get too fixated with going in one direction if the interviewer tries to nudge you into another.
Debrief: Each interviewer submits their feedback and hiring decision independently. Then they all get together and decide on a final decision.
The hiring decision is usually a hire/no-hire with low/high confidence.
Even if everyone aligns on the decision, the feedback and particular signals are still discussed to give visibility to the rest.
When the decision is divided, the high-confidence signals take the lead.
This is where you don’t want to have any red flags as a candidate.
🦜 Prepare the small talk
If you start having a friendly conversation, it creates a halo effect in the interviewer’s eyes. Your mistakes won’t be high-confidence red flags. Your right answers will be closer to high-confidence signals.
1️⃣ Prepare your self-introduction.
You never jump directly to an interview question without even saying hi. Use it in your favor. Have your elevator pitch prepared sharing your name, last 2-3 experiences in reverse-chronological order, and any noteworthy product they may know about.
This is my example:
My name is Fran, I’m an SDE-2 working on Amazon’s retail search page. I joined 2 years ago as an SDE-1 and got promoted in the middle. I have worked on customer-facing features such as the AddToCat button on the search page and some internal services. This was a great opportunity to work on a high-visibility project that was tracked at the CEO level and interact with non-tech stakeholders. I joined just out of university and now I’m looking to work in a new environment that brings me a new perspective and grow as a well-rounded engineer.
Notice things like:
“Got promoted in the middle”, “want to keep growing as an engineer” → Show I’m intentional about my career. Appeal to the learn and be curious leadership principle (Amazon’s culture)
Interact with non-technical audiences → It’s a common trait of seniority. I’m marketing myself and creating a bit of halo effect.
2️⃣ Prepare the questions to ask after the interview loops.
Start by showing interest in the problem the company solves, not the salary or work conditions. Reserve any question about pay to the hiring manager or recruiter, an engineer would just shrug under these questions.
Ask questions you are genuinely interested in. Internal interviews are a chance to have a 1-to-1 meeting with engineers in other parts of the company.
In my case, I am part of a design review group in my current org, and I want to do the same in the new team. I socialized this interest with everyone I interviewed with. I got the information that there is no such a group with regular reviews, plus I got a few people interested in joining the group. This is useful networking.
🎁 Check the Notion template I used for interview preparation for a list of questions.
🏹 The interview strategy
Studying while having a full-time job and personal obligations is hard. Let’s get strategic.
#1 The Mindset
Rote repetition won’t give you results. Don’t grind leetcode blindly.
🗺️ Define your framework for tackling each interview. A series of steps you’ll follow when solving problems.
Like the basketball player who has done thousands of 3-point shots, you practice the repetition of the movement, and on the day of the match, you execute the same steps.
This removes the ambiguity, the paralysis when you have to solve a problem that you don’t how to at first, and the nerves of the day of the interview.
“Mind Like Water: A mental and emotional state in which your head is clear, able to create and respond freely, unencumbered with distractions and split focus.” - David Allen in the book “Getting Things Done”
As a software engineer, my interviews are Behavioral, Coding, and System Design. In the post for each type, I’ll share the details for preparation.
⚙️ Define your learning modes. Not all hours of preparation are equal. I have identified three modes and practiced the three of them for each kind of interview:
🧑🎓 Deliberate study time: This is when you study new material. It’s not passive reading, but taking notes, checking particular sections of the books instead of reading start to finish, and writing about it as if you were going to publish it.
🧑🏭 Deliberate practice time: This is when you solve practice problems. Your primary goal is not learning new concepts of System Design or a Data Structure, but applying this knowledge to make it stick
🛡️ Siege your brain time: This is about surrounding yourself with these topics. You live and breathe replication techniques of databases. You wake up and think about doing a breadth-first search in your house to find where you put the keys. I made use of my time having lunch and dinner at home to watch YouTube videos related to interviews.
#2 Create a plan
First draw a map - Scott Young in the book “Ultralearning”
You need a structured approach to learning.
🌍 Context plan
“I’m going to study Monday to Friday before work, from 6.30 am to 8.30 am just after waking up, at my desk at home”
This is an implementation intention. If you are not in a rush for interviews, I recommend reading Atomic Habits by James Clear.
Consider your work and life season. It’s going to be hard to study for interviews if you have a deadline at work that gets you working overtime and if you have a few personal travels in the middle of the preparation time.
During your preparation time, you need to be consistently available to study. Make it a routine.
📚 Content plan
This is the moment you read posts like the ones I’m writing in this newsletter. You read the table of contents of the books and courses you think about taking.
You don’t randomly find a new book and start reading it in the middle of your preparation. Do this work upfront.
Put a target date in the calendar for the interview. Then work backward from it.
The next sections are my recommended phases until the interview.
#3 Start the preparation
Goal: Get new concepts (and old ones you forgot) into your brain
Time: Since you start preparing until 3-4 weeks before interview
This is the kind of work you can do for months until the interview. The longer your preparation time, the more quality content you can study.
Still, you don’t want to blindly study without applying it. Dedicate 80% time to studying the books and courses, and 20% of the time to going through problems, and applying the knowledge.
During this time, in a study session, I would read one hour of a book about data structures and algorithms and then do just 1 leetcode easy problem
Activities in each learning mode:
🧑🎓Deliberate study: Read the book/paper or watch the course taking notes.
🧑🏭Deliberate practice: Just start going through some problems, without grinding.
🛡️Siege your brain: Company tech talks and engineering blogs (e.g. AWS re:Invent talks), newsletters (e.g.
)
Learn things deeply. Don’t go from start to end but go to the sections that seem related in multiple resources.
As an example, read the chapter on Hashmaps in Cracking the Coding Interview, in Grokking Algorithms, do a couple of Leetcode problems tagged for hashmaps, and watch some videos about designing a Key-Value store.
Get evidence of the same pattern in your brain from multiple sources and in multiple contexts. Siege your brain with it!🛡️
#4 Struggle time
Goal: Dedicate struggle time to solidify the concepts in your brain
Time: 3-4 weeks before interview until the start of interviews
Reading theory feels nice, you take your time to understand it. Now your focus is different.
The goal is not learning new theory or feeling good.
Attack your weakest point. Make you uncomfortable.
Maximizing your struggle time means you are dedicating your time to the highest ROI activity. When something feels nice and easy, jump to the next thing.
These sessions give you direct feedback on how comfortable are you with the concepts.
Now your focus is 95% on solving problems. The other 5% is to check the books for particular things you found in a problem.
Activities in each learning mode:
🧑🎓Deliberate study: You stop it. You only check the books and courses as reference material.
🧑🏭Deliberate practice: You solve several problems in a given time. Here is where you are applying the step-by-step framework for each kind of interview. You are doing your drills, your 3-point-shots practice getting the muscle memory for the day of the match.
🛡️Siege your brain: Solved interview questions on YouTube.
#5 The interview week
Goal: Build indexes in your brain for fast retrieval of information through different access patterns
Time: 1-2 days before the interview and during them
Your preparation is over. You are not building more muscle, just maintaining it. More grinding will only get you tired for the day of the match.
Now it’s time for pattern matching.
Revisit your solved problems and some new ones just at a high level.
Your goal here is not memorizing, but neither is getting new knowledge into the brain. The goal is to connect ideas.
You are applying the “siege your brain” mindset with more and more references.
A word of warning: Don’t siege your brain the same day of the interview. That day focus on being relaxed and with your mind fresh.
If you get nervous, avoid the FOMO of reading about some kind of tree that appears in some Leetcode hard problems.
Calm yourself by reading your step-by-step framework for each kind of interview. We fear the interviews and the exams because it’s the unknown.
Ground yourself in your well-known framework.
🎯 Conclusion
Interview preparation takes time. It’s a mountain and you don’t see the peak.
Don’t think about how much is left. Focus on your next action, your next step
“The most important step a man can take. It's not the first one, is it? It's the next one. Always the next step, Dalinar.” - Brandon Sanderson in “Oathbringer”
I dedicated 5 weeks of study plus the interview week. Roughly 2 weeks on theory, and 3 weeks of grinding problems. And the week of the interview I focused on being well-rested and just did pattern matching.
Lastly, I’d like to share the inspiring story that I read both times I have prepared interviews. It advocates for hardcore grind, but it serves as motivation. Once you see people doing it, you find it achievable and believe you can do it too. (post1, post2)
I hope my newsletter has the impact these two Reddit posts had on me.
🗃️ Resources
📚 Productivity books mentioned in the post:
Getting Things Done by David Allen.
Ultralearning by Scott Young.
Atomic Habits by James Clear.
Technical resources for each interview type in the upcoming posts
👏 Weekly Applause
This is some great content I have gone through during the week
Are your standards too low? In defense of raising the bar -
. When changing jobs you want to surround yourself with high-performersMastering Leadership: 5 Behaviors that Made Me Approachable -
. When changing jobs try to find people easy to work with.7 books that changed me the most as a software engineer -
. Some good sources of deliberate study time contentThe Best Leadership Quotes and How to Apply Them -
An Engineer's Echo. When changing jobs, look for people who apply the company culture, not something just painted on the walls.
What I Wish I Knew As a Mid-Level Engineer -
. Sometimes the best decision is to move teams if you are only producing high throughput with low impact. This post applied a lot to my current level.
Great article, Fran. I'm saving this to pass along to future folks who ask me for advice :). Looking forward to the upcoming ones you have planned too.
Thank you for the mention too 🙇♂️
Appreciate the shout out, Fran. Great advice here, especially for appealing to both the interviewer’s emotional brain and rational brain.