Software developer interview

István Kovács
Jun 1, 2020 · 11 min read

I interviewed over a hundred IT people during the past 10+ years with the purpose of finding new colleges who fit into the team and I can work with as a manager. Of course I made some bad decisions along the way… but overall I was able to hire good candidates for the roles.

Approach

In my opinion I have a partially structured thinking with all of its pros like managing mess and cons for instance hardly following certain rules or adopting structures. As a result on the interviews in about 40% strict rules are followed while the rest of the interview is adapted to the skill set of the candidate and the profile we are hiring for.

Keep in mind that there are national/cultural characteristics of how the interviews are handled, for instance people socialized in the UK used to ask the same questions from all candidates. Expect that the candidates are dressed well which mostly means tie (tie holds the head in place!) and know something about the company when you arrive. The technical questions are straight to the point, mostly about experiences, seldom lost in details. Socializing only happens at the end of the interview if it happens at all.

Nordic people are more easy-going on interviews. They are much more interested in personality than people for the USA or UK and it is ok to socialize, tell short stories or laugh. Personality and experience matter the most.

Hungarians are a little bit also different. As an IT people you have high chance to apply to a service center owned by a foreign company where the interview technic and process are inherited from the owner, especially at large enterprises. The technics can also come from the experiences of the interviewer what he gathered at previous workplaces he was employed at (probably large foreign enterprises). This means that it is very much a mixture that you will face with. Because the interview mostly depends on the interviewer, you can’t really prepare.

Defaults — as an interviewer

You must not do any interviews alone. At most of the companies, this is a policy and it is not without reasons. First it is hard to ask and to listen at the same time especially if you would like to observe the meta communication (body talk) and immediate reactions as well unless you are a little bit sensitive to kryptonite.

Second reason is that you don’t know the other party so you have no clue what you can expect from the candidate. He/she might become aggressive during the interview or sue you after that for some reasons. It never happened with me, but it is also true that in 99% of the interviews I wasn’t alone doing it.

Of course a big S on your chest helps in this case as well.

Behavior and questions

Do me a favor: never do stress interviews. It is the most pointless thing that you can do when you would like to hire someone for your IT team. The candidates are stressed anyway on the interviews and the level of stress used to be high enough even to block them from answering correctly to certain questions. Putting more stress on the candidates may just highlight that the your workplace is absolutely unhealthy where the stress factor is high.

The default behavior on the interview as an interviewer should be calm, professional, little bit social or funny when the candidate is over stressed because you should be interested in his knowledge and values, what he can add to the team work on a day-to-day bases.

The goal of the questions is to get a picture about the capabilities and personality of the candidate.

The questions are not for showing the candidate how smart you are!

Once I participated on an interview for a project server consultant “position”. The fun part was that the guy seating in front of me just got his MS SQL Server Master certificate from Redmond and he wanted to show me how smart he is. It is a mistake! In this specific case the below mistakes were compressed into the two hours I spent there:

  • The company did the interview was looking for a Project Server expert and all technical questions were around SQL Server due to the knowledge of the interviewer.
  • The goal of the interviewer was to make himself proud of his own knowledge. (I know a lot about SQL Server, but for sure he knew more.)
  • The company requested the interviews wanted to get consultants from the company where I worked, but they were just cheating.

The fun part of the situation was that I called my colleague who had a scheduled appointment for the next day and just told them the questions and the right answers as I had no doubt that any of us could do the work anyway. On the other hand it was a large US origin investment bank so it was expectable that they will at least start with the same questions.

A week later my colleague got a job offer from the company and of course they didn’t want to get any consultants.

If you are interested in the knowledge level of the candidate in a certain subject, follow a staged approach. You can start with a basic question and go into the details question-by-question. When the candidate will not be able to answer even after some helper questions you need to switch to another topic as you already found the level of knowledge of the candidate.

Tricky questions

There are some crazy ideas about good/meaningful questions that some people still used to ask like the below.

What type of animal would you be?

Before you ask a question, always think about what you can do with the answer. Without being a psychologist (or wearing a tight blue dress), you won’t ever be able to evaluate the answer to the question above, so please don’t ask anything like that.

Just for the records, my default answer is wolverine, because I like X-Men.

Solve my problem

Some interviewers used to be quite rude and used to ask questions about the subject he is working on and probably struggling with. This is a no go! The candidate is not your paid resource (oh how I hate this word…). If the candidate will notice that you ask him to solve your own task he may get upset or just leave. The only thing you need to remember that this is unfair.

Number of rounds

How many interviews should you have before the final decision? Today when the IT job market is still quite saturated almost everywhere in Europe I propose to have two. One “technical” and one I used to call “management” interview mostly about experiences and personality. Make both interviews happen in a two weeks long period of time and also issue the offer within the period if the person is capable of doing the job.

The problem with having more interviews that it takes long so you may loose your candidate as he may have another offer in his pocket already AND please be honest: What else can anyone ask which weren’t clarified on the first two occasions? If the only difference on the interviews is just the interviewer, but the questions are about the same, you just highlight that you don’t talk to each other. Once I was able to hire a really good guy when another company was playing this tiring interview process with him.

Remember: lead time matters and avoid repetitions.

Strict part

If you skip this part you will look rude/unprofessional/too easy going, but in most of the cases you will get back the missing topics as questions.

