#22 Preparing for Tech Interviews, Part 1: Coding

Welcome to Part 1 of Preparing for Tech Interviews series, where I share insights and advice gathered from software engineers working at high-growth startups and big tech companies like FAANG.

---

Preparation Guide

First, let’s break down the preparation time for each interview based on engineering experience.

Rough percentages collected from 50+ engineers at all levels.

Note: companies might have specific requirements/responsibilities for their roles. Make sure to contextualise these estimates based on the role you’re applying for.

Important insights:

1. Junior / Fresh Grads should focus on their problem-solving skills through programming and on explaining their thought process. Having general system / software design knowledge is a plus.

2. Mid-Level Engineers are expected to have some experience working with production-grade systems. While coding remains a priority, they should invest time in preparing for system design and behavioural.

3. Senior Engineers cannot pass solely on coding (only 40%). They are expected to demonstrate strong system design skills and communication skills. Some companies also expect them to operate as a tech lead or mentor to juniors, so they might be asked leadership questions in their behavioural interviews.

4. Staff Engineers is the first rung on the leadership ladder. They are expected to demonstrate deep technical expertise in system design and leadership in behavioural interviews. A candidate with:

   strong system design + strong behavioural + okay coding = yes

5. Principal Engineers’ preparation is harder to pin down since it depends on their industry expertise and the business needs. However, their main role is to shape the company’s technical direction, so the focus should be on demonstrating organisational impact and deep technical expertise relevant to the role.

Note: Some companies merge or expand roles based on their structure. Staff/Senior engineers are often labeled as Tech Leads. Mid-level engineers may be divided into multiple levels, such as E3/E4 at Meta or SDE II/III at Amazon.

---

Part One: Coding Interviews

There are two types of coding interviews:

1. Algorithmic

A standard interview to evaluate a candidate’s knowledge of data structures, algorithms (DSA), and complexity analysis through coding problems.
Examples: Binary Search, String Manipulation, Tree Traversal, etc.

2. Task-based

An exercise (or take-home assignment) to evaluate a candidate’s knowledge through application development. Ideal for assessing specific roles such as Backend, Frontend, and DevOps.
Examples: CRUD Applications (e.g., ToDo App), Web Scrapper, etc.

---

I. Algorithmic Interviews

More common in big tech and large companies than in small ones and startups.

Algorithmic interviews are the standard for assessing CS graduates and junior engineers. These interviews are great for testing the foundations like data-structures and algorithms, Big O analysis, object-oriented programming, design patterns, etc.

Since these candidates don’t have much production experience, companies rely on algorithmic interviews to evaluate their problem-solving skills and their understanding of core software engineering principles.

Four Things to prepare for Algorithmic Interviews:

1. Data-structures and Algorithms (DSA)

2. Time and Space Complexity (BigO)

3. Thinking Vocally

4. Practicing Pattern Recognition

1. Data Structures and Algorithms (DSA)

First things first, you need to learn your data structures and algorithms before attempting to solve problems. They are the backbone of building efficient software.

You should be able to explain what a data structure does, when it’s useful, and how to use it.

For example, understanding why searching for a value in a Python dictionary is faster than in a list, and knowing their underlying data structures.

Data-structures to study:

> Arrays & Linked Lists (Singly, Doubly, Circularly)
> Stacks (LIFO-order) & Queues (FIFO-order)
> Hash Tables (Hash Maps/Sets)
> Trees & Tree Traversals (PreOrder, InOrder, PostOrder)
> Binary Search Trees
> Graphs
> Heaps (Min/Max Heaps & Priority Queues)
> Tries

You should also learn the algorithms that operate on the data within these structures—how each algorithm works (e.g., searching, adding, removing), when it’s useful, and its cost (time and space complexity).

Algorithms to study:

