I once interviewed a candidate with a degree from a well-known CS college, indicating general aptitude. I asked him a warm up question involving a BST. He solved it well, demonstrating his “knowledge” of that particular data structure. He also coded it correctly, demonstrating that he “knew” coding.
I then took it further, and gave him a problem where the input dataset required to be put into a BST in order to efficiently find a target element. He couldn’t solve that. I gave him plenty of hints, until he got it. But when he proceeded to code it, he fumbled and ended up with some basic bugs.
Nice guy, we all liked him as a person, would fit well in our work culture. But he was not hired.
He had it all: general aptitude, knowledge of DS/Algos, coding skills and culture fit. But they didn’t culminate into that most important skill of all: Problem Solving.
So how do you prepare and nail that technical interview?
1. Practice is the only way you'll get better.
You have to stick to your practice. Diligently. It's surprisingly difficult to stick to simple habits, but that's often the difference between success and failure. e.g. 2-4 hours a day to solve one or two problems is a great habit: necessary and often sufficient. But it's imperative that you actually do so several days a week for a number of weeks, rain or shine, in order to get cumulative benefits.
2. Recall is critical and you need continual feedback via mock interviews.
Interviews are not standardized tests. You can't prepare for them in a vacuum for several months and then suddenly hope to get better at the end of it all. That could work for SAT prep, but not for non-standardized tests like technical interviews, where grading is not standardized.
After every few problems/days of practice, you have to do mock interviews. Mock interviews are best done with engineers at top companies, but they can also be done with your friends and fellow seekers.
Mocks will help your recall circuitry, and give you feedback about where you stand. That will in turn, either increase your confidence, or let you tweak your practice early, if required.
3. You need to write code.
Just skimming problems and loading the solutions in your head is unlikely to be enough. Writing code is important in order to make the solutions real. When you write code, you will also discover and learn a lot of nuances of the programming language you're using, which will come handy in actual interviews and elsewhere.
4. You need to repeat the problems
Repetition deepens your understanding of problems and their solutions. Often patterns emerge only after repeating a number of problems. Obviously, repetition also improves recall and gives confidence.
5. Don't look for a magical moment of end viz. "I'm ready".
Thumb rule is to reach about 150 medium to challenging problems as your first milestone. I've seen people cross 300 also. And now even a 1000. By that time, assuming you've written code for those many problems and repeated them, you should feel pretty confident. But overall, let mock interviews guide your prep.
6. Practice with a long term goal.
Practice with a long term goal of being a better engineer. Interview problems will do that for you viz. actually make you a better coder and system-design-er. That will in turn, make your short-term goal of getting a job more realistic, and less agonizing.
And no, you’re not expected to write perfect code on your first attempt.
No, not even at top-tier tech companies. Even your interviewer is unlikely to have written perfect code at first shot in every interview. Heck, even Steph Curry doesn’t get it in the basket every time.
Now that we’ve got that out the way, here’s what you need to know. Interviews are not standardized tests, like online coding websites will make us believe. They are more like a date and less a standardized test. Interviews are also not robotic processes that we’ve been made to believe. They are a very human process which are as much dependent on the interviewers as they are on you and your preparation. And for humans, it’s practically impossible to write perfect code at first shot in all interviews. Some interviews, yes. All, no.
What is expected though is the following, which you’ll note is far more human and yet manages to maintain high standards:
- That you understand the problem without a lot of back and forth. Not necessarily at first shot, but quickly enough, and preferably by asking the right questions.
- That you articulate a solution, even brute force, with examples, quickly enough. Again, not necessarily at first shot, but quickly enough, to reinforce your claim that you have really understood the problem.
- That you improve your solution beyond brute force, to be optimal for practical applications. Again, not at first shot, but with proper thought articulation, enough logical leaps and taking me, the interviewer, along with you in your thought process.
- That you write code idiomatically in a programming language you claim to know well. Not pseudo code, not hand wavy code, but idiomatic code. Not at first shot, but quickly enough.
- That you clearly know what you know and what you don’t. If you don’t know the syntax of a function for example, then you point that out to the interviewer, make reasonable assumptions and move on. We understand that in the real world, there is going to be an IDE.
- That you find and correct your own mistakes. Again, not at first shot, but without me needing to prod you often to go back and correct it.
- If writing perfect code at first shot is not expected, then is it okay to take it easy in our prep? Not really.
Interviews do need speed, but not inhuman robotic speed. As long as an easy problem is complete within 20 minutes, a medium one within 30 and a hard one within 40, we’re good.
Are there interviewers who DO care about giving perfect working code in first shot? Yes, there are. After all, interviews are like a date. Are such interviewers in majority? No.
Relax. Prepare systematically with the right rigor and right people and you’ll be fine. We’ve seen that with over two thousand engineers we’ve trained.