So you’re going to your first dev job interview, eh?

Mikko Tiainen
Houston I/O
Published in
9 min readJun 2, 2020

Job interviews are stressful, especially when you’re applying for your first job. I was looking for a new job as a developer two years ago. Besides software development, I have a background in psychology and brain research. I’ve been on both sides of the job interview table (although I haven’t been an interviewer for dev jobs) and don’t really stress too much in job interviews, so I thought I could share some thoughts on how to handle a job interview so others wouldn’t find them so stressful as well.

Disclaimer: I’m Finnish and was looking for a full-stack dev job in a Finnish software consultancy firm. At least in Finland, the job market for developers has been pretty much in favor of the employee, so I’m writing this from a rather privileged point of view.

If it’s a technical interview, you can for example throw a curve ball by asking the interviewer a technical question in a light-hearted fashion.

The interview is a two-way street

First things first: the interview actually goes both ways. It’s not just you as the interviewee on the spot, but you should also take this a chance to interview the company as well. So think beforehand what are the important things to you in a job or workplace. Ask how these things are handled in the company you are interviewing at. Do they have lunch benefits, how’s the healthcare, etc. Asking about the work itself is also critical. What kind of clients/projects do they have? What technologies do they use? Gather information so that you can properly evaluate if this is the right job for you. This will also show the interviewer that you are serious about the job and have thought about things.

Read about the company ahead of time. Try to get at least a general understanding of what they do and what they could have to offer for you. I’d consider this pretty much a common courtesy. They have taken the time to read your cv so making yourself familiar with the basics of the company is the least you can do in return. I had a personal experience with one job that I was interviewing for where I hadn’t studied the company enough beforehand. We were talking and I said I had noticed that they also do some data science stuff and that I would be interested in expanding my knowledge towards that area. The interviewer basically said that yeah, they consider the data science branch of their company one of their biggest selling points and that they are one of the biggest operators in that area in Finland. I could see that he was disappointed that I didn’t know this about the company while claiming to be interested in data science, and it did make me feel like a bit of a fraud.

Be proactive and not only reactive. Take the initiative occasionally to drive the conversation.

Think also about your plans for the future. A classic question is “where do you see yourself five years from now?” So think about it. Usually companies look for a person who will stay with them for some time, so they want to know if your future plans are something that could be achieved at that company. If you for example respond with something like “In five years I would like to be living a quiet life in Australia as a cow farmer” that’s probably not where a software company wants their developers to be heading to.

Be proactive and not only reactive. Take the initiative occasionally to drive the conversation. If this seems hard to do spontaneously, you can think of something ahead of time. If it’s a technical interview, you can for example throw a curveball by asking the interviewer a technical question in a light-hearted fashion. I found it fun to ask whether they knew the difference between apply and bind in javascript (spoiler, not many people know this from the top of their head). It’s a bit of a silly thing, but something like this makes you more memorable and helps you stand out from the crowd. Be careful though not to sound arrogant or pushy. The interview is a two-way street, but the interviewer should be the one in charge.

Then there’s the question of salary. That’s always a tough one. You should have some salary estimate to bring to the table. But how do I know how much to ask? You can ask around from friends if they know anyone who works at the company and could give some approximation about how much they pay people. You can also search online for the salaries of people in similar positions. It doesn’t have to be a number set in stone, and it’s better if it isn’t so that you’re open to negotiate. But make sure that it’s a number that you’re okay with. So when they suddenly say: “Yeah that sounds good for us”, you don’t respond with “actually how about €500 more?” You can probably tell how that doesn’t sound good to the interviewer. Giving a salary request gets easier when you interview for several places and have already gotten at least one offer. You can then just state that “Well, I have already received an offer for €3000 a month, so I hope you could at least match that.” If it’s more than they can pay but they really want to hire you, they will make a counter-offer.

Don’t schedule interviews where you know you won’t take the job, it will only generate bad karma.

About the interview situation

The interview situation itself is something that the applicant doesn’t have much control over, but it’s good to keep some general ideas about it in mind as well. The interview is arranged for you. It costs money for the company to conduct interviews. So it is in their best interest that they don’t arrange them uselessly and obtain as much information as possible about you during it.

So since you are being invited to an interview, it means that they consider you as a potential candidate. Be appreciative of the situation and try to make the most of it for both parties. Don’t schedule interviews where you know you won’t take the job, it will only generate bad karma.