> Search Algorithms (Binary Search, Breadth-First, Depth-First)
> Sort Algorithms (Bubble Sort, Merge Sort, Quick Sort, etc.)
> Dynamic Programming (DP)
> String Algorithms (Longest Common Subsequence (LCS), Tries, etc.)
> Graph Algorithms (Topological Sort, Dijkstra's, A* Search, etc.)
> Two Pointers & Sliding Window Technique

You can search online for resources that explain each of these algorithms (i.e., GeekforGeeks).

Note: I covered some of these data-structures in my old blog posts (ignore the bad english). Here’s one on Binary Search Trees.

2. Time and Space Complexity (Big O)

A common mistake that some candidates make is coding up a solution, without knowing how long will it take and how much memory it needs.

Time and space complexity are measurements of how much time and memory an algorithm needs to run as a function of the amount of input it receives.

Understanding Big O is critical for software engineers. Choosing the right algorithm can make the difference between a program that runs in seconds and one that takes hours or even days. Make sure you’re able to analyse and justify the complexity introduced in your algorithms.

A candidate who is able to analyse their algorithms and explain trade-offs in time and space complexity is a positive signal.

3. Thinking Vocally

One common mistake I find with candidates during interviews is when asked to solve a specific challenge, they jump into implementation without thinking vocally.

Thinking vocally is verbalising your thought process out loud while working through a problem. This allows you to show to your interviewer/future teammate your reasoning and logical steps when solving a problem.

A candidate who communicates ideas clearly and explains their approach is a positive signal.

4. Practicing Pattern Recognition

Pattern recognition is when you solve many problems around a specific topic (e.g., dynamic programming), and in the process, you develop a pattern for recognising the need for an algorithm (e.g., memoization technique) based on the problem description.

The more you practice, the more you train that pattern recognition muscle.

A common mistake that candidates do is open a coding platform (eg., LeetCode) and attempt to solve all Easy problems, then move to Medium problems, and so on. This isn’t practical because A) You don’t have an infinite amount of time, and B) Your job is not to LeetCode.

Here’s my practice strategy:

1. Pick a category (e.g., string manipulation) and select a problem.

2. Spend ~30 minutes on it—try to solve it using the naïve approach, then improve.

3. Look up online solutions and understand how it differs from yours.

4. Revisit the problem few weeks later and solve it again.

5. Repeat this for 2–5 problems per day.

This strategy helped me pass Microsoft and Amazon interviews after six weeks of preparation.

Note: The preparation time depends on how much time you can allocate per day. Some candidates take anywhere from 4 to 12 weeks to prepare.

📖 Study Resources

1. Highly recommend reading HelloInterview.

2. LeetCode is a great platform for practicing problem-solving (by category!).

3. A detailed explanation of 250 problems: Elements of Programming Interviews (C++ edition)

   • Also available in Python edition.

4. A great resource for learning how to solve DSA questions (189 problems) Cracking The Coding Interview, 6th edition by Gayle Laakmann McDowell.

5. An excellent reference for your bookshelf Introduction to Algorithms (by C.L.R.S.)

Disclaimer: Junior / Fresh Grads might be asked more on CS topics beyond DSA like OOP, Design Patterns, SOLID principles, etc. Or to design (not code) a software application (as a replacement for system design interview) like Chess, Book Library, etc.

🌟 Tip: If you’re not sure, email your recruiter and ask what to expect in the interview.

---

II. Task-based Interviews

More common in early-stage startups and small to mid-sized companies than in big tech.

Task-based interviews come in different forms depending on the company’s domain and are often tailored to specific roles like Backend, Frontend, DevOps, etc.

This format is primarily designed for experienced software engineers (and occasionally fresh grads) to assess their ability to solve real-world problems using a tech stack. Two examples are:

