Engineering Interview Guide: Technical Questions, System Design & Problem Solving

Engineering interviews have multiple rounds, each testing different skills:

  1. Coding round (Algorithms + data structures)
  2. System design round (Architecture + tradeoffs)
  3. Behavioral (Your experience + collaboration)

Here’s how to nail them all.

What Engineering Interviewers Are Really Asking

Behind every technical question:

  1. Can you solve problems algorithmically? (Coding round)
  2. Can you think about scale and architecture? (System design)
  3. Can you communicate your thinking? (All rounds)
  4. Do you know when to use which tool? (Tradeoff awareness)
  5. Have you built things that work? (Real experience)
  6. Will you handle ambiguity? (Can you ask clarifying questions?)

Round 1: Coding Interview (60–90 Minutes)

What to Expect

You’ll solve 1–3 algorithmic problems on a whiteboard or collaborative coding platform.

Typical difficulty:

  • Easy: Simple data structure work (60% of companies)
  • Medium: Requires some algorithm thinking (most companies)
  • Hard: Requires solid CS knowledge (top tier companies)

What they’re measuring:

  • Can you break a problem into steps?
  • Do you know data structures + algorithms?
  • Can you optimize your solution?
  • Can you code cleanly and communicate?
  • Do you test your own code?

The Approach (35–40 min per problem)

Step 1: Understand (5 min)

  • [ ] Ask clarifying questions (don’t assume)
  • [ ] Repeat the problem back to them
  • [ ] Agree on expected input/output

Example:

“So you want me to find the longest substring without repeating characters? And I should return the substring itself or the length? The input is a string, right? What about edge cases—empty string, single character?”

Step 2: Brute Force First (5 min)

  • [ ] State the obvious solution (even if inefficient)
  • [ ] Estimate time complexity
  • [ ] Don’t jump to optimal yet

Example:

“The brute force would be: check every substring, see if it has repeating characters. That’s O(n³) because there are O(n²) substrings and checking each takes O(n). Obviously not optimal.”

Step 3: Optimize (10 min)

  • [ ] Think of better data structures (hash map? pointer?)
  • [ ] Walk through an example
  • [ ] Explain your thinking

Example:

“I could use a sliding window with a hash set. Keep track of characters in the current window. If I see a repeat, shrink from the left until it’s gone. That’s O(n) time because each character is visited at most twice.”

Step 4: Code It (10 min)

  • [ ] Write clean code
  • [ ] Variable names that matter
  • [ ] Assume they’ll grep your code later

Example (Python):

def lengthOfLongestSubstring(s):
    char_index = {}
    max_len = 0
    start = 0

    for end in range(len(s)):
        if s[end] in char_index:
            start = max(start, char_index[s[end]] + 1)
        char_index[s[end]] = end
        max_len = max(max_len, end - start + 1)

    return max_len

Step 5: Test (5 min)

  • [ ] Run through an example by hand
  • [ ] Test edge cases (empty, single char, all repeats)

Example:

"Let me trace through ‘abcabcbb’:

  • ‘a’: window = ‘a’, max = 1
  • ‘ab’: window = ‘ab’, max = 2
  • ‘abc’: window = ‘abc’, max = 3
  • ‘abca’: repeat ‘a’, shift start to 1, window = ‘bca’
  • … final max = 3 for ‘abc’"

Coding Interview Tips

Communicate Out Loud

“So I’m thinking I’ll use a hash map to track character positions. I’ll use two pointers for a sliding window. Let me trace through an example first before I code.”

They want to hear your thinking, not just see code appear.

Pick a Language You Know

Don’t learn a new language for interviews. Use what you’re comfortable in. (Python, Java, JavaScript, C++ all fine.)

Don’t Worry About Syntax

If you forget a method name, just say: “In real code I’d look this up. For now, let’s say dict.get()”

Interviewers don’t care about syntax—they care about thinking.

If You Get Stuck

  • [ ] Say it out loud: “I’m stuck on the optimization. Let me think…”
  • [ ] Ask for a hint: “Am I on the right track? Should I be thinking about a different data structure?”
  • [ ] It’s better to be honest about being stuck than to wave your hands

Edge Cases Matter

Always test:

  • Empty input
  • Single element
  • Duplicates
  • Very large input
  • Negative numbers (if applicable)

Round 2: System Design (45–60 Minutes)

What to Expect

You’ll design a large-scale system (like “Design YouTube” or “Design a URL Shortener”).

What they’re measuring:

  • Can you think about scale?
  • Do you know tradeoffs (SQL vs. NoSQL, caching, replication)?
  • Can you communicate architecture clearly?
  • Do you ask clarifying questions?
  • Can you estimate capacity (QPS, storage)?

The Approach

Step 1: Clarify Requirements (5 min)

Don’t assume. Ask:

  • [ ] “Are we designing for writes or reads? How many?”
  • [ ] “Do we need strong consistency or eventual consistency?”
  • [ ] “What’s the data volume?”
  • [ ] “What’s the complexity? (e.g., for a feed, do we need ranking?)”

Example (YouTube):

“So we’re designing YouTube. I’m assuming we need to handle millions of video uploads and billions of views. Do we care more about read latency (fast playback) or write latency (fast upload)? And for feeds, do we need to show the most relevant videos or just chronological?”

