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:
- requirements clarification
- what problem is this system trying to address?
- system interface design
- define read/write API specifications (at a high level)
- back-of-the-envelope estimation
- number of requests/second
- quantity of data I/O (in flight, on disk)–media files (text, image, video)
- defining data model
- entity-relationship diagram between them
- uniqueness constraints
- numerical integrity (integer vs. floating point data truncation) when dealing with $$$
- 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)
- 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.