Interview - Driving Signals: Technical Practice

There are two main aspects of technical interviews to practice for. The first is execution, and the second is everything around your execution, such as collaboration, perception, etc. While it’s possible to holistically practice all these at the same time, it’s often more effective to target them separately.

Practicing execution

Leetcode (algorithmic) questions are the most common at all early career level interviews, but they’re not the only type of interview you’ll encounter at top companies. Rounds such as Object oriented design (OOD) and Systems design are becoming more and more common. We’ll still cover leetcode style interviews first, but feel free to scroll down to sections for OOD and Systems design.

Leetcode/Algorithms

First and foremost, a baseline skill at leetcode-style problems is required. No easy way to sugarcoat this - the vast majority of people are best served by first reaching a level of leetcode (or general algorithmic) competency before focusing on other skills.

This typically means following a leetcode-style programme to fill in the gaps, especially when it comes to concepts not covered through your comp sci classes (which, by the way, is time efficient to pay attention in class for 99% of students I’ve mentored).

Self studying leetcode is the more common route, however much you pay attention in class. Resources like neetcode’s roadmap and blind75 offer well known standards that are common benchmarks, but keep in mind that completing problems is not a good indication that you understand the underlying concept. The key to scaling your knowledge past simply memorizing problems or themes is to take the time to study alternate solutions, follow up questions, and think about other tradeoffs that can be made. We may add more details about effective leetcode prep in a separate section

Object oriented design

OOD questions are a style of question where the goal is typically to implement classes and functions which solve the given specification. The priority is usually clarity and correctness instead of algorithmic optimality, which is quite different from typical leetcode rounds.

The most effective way to practice this, besides writing real code and getting it reviewed (not easy for just personal projects), is to purpose-built sample programs following common OOD questions. You can find these sample programs abundantly online, but a few sample ideas to get you started:

• Implement the API for a vending machine. Support common user flows, such as inserting cash, selecting a cell, dispensing the item, and giving change.

  • Make the vending machine track whether it is capable of giving exact change - warn the user if it can not.
  • Accept credit as a form of payment
  • Allow an alternate flow of the user selecting the item first before putting in cash

• Implement the API for a currency exchange business. The company can add supported currency pairs for conversion, dictate the rate, and fund the accounts. Users should be able to retrieve a list of accepted input currencies, and given an input currency, retrieve a list of output currencies. The user should then be able to select a currency pair and deposit money, and receive the corresponding funds.

  • What if the currency pairs were unidirectional?
  • Allow the user to convert currency using intermediate currencies (e.g., {1A -> 1B, 1B -> 3C} shall allow a conversion of 1A -> 3C.
  • What if different currencies had a minimum amount before allowing for conversions?

The skill to practice here is to come up with the right data structures to represent the problem space. This includes data classes, helper classes/methods, and other supporting data types that you’ll need. Practice using modern language features to gain a time advantage here; for example, you should use Records in Java and Dataclasses in Python. Similar to mock interviews for leetcode, you can conduct these with friends and classmates as well. Ask follow-up questions about the correctness, ask about time and space complexity (not a priority, but they should still be able to figure out which parts are slow/heavy and could be optimized). A good proxy for whether a solution is extensible and clean is how easily it can accommodate (reasonable) changes to the spec. See above sample problems for inspiration.

Systems Design

Systems design (aka System design) are not as common for early career folks, but since top companies are starting to ask these questions even for interns, it was worth including.

These interviews are difficult to prepare for if you have no prior experience designing systems, but there are still a few pointers to give.

Firstly, if you have the chance to work professionally, that’s by far the best opportunity to learn about systems. Be curious about how things work, why things don’t break (or even better, do break!), how and why choices were made, and what others think the weak points are currently. This insight, when motivated, is a far better learning resource than self preparation where there is little to no oversight and discussion on your own conclusions. It also looks really good when interns and juniors go above and beyond to learn about the designs in place.

That being said, there are still a few strong resources to study up on for the purposes of interviews. Primers such as this one give a good overview as to the process of answering common questions. The key points to practice are to recognize types of technologies and how they fit in (for example, how databases are typically queried, where load balancers are located, etc), then apply that theory to sample problems.

Mock interviews are also the best resource for practice, but unlike algorithmic or OOD, system design mocks greatly benefit from an experienced interviewer to give accurate and actionable feedback. It’s often painfully obvious to experienced engineers when someone hasn’t used a particular technology in depth. That being said, you can still go through the paces with an inexperienced mocker and get the flow and timing right for when you do have the chance to mock with someone more experienced.

Frankly, if you haven’t used technologies common in system design, you’re almost certainly better off making personal projects that leverage such technologies. Name dropping in a real interview might be fine on paper, but you won’t have the experience to justify the choice. See the personal projects section (coming soon) on how to pick what projects to prioritize for the purpose of learning software systems.