Step 2: Estimate Capacity (5 min)

Do some napkin math:

  • QPS (queries per second): How many people using the system at once?
  • Throughput (videos uploaded per day)
  • Storage (total GB/TB needed)

Example:

“Let’s say 1 billion users, 100M daily active users. If users watch 5 videos per day on average, that’s 500M video plays. At 86,400 seconds per day, that’s ~5,800 QPS for reads. For writes, if 1% of DAU are uploading, that’s 1M uploads per day, or ~12 QPS. So this is a read-heavy system.”

Step 3: High-Level Design (15 min)

Draw boxes:

  • [ ] API servers (serving requests)
  • [ ] Databases (storing data)
  • [ ] Cache layer (Redis for hot data)
  • [ ] CDN (for video delivery)
  • [ ] Message queue (for async work)

Rough architecture:

User -> LB -> API Servers -> Cache -> Database
                           -> CDN
                           -> Message Queue -> Video Processing

Step 4: Deep Dive on Key Components (20 min)

Pick the hard part and solve it:

For YouTube, maybe you focus on:

  • Video Delivery: How do you serve videos efficiently? (CDN, bitrate adaptation, georeplication)
  • Feed Generation: How do you build a personalized feed at scale? (Offline ranking, cache, eventual consistency)
  • Search: How do you search videos? (Full-text search engine like Elasticsearch)

For each component:

  • What data structure?
  • What database? (SQL for structured, NoSQL for flexible)
  • What tradeoffs?

Example (Video Delivery):

“For video delivery, I’d use a CDN to cache videos close to users. CDNs already exist (Cloudflare, Akamai), so we don’t build from scratch. We’d upload the source to our data center, then replicate to CDN edge servers. For playback, we’d use adaptive bitrate streaming (HLS or DASH) so video quality adjusts to network speed.”

Step 5: Discuss Tradeoffs (5 min)

Every design choice has a tradeoff. Acknowledge them:

  • SQL (strong consistency, slower at scale) vs. NoSQL (eventual consistency, scales)
  • Strong consistency vs. eventual consistency
  • Cache hits vs. cache misses (and stale data)
  • Complexity vs. simplicity

Example:

“I’m using eventual consistency for the feed because strong consistency would require checking the database on every request, which won’t scale. The tradeoff is that users might see slightly stale data (feeds updated every few minutes). For this use case, that’s acceptable.”

System Design Tips

Draw It Out

Interviewers want to see pictures. Use boxes, arrows, databases. It helps them understand and it helps you clarify your thinking.

Use Real Technologies But Don’t Get Bogged Down

Name real systems (Kafka, Redis, Elasticsearch) but don’t get lost in config. Say:

“I’d use Kafka for the message queue because it’s distributed, can handle millions of events per second, and preserves order within partitions.”

Discuss Failure Cases

“What happens if one of the video serving servers goes down? I have multiple API servers behind a load balancer, so it fails over to another one. The load balancer detects the failure and reroutes traffic.”

Talk About Monitoring

“We’d monitor QPS, latency, error rate, cache hit rate. If cache hit rate drops below 70%, we’d increase cache size or evict less frequently used items.”

Round 3: Behavioral (30–45 Minutes)

See Interview Preparation Guide for full behavioral guide.

Quick version for engineers:

You’ll answer:

  • Tell me about a project you’re proud of
  • Tell me about a time you debugged something hard
  • Tell me about a time you disagreed with a decision

Formula:

“Situation → What was the problem → What did I do → What was the outcome → What did I learn”

Focus on:

  • Technical depth (did you solve hard problems?)
  • Collaboration (how did you work with your team?)
  • Initiative (did you take ownership?)

Common Mistakes in Engineering Interviews

❌ Jumping to code without thinking

(Spend 2 minutes on paper first)

❌ Not asking clarifying questions

(Assume nothing. Ask about constraints, tradeoffs, scale)

❌ Perfect code != good interview

(Clear communication matters more than perfect syntax)

❌ Not explaining tradeoffs in system design

(“Why did you pick Postgres?” “It’s what we use at work” is weak. “Because we need strong consistency and complex queries” is strong.)

❌ Ignoring scale

(System design is about scale. Address it early)

Practice & Prep

Coding

  • LeetCode (Medium level)
  • InterviewBit
  • HackerRank

Practice: 30 problems of Medium difficulty (about 10 hours total)

System Design

  • Mock interviews
  • YouTube videos (Grokking the Interview, System Deisgn Primer)
  • Design popular systems (YouTube, Twitter, Netflix, Uber)

Practice: 5–10 system design mock interviews

Key Takeaways

  1. Understand the problem first (ask questions)
  2. Communicate your thinking (out loud)
  3. Optimize, but don’t over-optimize (good enough > perfect)
  4. Think about scale (system design is about scale)
  5. Discuss tradeoffs (every decision has a cost)
  6. Test your work (edge cases matter)
  7. Don’t give up (interviewers like persistence)
  8. Learn from feedback (if you get rejected, ask why)

Engineering interviews are learnable. You don’t need to be genius-level to pass—you need to think clearly and communicate well.

Next: You’ve mastered technical interviews. Now prepare for the full interview cycle with Interview Preparation Complete Guide or Interview Day Checklist.