Free Guide

Software Engineer Interview Prep Guide

What to study, how to practice, and what interviewers actually look for at each stage.

15 min read

Introduction

Technical interviews can feel overwhelming, but they follow predictable patterns. Interviewers aren’t trying to trick you—they’re trying to understand how you think, solve problems, and communicate. This guide breaks down each interview stage and gives you a concrete plan to prepare.

The key insight: interviews are conversations, not interrogations. You’re evaluating them as much as they’re evaluating you.

Resume Tips

Your resume is your first impression and often determines if you get an interview at all.

Format

One page for mid-level engineers, two for 5+ years of experience
Clean layout: use consistent formatting, white space, standard fonts (Arial, Calibri)
ATS-friendly: avoid graphics, tables, and fancy formatting (systems scan these)
Contact info: name, email, phone, city/state, LinkedIn, GitHub

What to Include

Lead with impact, not tasks:

Bad:

- Worked on backend API
- Wrote some tests
- Fixed bugs

Good:

- Designed and built payment processing API serving 50k requests/day
  with 99.95% uptime, reducing payment processing time from 5s to 200ms
- Increased test coverage from 45% to 82%, catching 3 critical bugs
  before production
- Led incident response for database outage, implementing failover
  strategy that prevented 8 hours of downtime

Quantify achievements:

Performance improvements (% or absolute metrics)
Scale (requests/day, users, data volume)
Business impact (revenue, cost savings, time saved)
Team impact (mentored X developers, led Y migrations)

Structure Each Role

[Company Name] | [Job Title] | [Dates]
- [Accomplishment 1 with metric]
- [Accomplishment 2 with metric]
- [Technical details: languages, frameworks, tools used]

Skills Section

List relevant technologies (the recruiter will grep your resume):

Languages: Java, Python, JavaScript, Go
Databases: PostgreSQL, MySQL, Redis, MongoDB
Tools/Platforms: Docker, Kubernetes, AWS, GitHub
Frameworks: Spring Boot, Django, Node.js, React

Keywords Matter

Many companies use ATS (Applicant Tracking Systems) that search for keywords. Include:

Specific languages and frameworks you’ve used
Methodologies (Agile, Scrum, TDD)
Cloud platforms (AWS, GCP, Azure)
Databases and tools relevant to the role

Phone Screen Prep

The phone screen (usually with a recruiter or junior engineer) is about feasibility: Do you have the baseline skills? Can you communicate clearly? Are you interested in the role?

Before the Call

Research the company: products, engineering blog, recent news
Understand the role: required skills, team size, reporting structure
Know your story: 2-minute summary of your background and why you’re interested
Test your setup: quiet room, good internet, working webcam
Have your resume printed or visible
Have a notepad ready

During the Call

Be conversational, not robotic:

Listen to the question fully before answering
Ask clarifying questions if needed
Share specific examples (use the STAR method: Situation, Task, Action, Result)
Ask genuine questions about the team and role

Common questions:

“Tell me about yourself” (2 minutes max)
“Why are you interested in this role?”
“What’s a challenge you’ve overcome?”
“What do you want to learn/improve on?”
“What questions do you have for us?”

Red flags to avoid:

Talking too much (let them speak too)
Not asking any questions (shows disinterest)
Bad-mouthing previous employers
Being unclear about your goals
Not knowing anything about the company

After the Call

Send a thank you email within 24 hours
Reference something specific from the conversation
Reiterate your interest
Ask about next steps

Coding Interview Prep

This is where technical depth matters. Most companies test three areas: data structures, algorithms, and coding patterns.

Data Structures You Must Know

Understand the time and space complexity of each:

Arrays and Strings

Operations: access O(1), insert/delete O(n)
Common problems: two-pointer, sliding window, prefix sum
Examples: reverse string, merge sorted arrays, container with most water

Hash Maps/Sets

Operations: insert/lookup O(1) average
Use when: you need fast lookup or counting duplicates
Examples: two sum, valid anagram, group anagrams, most frequent elements

Linked Lists

Operations: traverse O(n), insert/delete O(1) if you have the node
Use when: frequent insertions/deletions or cyclic structures
Examples: reverse linked list, detect cycle, merge sorted lists

