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.

The postings on this site are my own and don't necessarily represent my employer’s positions, strategies or opinions.

© Mr. Max, 2019