I know its an old topic and a heavily debated one. There are lot of opinions on how to conduct an interview and tons of suggestions on how to be successful at software engineering interviews. What motivated me to write this piece was my own experience and what I have observed by being on both sides of the table. I hope this might help people in some way who are looking for job. This is all about the process, its strength and weakness.
First thing to understand is that HIRING IS NEVER A FAIR PROCESS, its not only about your skills but also your timing, presentation, relationship. It is easy to get rejected even after a very good interview and at the same time, one might land a job offer from an unexpected company. And then again there is this demand and supply aspect. I always suggest the rule of 20–25% success rate on an average. The thumb rule is if you apply to 100 positions then there is a good enough chance to get a HR call from at-least 20. Its not bad if out of 20 only 4 companies invite you for onsite, there is a good chance of getting one offer. It has worked out practically for a lot of people I personally know about. The important thing is that it helps you in being hopeful and optimistic throughout the process. It doesn't matter however strong you are, the rejection calls and email are demoralizing.
Job Description
Unfortunately most companies/managers/HR do not spend much time with the job description. There is a standard template that people copy from other places and inject a few terms of their own related to the project unless the position is very very specific. DO NOT GET INTIMIDATED by the skills being asked in the job description. I can bet that 99% of the times even the existing people on the team do not know more than 50% of the tech stack mentioned as required on the JD. More than often these are the keywords put in there either to make the company look promising and for better search-ability. Bottom line is if there is even 25% match in your skill set and the JD then one should apply. After all in most practical scenarios you are going to end up working with at the most 5% of the mentioned stack. Remember that if you do not do it then some one with 5% skill match would apply and get the job.
Resume — Getting your foot in
Its not a bad thing to modify your resume a little bit and add things to match it with job description. After all this is how your resume is going to be picked up by automated softwares and recruiters. Keywords like agile, scrum, micro-services, REST, AWS make the resume look better. I do get a lot of resumes and more than often I can out rightly tell how much of it is a lie but almost everyone is doing it so you do not want to miss out. In most companies the interview processes are pretty standard and seldom do they ask things directly from your resume.
Alternatively find some one who works in the company and ask them for referral. In most companies its the guaranteed route to get a HR call for sure.
HR interview
If you are lucky enough and your resume gets picked then HR is the first person to reach out to you. More than often they have a checklist which might include some questions around stack, your aspirations and compensation details. As far as the stack is concerned its best to give affirmative answers than to say no or go into technical details. Everyone knows the realities why you are interviewing but at the same time it is expected that you come up with the a good sounding explanation even if thats not really the case. In short all you need to how is how motivated you are and you do know a little bit about the company and big picture.
Online Technical Challenge
Depending on the company you might be scheduled for a telephonic conversation with the hiring manager or a online technical coding challenge (hackerank), or a take home exam or mix of these things before you are invited for onsite or next round. Even if you are good with programming it might take a while to get hold of the process and framework to write the code and submission method.
Some one told me a long time ago that there is nothing new under the sun.
So most likely you should be able to find out the answers by spending a little time on google search. Although some may call it cheating but its still the right thing to do because most likely your code is going to be evaluated on the final output of your program. Unfortunately no one is going to look at your 99% correct code if you tried to do it by your own. Just like before, there is no reason to not to do it since everyone else is already doing it.
Onsite Technical Interview
Now this is a little bit hard part if you are not handy with your data structures and writing code on regular basis. Almost 90% people fall into this bucket after being in the industry for a certain number of years. I am sure you might have come across the advices like understanding the problem, asking all relevant questions, explaining your thought process to the interview and the golden line that you are being evaluated on your approach not the solution. While it might be correct for some cases, I do know for sure that thats not how it works. In most companies the interviewees are never trained on how to carry out an interview, they might not even be matured enough to understand your approach. On the top of it, having a answer in mind blocks individuals mental ability to think of other possible solutions. The interview might be one of the most important dates for the candidate but for the interviewer its just another one hour meeting. More than often they are just going to repeat themselves with the same set of question because of three possible reasons —
a. They do not want to put in much efforts and its easier this way
b. They want to be consistent with the questions, it makes it easier to do evaluations and comparisons between two different candidates
c. The company set up the possible question bank to be on the safer side (there are always some reasons), or some think tank in the company came up with the correct set of questions.
Whatever might be the case, it does helps you as a candidate. Use it for your advantage. Ask your friends from the company or go to sites like glassdoor and others to look at the questions being asked for the similar positions. There is very probability of getting it right.
Non-Technical Interview
Not all companies have non-technical interviews but some companies might have bunch of them. Your personality definitely makes a big difference in these type of interviews. It helps a lot if you appear(reality might be different) to be a easy going person and motivated for the position, team and the company. If interviewers are seeking a candidate for their own team then they would of course give preference to some one who is easy to work with. This is applicable for the technical interviews as well.
After the interview
Always send out a thank-you email to HR at least and remind him/her how motivated you are for the position. Unfortunately the HR’s might promise some time window to get back but they are not always able to fulfill their commitment. It might be because of multiple reasons:
a. The company is too big and people do not care enough unless the hiring manager wants you badly
b. You were rejected and there is an implicit understanding that you would get it.
c. You are being put on hold until the company is interviewing more candidates or waiting on some one else.
In all the above cases keeping the communication channel active is really important. Even if you were rejected for that particular position the HR might work on finding more positions for you in the same company. Also the companies are more inclined to hire some one who is really motivated to join and stay once they accept the the offer. So it would be really good for you if you can put that into your words and communicate to the HR and hiring manager.
Lastly I would just reiterate the easy going part once again. Remember no one wants to go all in or all out when all the interviewers are asked to submit their feedback (either verbally or in writing). Most interviewers are going to submit it in may be yes or may be no language unless you are really off the chart. The easy going nature displayed during the interview and keeping the interviewer happy/satisfied can be the difference between may be yes and may be no.
DISCLAIMER : As a candidate myself I do things in a completely opposite manner. Mainly cause I am lucky enough to always find a job easily. However this cheat sheet works all the time based on the interviews I have conducted. At the end of the day most people are capable of doing the job.
