Lots of aspiring Software engineers work hard to excel in the coding interviews. They spend hours after hours on Leetcode or reading up on Data Structure and Algorithms but end up without the job offer. I think a majority of the preparation strategies are fundamentally flawed.
First, some background to add credibility. In college, I applied for internships at Google, Microsoft, Amazon and Goldman Sachs but did not get into any of them. A year later, I applied for jobs at Microsoft, Uber, Goldman Sachs and got offers from all of them. A year after that, I got a job offer from Google.
For most tasks, Output = Input * Efficiency. Most people try to optimize for Input by working hard. But, what you really want to optimize is output. And there’s a ceiling to the amount of Input you can put in. You maximise your Output by working smart, i.e, improving Efficiency.
For example, people try to solve lots of problems with the hope that they’ll see the same problem in an interview. This is a sub-optimal strategy. Most interviewers are armed with tweaks to the problem as follow ups and are good at identifying if you have the solution memorised.
Solving lots of problems isn’t bad. In-fact, I recommend it. However, the reason to do that is not to memorize solutions. Instead it is to identify common patterns across problems which are extensible to a larger set of problems.
Do not memorize how to find the maximum of the sum of values for all root to leaf paths in a tree. No one wants you to do that. Instead, understand how and why Dynamic programming (DP) works and learn to recognise the situations in which DP on trees can be helpful.
There are countless resources on the web to help you understand these concepts. Most programming platforms these days allow you to group problems by these concepts. Once you think you understand them, try to see if you’re able to solve problems that involve these concepts.
Another key mistake I see on the part of candidates is failure to calibrate themselves, i.e, evaluating the effectiveness of their approach during preparation. This is crucial to know if your countless hours of effort is turning into meaningful output.
Do this by involving a friend and scheduling mock interviews. Try to ensure the setup resembles actual interviews as much as possible. Take notes on which aspect requires attention and focus to train harder on that. Then iterate on this whole process again.
Interviews are stressful situations for lots of candidates and the stress can lead you to be off your game. Mock interviews help you get some early experience of that environment so that you’re comfortable when the real thing comes along.
Finally, Job interviews go beyond just code. The way you approach a problem is important. Interviewers are looking at how effectively you communicate to resolve ambiguities. Making rational trade-offs in solutions is critical. End result matters, but how you get there counts just as much.
This content was originally posted as a Twitter Thread.
Lots of aspiring Software engineers work hard to excel in the coding interviews. They spend hours after hours on Leetcode or reading up on DSA but end up without the job offer. I think a majority of the preparation strategies are fundamentally flawed. A thread. 👇
— Pratik Mishra (@pratikmishra001) October 18, 2020
Building for scale @ Google.
Problem solving is more about the problem than the solution.
