How to interview (or evaluate) a Software Developer

Today is 31st Jan 2021. We are already in 21st year of 21st century, and software development is now well over 3 decades old. Still the question of how to interview a software developer is bugging every manager, director or IT leader. Most of them leave it to a technical senior team to evaluate their future team mate. And many keep faith in the candidate’s past experience with previous employers and go by one simple belief — if the guy has worked for over a year at certain place, it is not really a risk to hire.

Best practices of interviewing developers:

0- Let's assume that you are hiring for someone who can really code. So conduct only practical interview. You will need to prepare few programs (code snippets) in advance that you can use during interview. Keep all such programs ready and open in IDE before the interview so minimum time is wasted.

1 — Candidate’s practice with programming is a key when you are hiring for some hands-on developer. So how do you check this practice? Well, the practice means ‘debugging’ skills. Make few small programs that have some logical errors. And ask the candidate that expected behavior should be X and it is doing Y. How will s/he go about troubleshooting it? You will immediately learn about his/her practice with debugging. Observe following:

• Does s/he use Breakpoint — see his choice of where s/he puts breakpoint
• Does s/he use Watch Variables
• Does s/he know about Immediate Window (or Console in Web browser)

If you find that all is going well, then you can dig deeper if the candidate is either senior or more skilled.

• Open up the Debug menu and ask which options has s/he used before or what does s/he know about those options
• If candidate knows about “Attach Process..” (in Visual Studio) s/he is THE guy
• Discuss how to debug Windows Service or multi-threading application and learn about opinions — please know that you are asking opinion and not looking for one fixed answer here

2- This step could be step 1 .. but oh well.. Keep some programs with few compile errors. And ask the developer to compile and explain those errors. You may not necessarily ask to fix each error but understanding what s/he thinks about those errors is important.

3- A typical programmer may be expected to work in multiple stacks. For a web developer, open up Google (or Firefox or Edge) debugger and ask which menus in the debugger is s/he familiar with and when those menus are useful. It is not expected that anyone knows about each option — but more they know, better you will feel good about how they will fit in.

4- Now you need certain programming samples where there is a choice between good practice v/s bad practice. These programs or snippets of code would compile just fine but they should have something bad in them. Ask if they can notice what is bad. You will see many answers — and it will tell you more about their thinking as well.

Sample 1:

try { doSomething(); } catch(Exception ex) { throw ex; }

Sample 2:

void main() { MyService someService = new MyService(); MyObject x = new MyObject(); x = someService.getX(); printX(x); }

There is something in wrong in above — and real programmers will see it. You can come up with more such samples.

5-If you still think you want to evaluate more or you skipped some of the above methods then do a Pull Request Review. In one of the project that is going on, open up few PRs with good amount of quantity of changes and ask if s/he was doing the review of this PR then how would s/he do it? What are the things that s/he would comment on and what s/he would not mind.

The answer will have both facts and opinions.

Opinion would be about — spacing, naming convention, indentation, comments, readability of code etc. But the candidate must have these opinions.

Facts will be about — … well we are not going to tell you that. you can write to us personally if you want to know what do we look for.

Above should be good enough for now. If you have come up with additional ways or better ways then please comment here. None of the above evaluates the attitudes and core values of the candidate. So who will fit in in your team is finally your decision.

What does not work

1-You can use many tools to evaluate theoretical knowledge. While it is good, it does not give you complete story. Also someone with only practical knowledge but does not understand ‘why’ is also not a good fit.

2-A candidate who has too much experience and many certificates may mislead you to believe that they are already qualified. Always go through some practical exercise like above.

3-Thinking that a candidate has worked in big corporate houses means they are already qualified is also a big mistake. There are many candidates who are only ideal for big corporate because their inabilities are easily hidden in those environments. A typical bug that can be resolved in 4–8 hours in small/agile team takes a week in certain places.

Finally a good developer does not mean a good team-mate and a good team-mate does not mean a good developer either. But you need all of these in a team.