December 01, 2019

The Case Interview (of Software Engineering)

Software engineers have two jobs:

  • their day job
  • their preparation for job interviews

These two jobs do not overlap much.

Preparing for the job interview (separate of preparing for the job) is a valuable activity for software engineers, as it can directly improve your chances of getting the job in the first place.

Given that, I can share from personal experience that the “system design” interview has risen in popularity for software engineering jobs.

Much like consulting firms and case interviews, system design interviews are evaluating:

  • your communication abilities,
  • your information-seeking abilities,
  • your ability to discover constraints of a problem and find a solution that accounts for the constraints

There are a ton of free and paid information resources out there online for helping you prepare for the system design interview.

Specifically, Facebook coaches job applicants (which I was at one time) on how to prepare for these interviews.

They even pay for an online course curriculum that you can study as a job applicant.

To the best of my ability, I followed the interview prep course that Facebook provided and took notes below.

The course lays out a framework for presenting your solution to a system design job interview question:

  1. requirements clarification
    • what problem is this system trying to address?
  2. system interface design
    • define read/write API specifications (at a high level)
  3. back-of-the-envelope estimation
    • number of requests/second
    • quantity of data I/O (in flight, on disk)–media files (text, image, video)
  4. defining data model
    • resources
    • entity-relationship diagram between them
    • uniqueness constraints
    • encryption?
    • numerical integrity (integer vs. floating point data truncation) when dealing with $$$
  5. high-level design
    • draw a system diagram
    • sketch how requests flow through the system and the system’s components (e.g. load balancer, app-server, database)
    • draw element of the system proportionately to cost/”size” (e.g. traffic, # of instances)
  6. detailed design
    • is the system usage uniform? Or spikey?
    • pros/cons of sharding, what to shard by (time? tenant?)
    • optimize for reads or writes?
    • what to cache and how cache is managed/designed
    • how to monitor our system’s performance at different points

Now the real question: did this course improve my perceived performance to my interviewers vs. not having consumed this content?

It’s hard to say, but I think so.

Demonstrating familiarity with the system design format shows that:

  • you are taking the process seriously
  • you are a competitive candidate for roles at other employers
  • you might be an effective interviewer of candidates yourself, after you are hired

In conclusion, I would recommend preparating for the system design interview format in your softare engineering job search.