When you arrive at the interview, be punctual. Don’t be late but don’t also arrive an hour too early. Companies don’t necessarily have a specified waiting area where you could wait and they probably don’t want a stranger loitering around their premises without supervision. During the interview pay attention to how you present yourself. Sit up straight and don’t fold your arms. Slouching gives a lazy impression and folding your arms a negative/closed off impression. Small things, but the way you present yourself makes a big difference especially to how people implicitly view you. However, don’t force things. If you don’t naturally smile a lot, don’t force it. People will likely notice that you’re tense or that something feels off and become wary of you.

Pay also attention to the body language of the interviewer(s). There is a thing called mirroring where you subconsciously mirror the movements and postures of the person you are talking to. This is a sign that you are invested in the discussion and this also makes both participants feel afterward that the discussion went well. Beware of mirroring intentionally, because if the other participant notices that you are copying their movements, it will have the converse effect and potentially ruins the whole interview. This is why I would only suggest you pay attention if the interviewer is mirroring you since this would imply that they are invested in the discussion and enjoying it, which may help alleviate your anxiety about the interview.

Almost all dev job interviews also include a technical interview (or portion). During this you might be asked to code something alone, pair program something with the interviewer, present a project you’ve made, describe a potential technical solution for a given problem, or something else. It depends on the company, interviewer, and the job you are applying for. I wouldn’t put extra effort into practicing for the technical interview unless it’s been a long time since the last time you have written any code. Rather, I would recommend you practice articulating your thought process. In a technical task you must know how to tell why you are doing what you are doing. You might be doing the correct things, but unless you tell the reason why you are doing them, the interviewer has a really hard time knowing if the motives driving your choices are correct. There’s a big difference between using a function because it’s the only one you know, or because it’s the best one for the situation.

We are all only human and everyone makes mistakes.

Lastly, not all interviewers are professional. This is just the (sad) truth and could be the reason that an interview feels stressful or otherwise uncomfortable. There’s really nothing you can do about this but try to be understanding if, for example, a developer conducting the technical review isn’t doing very well in creating a relaxed atmosphere. Sometimes this inexperience can manifest itself as weird or pressuring questions. There can be a legit reason for these questions as well, such as trying to find out how you function in sudden pressuring situations. The advice is the same in either case, try to stay calm and articulate your thought process, and don’t be afraid to admit if you don’t know something. We are all only human and everyone makes mistakes. This is true also for the interviewer, so sometimes they may mix your information or have Java assignment prepared for a front-end guy. It happens. Try to make the best of these situations, you will probably score extra points for being flexible.

Be honest

This might be the most important tip: be honest. This post is not about making a CV, but here’s a tip for that as well: don’t lie in your CV about your skills. Don’t lie about them in the interview. Saying that you’re an expert on Docker when you’ve built one container after watching a Youtube tutorial is only going to get you in trouble. In the best case, you get caught on the exaggeration during the interview which will make you seem untrustworthy and likely cost you the job (for probably a good reason). In the worst case, you won’t get caught on it during the interview and do get the job where they then expect you to actually be a Docker expert. Then when the truth starts to get out, you will be more of a hindrance to your teammates and source for internal conflict when your teammates/managers can’t trust you with the work that you were supposed to do. At this point, the lie isn’t only causing trouble for you but to a whole lot of other people and their work as well. Instead, be honest. Say that you are not an expert with Docker, but know the concept and have done some tutorials and are eager to learn.

But again, too much is too much. Don’t be rude or arrogant. If the interviewer says that you’ll be mostly working with Java 6 servlets and jQuery when you were expecting Go and React, don’t respond with “Good luck breathing life into that kind of piece of crap”. Just say that it sounds like a challenge and that you’re not too familiar with those technologies.

Summary

Interviews can be stressful, and a small amount of stress is probably a good thing to keep you alert during the interview. Just make sure it keeps at that level. Here are some key points that I have outlined above.

  • The interview is a two-way street. Take the chance to also ask about what the potential employer has to offer for you.
  • Prepare for the interview by reading about the company and plan out some key answers like a salary request and your plans for the future.
  • The interview is arranged for you, so if you get an invitation for one, you have a chance to get the job.
  • Be on time and pay attention to how you present yourself, pay attention also on the behaviour of the interviewer.
  • In the technical interview, pay attention to articulating your thought processes, this is even more important than what you actually manage to get done.
  • Be honest. Don’t lie about your skills, it will only cause you trouble sooner or later.

I want to conclude with the age-old saying ‘practice makes perfect’. So when you’re looking for a new job, I would suggest you try and find as many potential positions as possible and take your time trying to find the best one. Your interview skills will grow in the process.

--

--

Mikko Tiainen
Houston I/O

Software developer, psychologist and brain researcher. I like making things.