Prepare for Technical Interviews
Those who are seeking a job: Please prepare for your interviews
I reach out to candidates weekly and have several discussions around the opportunity and growth that is available and I usually see a lot of excitement and interest in return. This is great, but this has not really translated to a good hiring rate. The primary reason for this is the lack of preparation that the candidate has put in before their onsite interview. Please do understand that just because a company has to grow fast (in some cases double their size), it does not mean they will reduce their hiring bar. You will need to prepare really well if you want to land a job in a company. Here are my views on some of the rounds that will happen for a tech screen.
Problem solving / Data structure: This round usually tests the candidate’s ability to solve the given problem using appropriate data structures. Think through the problem given and do not write code within seconds of the problem statement ending. ’Solve’ the problem first, question and discuss the assumptions you have made, a good discussion with the interviewer is always appreciated, and then get to writing the code. Use the right data structures and always think about scalability and maintenance. You should almost expect the interview’s next questions to be in the line of “What is the time / space complexity?”, “What happens if the problem set is larger?”, etc. Take the hints given to you and see how to improve your solution. The number of tech problems that you can use to prepare yourself is limitless, a simple web search will give you a host of problems to solve, take time before or after your office hours to work on them.
Machine Coding: This may not be a common occurrence but many companies will expect you to code up a solution on a laptop. What they are looking for is a code that compiles and executes to give the output of the solution. This could be an offline assessment or one of the first rounds in a face-to-face interview. Considering you are applying for a developer position, this is a reasonable ask, and should be easy enough if you do this for a living. Try to focus more in your current job on every single line of code that you are writing, it’s easy to copy paste and change existing flows to achieve something new, but ask yourself: “Is every single line needed?”, “Can I refactor to solve this at scale?”, “If I leave the company, will someone else be able to make sense of this code?”, etc. Such questions will help you not only improve your solution but also prepare for interviews. Also follow the tips mentioned as part of PS / DS above and you’re good.
Design: If you are experienced developer, you should expect a design question. The difficulty of design will depend on the hiring manager and interviewer based on what role they have open. Most people say “There is no right or wrong in design”, but I disagree. There is not a single solution for design as there could be multiple ways to approach the problem but there are several wrong designs. I have found http://highscalability.com/ a very good source to study designs. Study some real world examples of how companies have designed solutions for challenging problems, and understand why they went that route and the benefit it got them. This will get you thinking on various parameters that need to be considered to come up with a good design. One key aspect is to be able to defend your design, bonus points to knowing the limitations of your design which means you have thought well and may be capable of working on the limitations given enough time.
Hiring Manager: Your mileage may vary here but these rounds are sometimes the trickiest or the easiest. A precursor to this interview is to know what’s on your resume…inside out. Most hiring managers will drill into specifics for a project: “Where did the need come from?”, “What was your contribution to the project?”, “What metrics did you monitor to measure success of your project?”, etc. Pay attention to when you use “we” vs “I”. A project can be executed by the team and you will have a part to play in it. Acknowledge both, experienced managers will sniff out where you are claiming responsibility for something that your team did. Another set of questions could be around team fit and culture. I have not known a company who hires rock stars who cannot work with anyone in the team. Behavioral questions are just as important to clear as technical questions. “How will you deal with X situation?”, “What if someone opposes the design you have presented?”, “What if you are the QA do not agree on the priority of a bug?”, etc. are some of the questions I frequently ask to gauge your engagement with the team and how you can deal with different situations. Use your experience (all of it, don’t limit to just recent projects) or tell them how you would handle this hypothetically.
These are my personal views and I hope this proves useful to some of you and helps you prepare better to clear interviews. All the best!
Very well written and completely relevant! Kudos to your efforts for putting it up together.I hope people read it and get benefitted - not just the job seekers but also the interviewers.
>>people say “There is no right or wrong in design”, but I disagree. There is not a single solution for design as there could be multiple ways to approach the problem but there are several wrong designs. :thumbsup:
If they need to "prepare" for an interview, you are not judging their natural disposition, which is what will play in day to day work. The interview should be designed so as to judge whether they will be able to carry out their day to day work. If they have to "prepare" for it, the very purpose of the interview is defeated and you will be hiring people who won't deliver. Instead of telling how to prepare, I think you should fix the interview process itself. I usually reject the companies which need any "preparation" since I know both of us are going to fail in the end even if I "succeed" in bagging the job.
Those people who are rejected should remember and memorize a bunch of algorithms and concepts from their college time to succeed otherwise isn't that true that a lot of them are senior developers who have been doing software development everyday for so many years?