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.

First, some background to add credibility. In college, I applied for internships at Google, MSFT, Amazon and Goldman but did not get into any of them. A year later, I applied for MSFT, Uber, Goldman and got offers from all of them. A year after that, I got an 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. You do this 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 or wasteful. In-fact, I recommend it. However, the reason to do that is not to memorize solutions. Instead it is to identify common patterns within solutions 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. How 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, a lot, but how you get there counts just as much.

There's lots more to job interviews. I am planning to write regularly on topics involving Software engineering. If you'd like to have access to that, consider subscribing to http://piedpiper.substack.com  . If you found this useful, please RT so this reaches more people.