Skip to content

interviewing

Jump to bottom
dozens edited this page Nov 7, 2025 · 4 revisions

Interviewing

Formats

Technical interview formats I've had, ranked in order of preference.

  1. I get to use my own computer, editor, environment, etc to do a task. Ultimate comfort and familiarity.

  2. Coderpad: a web IDE that I can be in control of.

  3. Taking control of somebody else's screen and using their text editor. I don't just not know their editor shortcuts, I feel crippled without my own.

  4. Whiteboarding

  5. "Coding" in Google Docs

Systems Design

Architectural, Systems, Design, etc

There are a couple of different "system design" interviews:

  1. Product Design: Build Netlfix
  2. Infrastructure Design: Build a Key Value Store
  3. OOP Design: Build a vending machine
  4. Front End Design: Build a spreadsheet application

Most places mean Product Design

src: https://www.hellointerview.com/learn/system-design/in-a-hurry/introduction

A System Desgin Rubric:

  • Problem solving / navigation: break a problem down, priortize the most important problems, don't get stuck, time management
  • High Level Design: have a coherent solution that fully answers the problem, addresses scaling and performance, demonstrate understanding of core concepts
  • Technical expertise: know best practices and key technologies and how to apply them
  • Communication and Collaboration: communicate concepts clearly, work with the interviewer, ask questions, don't get lost in the weeds, be agreeable and not argumentative.

A delivery framework:

  • Requirements (5 min)
    • Functional: "The user should be able to...."
    • Non-Functional: "The system should be...."
  • Core Entities (2 min)
  • API or Interface (5 min)
  • Data Flow (5 min) Just make a short list instead of a whole Sequence Diagram
  • High Level Design (10 - 15 min) Time for boxes and arrows
  • Deep Dives (10 min) HARDEN
    • Non-Functional Reqs
    • Edge Cases

API Design:

POST /v1/toot
{
  "body": string
}

GET /v1/toot/:tootId -> Toot

POST /v1/follow/:userId

GET /v1/feed -> Toot[]

High Level Design:

.PS
down
[
  right
  box "client"
  arrow
  Gate: box "API" "Gateway" ht 2
  arrow
  box "Toot" "Service"
  arrow
  circle rad 0.5 "Toot Db" "(Postgres)"
  move
  "Toot" "id" "authorId" "text" "media"
]
.PE

Core Concepts:

  • Scaling
  • Locking
  • Indexing
  • Work Distribution
  • Data Distribution
  • Blob Storage
  • Communication Protocols
  • Security
  • Monitoring

It is important to budget your time, and to have a reliable framework:

  1. Introductions. <5 minutes
  2. Define the Problem: What is in scope? What is out of scope? What are the functional requirements? (Are you building from scratch? Who are our users? Are we communicating with other systems?) What are the non-functional requirements? (Business requirements, user experience, availability, speed, reliability). 8 minutes
  3. High Level Design Diagram: What are the high level components and how do they interact? Resist the urge to deep dive. That's coming up next. Design some APIs. 15 minutes.
  4. Design Deep Dive: how do non-functional requirements inform your decisions? Speed, load balancing, availability, etc. 15 minutes.
  5. Bottlenecks and Scaling: Is it robust? Is there a single point of failure? Can it grow? Global availability? Peak hours / hot users?. 7 minutes.
  6. Wrap up: Summarize. List decisions and trade-offs. 5 minutes.

TIPS:

  • State your Assumptions
  • Periodically check that you are on track, that you are answering the stated requirements
  • Explain Why
  • Remember: you are being asked to solve a problem in ~45 minutes that should take a team of engineers a month to solve.

src: https://www.youtube.com/watch?v=L9TfZdODuFQ

Architectures

  • Microservices
  • Spoke and Hub
  • Layered (MVC?)
  • Event Driven Architecture
  • Client Server
  • P2P
  • Hexagonal (Ports + Adaptors)

Links and quotes

A new study from North Carolina State University and Microsoft finds that the technical interviews currently used in hiring for many software engineering positions test whether a job candidate has performance anxiety rather than whether the candidate is competent at coding.

- https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

When you’re placed in a high-stakes, time-pressured situation, like live coding, your brain reacts exactly like it would to any other threat. The amygdala gets activated. Cortisol levels spike. Your prefrontal cortex, the part of the brain responsible for complex reasoning and working memory, gets impaired. Either mildly, moderately, or severely, depending on the individual and their baseline stress resilience. - https://hadid.dev/posts/living-coding/

Clone this wiki locally