Stacks and Queues

Stack: LIFO, use for: bracket matching, expression evaluation, DFS
Queue: FIFO, use for: BFS, task scheduling, rate limiting
Examples: valid parentheses, daily temperatures, implement stack using queues

Trees and Graphs

Binary trees: traversal (in/pre/post-order), BST operations
Graphs: DFS/BFS, shortest path (Dijkstra, BFS), connected components
Examples: level order traversal, lowest common ancestor, path sum, number of islands

Heaps

Operations: insert/extract O(log n)
Use when: finding kth largest, priority queues, median finding
Examples: top k frequent elements, kth largest element, merge k sorted lists

Algorithm Patterns to Master

Two Pointer Used for sorted arrays or linked lists:

// Example: two sum in sorted array
function twoSum(arr, target) {
  let left = 0, right = arr.length - 1;
  while (left < right) {
    const sum = arr[left] + arr[right];
    if (sum === target) return [left, right];
    if (sum < target) left++;
    else right--;
  }
  return null;
}

Sliding Window For substring/subarray problems:

// Example: longest substring without repeating characters
function lengthOfLongestSubstring(s) {
  const seen = new Set();
  let left = 0, max = 0;
  for (let right = 0; right < s.length; right++) {
    while (seen.has(s[right])) {
      seen.delete(s[left++]);
    }
    seen.add(s[right]);
    max = Math.max(max, right - left + 1);
  }
  return max;
}

Binary Search For sorted arrays or when you can binary search on the answer:

function binarySearch(arr, target) {
  let left = 0, right = arr.length - 1;
  while (left <= right) {
    const mid = Math.floor((left + right) / 2);
    if (arr[mid] === target) return mid;
    if (arr[mid] < target) left = mid + 1;
    else right = mid - 1;
  }
  return -1;
}

Dynamic Programming For optimization problems (fibonacci, coin change, longest subsequence):

// Example: coin change (minimum coins)
function coinChange(coins, amount) {
  const dp = Array(amount + 1).fill(Infinity);
  dp[0] = 0;
  for (let i = 1; i <= amount; i++) {
    for (const coin of coins) {
      if (coin <= i) {
        dp[i] = Math.min(dp[i], dp[i - coin] + 1);
      }
    }
  }
  return dp[amount] === Infinity ? -1 : dp[amount];
}

Backtracking For combination/permutation problems:

// Example: generate all permutations
function permute(nums) {
  const result = [];
  function backtrack(current) {
    if (current.length === nums.length) {
      result.push([...current]);
      return;
    }
    for (const num of nums) {
      if (!current.includes(num)) {
        current.push(num);
        backtrack(current);
        current.pop();
      }
    }
  }
  backtrack([]);
  return result;
}

How to Approach a Coding Problem

Clarify the problem (2 minutes)
- Ask about input/output format, edge cases, constraints
- Example: “If the array is empty, should I return null or throw an error?”
Think out loud (2 minutes)
- Share your approach before coding
- Walk through a simple example
- Discuss time/space complexity
Code carefully (10-15 minutes)
- Start simple, optimize later
- Write clean, readable code
- Test with examples as you go
Test and optimize (5 minutes)
- Walk through your code with the example
- Test edge cases: empty, single element, duplicates
- Discuss optimizations if time permits

Practice Strategy

Start here:

LeetCode Easy problems (100+ problems)
Focus on: arrays, strings, hash maps, linked lists

Then move to:

LeetCode Medium problems (50+ problems)
Mix of all categories
Practice explaining your solution out loud

Finally:

LeetCode Hard (10-20 problems)
Focus on: graphs, dynamic programming, system design patterns

Daily practice:

1-2 problems per day, 30 minutes max per problem
If stuck >15 min, read the discussion/solution
Understand the pattern, solve again the next day

System Design Interview

System design interviews test your ability to build large-scale systems. They’re less about “right answers” and more about your thought process.

Key Topics

Scale and Constraints

Understand the problem: how many users, requests per second, data volume?
Make reasonable assumptions: “Assume 1 million daily active users”
Calculate requirements: storage, bandwidth, throughput

Back of the Envelope Calculations