Book Catalog API (eg., Goodreads https://www.goodreads.com/api)

Build a simple REST API that allows users to manage book catalogs.

• Adding a new book with a title, author, and publication year

• Fetching a list of books

• Searching for books by title or author

• Deleting a book by ID

Project Management API (eg., Jira API)

Build a minimal API for managing projects and tasks.

• Allow users to create, update, and delete projects / tasks.

• Retrieve project / task information.

• Mark projects / task as completed

• Retrieve a list of all projects / tasks.

Four Things to prepare for Task-based Interviews:

1. Get Comfortable With Your Tools

2. Learn To Scope

3. Build Personal Projects

4. Read As You’re Building

1. Get Comfortable With Your Tools

One of the goals in task-based interviews is to see how you work as an engineer—how you set up your development environment, which tools/languages/frameworks you use, how you test your solution, how you use documentation, etc.

The first step is to pick a stack you’re interested in (e.g., Python, React, PostgreSQL, Docker, AWS) and practice developing applications while learning about best practices.

Don’t waste time on “mastering” multiple languages. Pick one language you’re comfortable with and deepen your knowledge and expertise in it.

2. Learn to Scope

Some interviews will intentionally give you a vague task to solve. Your role is to ask follow-up questions to gather requirements and make sure you’re clear on what you need to build.

Say you’re asked to implement Amazon Gift Cards API.

Some follow up questions are:

• What are the core features of the Gift Cards API? (e.g., create, redeem, check balance, deactivate)

• What information should be stored for each gift card?

• Are there any expiration rules for gift cards?

• What happens if a user tries to redeem an expired or deactivated gift card?

If you’re making some assumptions, be sure to communicate them back to the interviewer. This helps validate the scope and requirements you’ve gathered. Once everything is clear, you can start building the solution.

🌟 Tip: Make sure to test your solution during the interview. If time runs out, explain your testing strategy out loud and highlight any improvements you would have made if you had more time.

3. Build Personal Projects

To build confidence in task-based interviews, you should be comfortable with:

1. Designing and building CRUD apps, interacting with databases, etc.

2. Testing and debugging apps, integrating third-party APIs, etc.

3. Deploying and monitoring apps.

Building a personal project allows you to go through this cycle. The more you build, the more capable you become. Think of any project or idea you’re interested in, and build a small version of it. Be careful of tutorial hell (i.e., watching tutorials all day without building)

Here’s an inspiration:

1. Budget Tracker – Build an app to track expenses, predict future spending (maybe plug-in an ML model?), visualise monthly spending, etc.

2. Sports Bracket Generator (e.g., Premier League) – Learn how to integrate a Sports API to generate tournament brackets and display live updates for your favourite sports.

3. Messaging App (e.g., WhatsApp) – Learn how to build real-time messaging using WebSockets.

🎁 Practice Test: Here is a document for a project idea, Gift Cards.

🌟 Tip: Having your personal projects available on GitHub is a strong signal in your resume and an opportunity for others to see your quality of work.

Start small. The smaller the project, the easier it is to complete and share.

4. Read as You’re Building

As you build personal/work projects, you’ll encounter various engineering topics that will challenge you to deepen your understanding, gaining both knowledge and hands-on experience.

Some of these topics are:

• API design: learning about REST, GraphQL, gRPC, and SOAP.

• Testing: Unit vs. integration testing, white vs black box testing, etc.

• Storage: SQL vs. NoSQL, ORM, indexing, isolation levels, transactions, etc.

• Deployment: CI/CD, deployment patterns, and strategies for scalability.

• Observability (o11y): Using logs, metrics, traces, and OpenTelemetry (OTel)

• Performance: Load testing, profiling, and optimisation techniques.

• Security: Data validation & sanitisation, AuthN vs. AuthZ.

• AuthN & AuthZ: token (JWT) vs. session (cookie), OAuth 2.0, SAML, etc.

• Cloud Deployment: EC2 vs Lambda (Serverless) for app hosting.

• Container Orchestration: Kubernetes (K8s) vs. managed service (EKS vs. ECS).

Going through all of them during the interview is not possible. However, be prepared to discuss any of them. I’ve found that reading + hands-on experience from building applications is the best way to internalise new concepts over time.

---

Wrap up

Tech interviews may include both algorithmic and task-based rounds. In general, these are the two main approaches companies use to evaluate candidates, so make sure to practice both.

Pick your favourite programming language and practice, practice, practice.

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.