Coding interviews are a daunting experience.
Beads of sweat drip from your palms, and your mind ricochets everywhere.
How do I solve this problem?
Will my approach handle all edge cases?
How many minutes are left?
Whats the facial expression of my interviewer?
Its not an easy experience.
You should spend around 5 to 20 minutes on this portion.
Typically my game plan involves drawing diagrams and doing test examples.
More importantly, drawing these trees highlights any logic I may need to perform, such as backtracking.
Coming up with a game plan has several advantages.
First, the interviewer can inform you if you are heading in the wrong direction.
If so, you just saved yourself 30 minutes from writing all that wrong code!
Second, it is easy to pinpoint what data structures and variables will be needed to solve the problem.
It’s free, every week, in your inbox.
This tends to be the downfall of numerous interview candidates.
I am stressing about this skill because communicating effectively landed me a job offer at a top company.
During that onsite interview, a senior engineer asked me a difficult dynamic programming interview for a 45-minute session.
I drew out a 2D matrix and the different states in the matrix.
However, I was stuck the longest time in expressing the correct recurrence relation.
I would explain why my recurrence relation was wrong and discuss approaches to refine it.
I communicated every step of my thought process.
At the end of the session, I had a defined recurrence relation, but no code was written.
The whole entire whiteboard was filled with a bunch of matrices and arrows.
As I walked out of the interview room, I was confident that I failed that interview.
I would have bet my whole life savings that I failed.
A few days later, I got a call that I got the job.
So when do you should probably communicate?
you gotta communicate
3.
Always test your code
It is a rewarding feeling once you write out the final line of code.
You feel accomplished for solving a difficult problem under pressure.
However, you have not crossed the finish line yet.
Not testing your code is not abiding by the most fundamental practices in software engineering.
No one writes perfect code on the first try.
You always need to validate your code to gain and maintain the trust of your customers.
check that to communicate during the testing portion.
This will determine which game plan to come up with.
You should pose these types of questions to your interviewer:
How can asking this be helpful?
For instance, lets say the task at hand is to find a target number in an array.
The nature of the input can change the approach to solving the problem.
It is okay to ask for guidance from the interviewer.
It means you are still an independent thinker with the right guidance.
However, you do not want to keep asking for a lot of help.
You do not want to seem you are incapable of problem solving.
A good safe number of hints to use is 2.
Going more than that may drastically lower your chances at getting the job offer.
Extra tip: Study Leetcode effectively
Doing more leetcode problems will not help you get a job.
It is not a numbers game.
You should not just memorize every leetcode solution out there.
What you should be focusing on is the techniques and approaches.
A lot of times, these techniques can be applied in other problems as well.
Trust me, I had my fair share of it.
It is not an easy process.
It is a draining process, and sometimes it can get depressing.
No one told me any tips and tricks to succeed in the interview game.
I had to go through countless interviews to come up with the best approaches in succeeding in this game.
I hope my tips can at least help someone out there get his or her dream job!
yo reach out to me if you do.
Thisarticlewas written byYen Huangand originally published onTowards Data Science.
Yen is a software engineer at Twitter.
He works on the Messaging team, maintaining and improving pubsub systems.
He has worked with numerous clients on ramping up their technical skills for jobs with over 400 client sessions.