100 million users
10% daily active = 10 million users
Peak QPS = 10M / (24 * 3600) * 5 = ~600 requests/second

Core Building Blocks

Load balancers: distribute traffic
Caching: Redis, Memcached
Databases: SQL (strong consistency) vs NoSQL (scalability)
Message queues: async processing (RabbitMQ, Kafka)
Search engines: Elasticsearch for full-text search
CDN: serve static content from edge locations

Design Patterns

Master-slave replication: read replicas for read scaling
Sharding: partition data by key for write scaling
Caching: reduce database load
Rate limiting: protect API from abuse
Circuit breaker: handle downstream failures gracefully

Example: Design a URL Shortening Service (like TinyURL)

Requirements

Create shortened URLs from long URLs
Redirect short URL to original (302 temporary)
100 million URLs created per day
Read:write ratio 100:1

High-level approach:

1. API Layer
   - POST /shorten → create shortened URL
   - GET /:shortUrl → redirect to original

2. Service Logic
   - Hash long URL to generate short code (or use counter with base62 encoding)
   - Store mapping in database
   - Cache hot URLs in Redis

3. Database Schema
   - Table: urls (id, long_url, short_code, created_at, expires_at)
   - Index on short_code for fast lookup

4. Scale Considerations
   - Write: 100M/day = 1200 QPS → use sharding by short_code
   - Read: 120k QPS → cache in Redis (hot keys)
   - Expiration: background job to clean up old URLs

How to Approach System Design

Clarify requirements (5 min)
- Functional: what features?
- Non-functional: scale, latency, availability, consistency?
High-level design (5 min)
- Draw the architecture (API, services, databases, cache)
- Identify bottlenecks
Deep dive (10-15 min)
- Pick the most interesting/complex component
- Discuss trade-offs
- Solve the scaling problem
Trade-offs and alternatives (5 min)
- SQL vs NoSQL, consistency vs availability, etc.
- Why did you choose this approach?

Pro tips:

Draw on a whiteboard/virtual board as you talk
Ask questions: “Is low latency more important than strong consistency?”
Think about operations: “How would you monitor this? What would you alert on?”
Discuss scaling in both dimensions: horizontal (more servers) and vertical (bigger servers)

Behavioral Interview (STAR Method)

Behavioral interviews assess communication, teamwork, conflict resolution, and growth mindset. Use the STAR method:

Situation: Set the context (what was the project, what was the problem?)
Task: What was your responsibility?
Action: What did you do specifically? Use “I”, not “we”
Result: What was the outcome? Quantify if possible.

Common Behavioral Questions

“Tell me about a time you failed”

Poor answer: “I haven’t really failed” or vague failures

Great answer:

Situation: Built a caching layer expecting 10x improvement, but tests showed only 2x improvement.
Task: I had promised the team a significant performance boost.
Action: Instead of making excuses, I ran detailed profiling and discovered the bottleneck was actually
        the serialization layer, not the database. I refactored that instead.
Result: Achieved 12x improvement. More importantly, I learned to measure before optimizing.

“Tell me about a conflict with a teammate”

Poor answer: Blaming the teammate, staying vague

Great answer:

Situation: A senior engineer wanted to use a NoSQL database for a feature I believed needed strong consistency.
Task: We both had valid points and needed to reach consensus.
Action: I suggested we prototype both approaches. We built a small POC for the consistent path I proposed
        and a separate one for his NoSQL approach. Then we compared.
Result: His approach actually worked well. I learned that sometimes my assumptions were wrong.
        We shipped the NoSQL version and it's been stable for 2 years.

“Describe a time you led or influenced a decision”

Poor answer: “I just told them what to do”

Great answer:

Situation: Our test suite took 45 minutes to run, slowing down development.
Task: I wanted to switch to a faster framework but the team was hesitant about the migration.
Action: Instead of arguing, I created a small POC showing the time savings and migration path.
        I volunteered to do the first 30% of the migration myself. I made it easy for others to follow.
Result: The team agreed, we completed it in 2 weeks, and our test suite now runs in 10 minutes.

Questions to prepare:

Tell me about yourself
Why are you interested in this role/company?
Describe a challenging project
Tell me about a time you learned something quickly
Describe a time you improved a process
Tell me about your proudest accomplishment
Describe a time you had to work with a difficult person
Tell me about a time you took initiative
Describe a situation where you had to adapt to change
Tell me about a time you made a mistake

Company Research

Before your interview, know:

What they do: products, target customers, business model
Technical challenges: scale, reliability requirements, architecture
Culture and values: who they hire, what they care about
Recent news: funding, product launches, company changes
Team: who you’ll be working with (check LinkedIn)

Research sources:

Company website (products, engineering blog)
Glassdoor (employee reviews, salary ranges)
LinkedIn (team structure, company size)
GitHub (if they open source, see code quality)
Tech news (Hacker News, TechCrunch)
YouTube (some companies have tech talks)

Negotiation Basics

You have leverage after the offer. Use it.

Before negotiating:

Research salary ranges (Levels.fyi, Blind, Glassdoor)
Know your current total compensation
Decide walk-away number (minimum acceptable)
Write down priorities: salary, equity, title, remote work, signing bonus

The process:

They make an offer
You don’t accept immediately—ask for time to consider
Research the offer against market rates
If below market, counter with data: “Based on levels.fyi and my experience, the market rate is $X”
Be professional but firm
Negotiate other things too: signing bonus, equity vesting, start date, vacation, learning budget

What to negotiate:

Salary (most important)
Sign-on bonus (one-time cash)
Stock/equity (long-term value, but be careful about exercise prices)
Vacation (more PTO is valuable)
Remote flexibility (work from home)
Learning budget (conferences, courses)
Title (affects future compensation)

Example response to lowball offer: “Thanks for the offer. I appreciate it. Based on my research and experience, the market rate for this position is $X to $Y. Given my background in [specific skills], I was expecting something closer to $X. Could we move to that range?“

4-Week Study Plan

Week 1: Foundation

Monday: Review big-O notation, array/string basics
Tuesday-Wednesday: Solve 10 easy array/string problems
Thursday-Friday: Hash maps and sets (solve 5 problems)
Weekend: Practice explaining solutions out loud

Week 2: Core Data Structures

Monday-Tuesday: Linked lists (solve 5 problems)
Wednesday-Thursday: Stacks and queues (solve 5 problems)
Friday: Binary trees basics
Weekend: Review and identify weak areas

Week 3: Algorithms

Monday-Tuesday: Binary search and two pointers (solve 5 problems)
Wednesday-Thursday: Graphs (BFS/DFS) (solve 5 problems)
Friday: Dynamic programming intro
Weekend: Mix of medium problems from all categories

Week 4: System Design + Behavioral

Monday-Tuesday: System design study (watch videos, read articles)
Wednesday: Practice designing 2 systems (URL shortener, Twitter feed)
Thursday: Behavioral prep (write out 10 stories using STAR)
Friday: Mock interview (coding or system design)
Weekend: Rest and final review

Daily routine:

30 minutes: solve 1 problem (or review a solution)
15 minutes: brush up on weak area
10 minutes: behavioral/company research
Total: ~1 hour per day

Interview Day

Day Before

Get good sleep
Test your setup (internet, camera, audio)
Review your resume and key accomplishments
Prepare questions to ask the interviewer

Day Of

Dress appropriately (business casual or company culture)
Be 10 minutes early to virtual interviews
Bring water and a notepad
Take deep breaths before each interview
Smile (yes, even on video—people can hear it in your voice)

During

Listen fully before answering
Think out loud so they understand your process
Admit when you don’t know but explain how you’d figure it out
Ask questions (shows genuine interest)
Pace yourself (don’t rush through)

Questions to Ask Them

What does a typical day look like?
What’s the biggest technical challenge the team is facing?
How does the team handle on-call and incidents?
What’s the growth trajectory for this role?
What does success look like in the first 90 days?
Can you tell me more about the team I’d be working with?

Final Checklist

Before each interview:

Summary

Interviewing is a learnable skill. The more you prepare, the more confident you’ll be. Remember:

Interviewers want you to succeed (hiring is expensive)
Communication matters as much as being smart
Showing your thinking process is more valuable than perfect solutions
Asking questions shows genuine interest
You’re evaluating them as much as they’re evaluating you

Good luck. You’ve got this.