Starter topics

  • Introduction of interviewers
    Due to the fact that most companies just don’t update the job descriptions it may not be obvious what to say or highlight about yourself. So be prepared if you don’t do interviews every day.
  • Role of the people doing the interview
    It just is nice to let the candidate know what each people will do on the interview, especially when there are more than two people.
  • Structure of the interview process
    How many rounds you have and what can be expected at each round like who will do the interviews, language of the interview and main goals of the stages.
  • Structure of the current interview
    Just list what will come: introduction of the company, review of the CV, test or some technical questions and at the end a talk about general perks and benefits.
  • Introduction of the company
    Many interviewers used to ask the candidate what they know about the company. The answer used to be quite sad due to the saturation of the job market. The people don’t used to check where they are applying, but as an interviewer, just don’t be surprised. If you do the interview with a foreign colleague together, clarify it for him beforehand.
  • Job profile
    You must have a written profile, not just because you have to send that to recruiter when you start the recruitment process, but it will be needed to be able to evaluate the answers and set the right level of the questions. Maybe the candidate will just stand up and leave if he misunderstood the job AD based on the clarification, but that will just save time for both of you.

Finishing topics

If you haven’t done that when you started the interview and you don’t have a HR interview included in your process always clarify the frame of the employment:

  • Place of work, home office options
  • Working hours and flexibility if there is any
  • Stand by support needs
  • Salary, bonus and other perks and benefits
  • Tools provided for the work
  • Confirmation on travel requirements, highlighting the level and the method (by air, etc.)
  • Don’t be afraid of asking the candidate about other ongoing applications and offers. You need to know how fast you need to be if the candidate is a good fit.

Never ask directly about children and family because it should not matter, but you can have a free chat about “everything and nothing” after the interview in a few minutes to fulfill your curiosity.

Partly strict part — experiences

You need to check together the resume with the candidate. IT people started to be lazy so in general you don’t get cover letter which would describe his/her interest. The reason is very simple: people need to be asked to come to interviews and it is not their own thought to apply.

Getting back to the CV: read that before the interview! It takes 3 minutes only. You will need to remember at least one or two interesting workplaces or positions because you as an interviewer needs to show interest in the candidate.

In regards of each previous positions always ask the below questions as a minimum:

  • Did you work in a team or mostly alone?
  • What was your exact role in that project/team?
  • Could you mention some tasks that you were working on?
  • What did you like in that job and what you didn’t?

When you get to the current/last job, just ask:

  • Why would you like to change?

Of course you can ask about technologies mentioned in the CV as well or interesting projects, etc. to make the candidate speak.

Technical part

For several years we asked candidates to spend some time on a test and then we went through the questionnaire and discussed the answers with the him/her.

You can choose this technic, but before you start make it clear for the candidate that you will not give feedback to all the questions in the test and it doesn’t mean that the answers are good or bad. Actually this saved a lot of time for me because in some cases the candidate is just good so after checking two questions together and looking at the rest of the answers I recognized that it was just ok. It can also be the opposite and you see that the candidate just unable to explain his answer to the question and it is quite pointless to continue.

Today I used to prefer verbal questions and whiteboard. This allows me to skip any part of the interview and monitor the reactions of the candidate closely.

Being interested in capabilities and motivation

My goal used to be to see people thinking and listening and they are able to combine the information that they get with their own knowledge. People who are able to distill the right solution from all the data that they get can work effectively under minimal supervision.

Typical questions

The questions I used to ask are simple and even if the candidate doesn’t know the answer he/she should be able to figure out the answer because I help them with questions. So one of the questions is:

What is a deadlock?

Most of the people used to know what lock is, but have no clue or just obscure memories about deadlock. So I used to ask some questions to help the candidate out:

What is a lock?
What do I need to have a lock?
How many processes?
How many resources?
and so on…

Sooner or later the candidate will figure out what deadlock is and be able to explain it with his/her own words. If the candidate hasn’t been collapsed at that time we can go to the next step by asking:

If you worked with relational database servers you probably saw deadlock related messages in the error log. How can a XYZ database server detect it?

XYZ should be the database server the candidate used earlier and mentioned in his CV.

This time we just go back to the definition of deadlock and asking questions about the information available for the server to recognize the certain situation. This part is much harder for the candidate, but we achieve our goal to make him think about technical challenges which is the purpose of the question.

You can even go further and ask about what the database server can do in this case. Obviously when you mentioned the entries in the error log earlier you told him the answer, but the question is if the candidate can use his knowledge and at the same time how he reacts. Will he/she be aggressive or behaves as a partner? Will he enjoy the challenge or just suffer? Will he give up?

Whenever you ask a question or help the candidate to answer show up as a partner who helps solving the challenge.

Shortly after the start of this task the candidate should open and talk. Even the bluest personalities used to do it because the questions are not about them but about technical details where preciseness matter.

In most of the cases when you get to the end of this exercise you will know if you would like to work together with the person or not.

Of course if the candidate knows the answer from the university you need to have another question in your pocket.

Going into technical details

In general I can’t recommend that. These type of details related questions used to come from architects who lose focus on the level of the profile you are hiring for or they have/had a problem and they invested quite a lot of hours to find a solution.The reality is that the candidate may know the answer or may not, but it doesn’t mean too much. The candidate hasn’t faced with that particular edge case… so what?

The right questions are not about edge cases and for sure not about solutions that our architects were able to figure out in weeks. The right questions are around cornerstones like in case of JavaScript you can ask about Promises or in case of C# about IDisposable. These will highlight whether the candidate knows anything about the subject or not. If you use these answers together with the answers given for the roles the candidate played in on certain projects/teams earlier you can get a quite clear picture about the level of his/her skills.

Summary

This article became long… much longer than an article should be but hopefully useful for you if you start to interview people and even if you interviewed some candidates before you can find some useful practices that you can apply.

Please give me feedback on the article and tell me about your approach in the comments.

If you are superman, it is enough if you send an S!

The Startup

Get smarter at building your thing. Join The Startup’s +793K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

István Kovács

Written by

Relevant work experience in multiple IT areas: development, operations/support and management.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

István Kovács

Written by

Relevant work experience in multiple IT areas: development, operations/support and management.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store