Interviewing for a new job can be an intimidating and difficult experience for anyone. I’ve put together some advice based on my experience doing over a hundred interviews that should be helpful for developers of any skill level. Let me know what you think in the comments below.
Show Up On Time
You may think this would go without saying, but you’d be mistaken. Many candidates (> 50%) show up too early or late. You’ll get different answers from different people, but I’d advise not going into the interview more than 10 minutes early, preferably 5 minutes. That said, you should arrive early, and just hang out in your car or a coffee shop. You never know if you’ll run into construction, traffic, or have difficulties finding the location. If you are running late, I’d advise calling them to inform them of the delay, rather than just show up late.
Bring Copies Of Your Resume
While typically unnecessary, it shows that you’re prepared. The unfortunate reality is that many times people don’t prep for interviews in advance, and may forget to print off the resume (or they get pulled in at the last minute). Having a few copies of your resume to hand out can earn you some good will.
Research The Company Ahead Of Time
Many companies will ask you what you’ve heard about them, and having nothing to respond with is a red mark against you. Researching the company ahead of time can also help you prepare some very relevant questions to ask your interviewers, which will typically give you bonus points in the interview process. Trawl through local news, the company’s website, and their social media. 30-45 minutes of research goes a long way. Using the OSInt Framework can actually be a good way of finding out a lot about the company.
Prepare A List Of Questions
Almost all interviews will end with the interviewers giving you a chance to ask questions. While this is typically an important step in deciding if the company is the right fit for you, it’s still part of the interview process, and you will likely be evaluated based on which questions you ask. I’d recommend prepping a few ahead of time, both some about the position itself, and some about the company culture. If you can add some relevant questions based on your research of the company, that’s even better (e.g. “I saw you unveiled a new product X, would I be working on that or something different”). There are bunch of questions online if you’re having trouble thinking of some, but here are a few basics:
- What would my average day look like if I got hired?
- What is your development process like? Do you have linters, CI, unit tests, code review, etc?
- What’s the company culture like?
Generally you’d save any questions related to salary or benefits for the job offer call if you get one. That’s when you can haggle over the details. I cannot emphasize this point enough, a lot of interviewers will deduct points if you have no questions at the end of the interview process, and it may be seen as a sign that you’re not interested or engaged in the process.
Research The Interviewers On LinkedIn (if possible)
If you get an invite from the company, it may include the names of the interviewers who will be present (you may also ask for this from recruiters if applicable). Looking them up on LinkedIn (but don’t add them!) is a smart idea, and can give you an edge over other candidates. Many interviewers will list details about their current job, which you can use to ask smart questions (see above). It can also be beneficial to research the company’s top executives, CEO, and HR team. You don’t need to go in-depth, but knowing who they are and what their background is may be useful during the interview.
Even if you’re not a huge fan of programming and it’s just a job to you, acting enthusiastic during interviews is important if you want to make a good impression and build rapport with the interviewers. Avoid giving short answers, as that can come across as you being disinterested, but don’t give long-winded answers either. Try to sound excited and engaged, and make sure to focus on the interview. I’d also recommend not checking your watch or a clock, as it can seem like you’re in a hurry (even if you may be on a lunch break and need to get back by a certain time).
Don’t Be Afraid To Clarify Questions
If you’re not sure what an interviewer meant, just ask. Don’t try to bullshit your way through a question that you don’t clearly understand, it’s more likely to backfire and make you look bad. Interviewers are used to being asked clarifying questions, and it can be viewed as a positive attribute.
Be Respectful Of Interview Time Constraints
Be aware of the length of the interview, and don’t take up too much time with unnecessary information. It’s important to build rapport with the interviewers, but going too deep into your life story is typically a bad thing, especially when it doesn’t tie back to the conversation or question you were asked. If you get asked an overly broad question, it may be a good idea to clarify how much depth the interviewer is expecting. Avoid sharing too many details about your examples, since you want to respect any NDAs you probably signed with previous employers, and being overly specific about irrelevant details wastes time (e.g. focus on the technical aspect, not the details specific to the business).
Don’t bullshit the interviewers, they’re probably experienced in detecting it. If you don’t know something, tell the interviewer you don’t know (but you can follow up by saying how you’d find out). I’ve had candidates try and bullshit their way through a question they clearly didn’t know, and it was a giant red flag.
Prepare For Common Questions
A lot of interviews will recycle common questions, so it’s beneficial to have prepared answers for some of those. For example:
- Give an example of an interesting technical problem you solved (and how you solved it, what you found interesting, etc)
- Give an example of an interpersonal conflict you overcame
- Give an example of a project that failed or didn’t meet expectations and what you learned from it
- What is your favorite language, and give an example of what you like/don’t like about it (not being able to provide anything you don’t like about the language is generally viewed as a sign that you have limited experience)