How to Differentiate Average Programmers from Good Programmers
When it comes to programming job interviews, the goal is to find the most suitable developer for the job. With that said, the harsh reality is that it's very difficult to judge someone's caliber, experience, and expertise in a short programming job interview.
Most software companies have a standard process to find good programmers, starting with the phone interview, written tests, and then a couple of rounds of face-to-face interview. Even so, it's still very difficult for companies to hire the right people. The process can help you to filter candidates, but eventually, it will come down to your experience and gut feeling.
As you interview more and more people, you will know what to ask and what not to ask. And like many other interviewers in the world, you will develop some of your own tips. Similarly, I have developed a couple of tips from my own experience, which has helped me to differentiate between an average programmer from a good programmer.
Today, I would like to share one of my tips with you guys, to see if you agree with my observation.
One of my most successful tip in finding good programmers during an interview is
finding gaps in requirement. I have found and learnt over time that good developers have a knack of breaking requirements and finding gaps, which is very important to produce quality software and products.
Though this skill comes with experience, a good developer with less experience can have this ability. In this article, I will share two different interview scenarios with two programmers and see what happened.
Average Programmer vs. Good Programmer
The key is to give a one line requirement to a candidate and compare the quality of program developed by multiple programmers.
I usually come up with a very generic requirement that doesn't require any domain expertise (e.g. finance, healthcare or manufacturing) but require some programming experience.
Here's a hypothetical question, which I've asked in real interviews before, you can ask:
Can you write a script to archive files that are older than 30 days, which can be run on the 1st day of each month using a cron job?
Average programmer will go on to code and produce a script that does exactly what was asked of him. His script can find all files in a directory provided as input and can create an archive of the same directory with provided name and backup date as a suffix.
Looks good right? but hold on, somethings are missing:
He did not exclude archive files created by the script itself, which means, next month, the archiving script will also include last month's archive and you will have a bigger and ever-growing file.
If you are not monitoring, you will only realize this problem when you need to retrieve something from the archive or when you receive an alert that your file system is full.
He did not think about two contradicting parts in this script — finding files that are older than 30 days and running it on first of every month. The script's objective is to backup last month's data, whose length could be 28, 29, 30, or 31 days. So if you run this script on the 1st of March, it will not archive any files because all of them are less than 30 days old (February is usually 28 days long).
His script does not remove files after they've been archived. Though this was not stated as part of the requirement, it's an implicit requirement, unless interviewer specifically mentioned not to do so. The whole purpose of archiving is to save space by reducing the size of old files.
These are just a couple of examples of missing requirements, but this case is quite common in real world programming. Most users will give generic requirement like this — experienced programmers should know that the "devil is always in the details".
If your candidate is a good programmer, before doing anything, she'll first try to grasp onto the purpose and then think about what is missing. Just like when you go to the doctor and say that you have some problem, he or she will ask a few questions to better understand the problem. Good programmers should always ask questions to clarify questions and let the user know what is missing and more.
As an expert in software development, it's your responsibility to get enough details for you to produce something that will meet the user's expectation and can withstand the test of time. I like to ask this kind of question because it's not domain specific and very general in nature.
This not only gives you an opportunity to gauge the candidate's expertise on any particular technology (e.g. Perl, Python, or Bash script) but also his or her overall thinking process.
Any developer who can think through and find gaps in requirement is going to be an asset for your team. Keep in mind, like all the things, this is not always the case and it's not a hard and fast rule. This is just another indicator, which can potentially help you to find good programmers.
A Few More Example Questions
Here are a couple of more examples to help you differentiate between an average programmer and good programmer.
1. Ask a developer to write code to read a file.
A good programmer always asks questions about file content (e.g. binary or text, if text then what is the encoding) while an average developer will just write code to read the file.
A good developer will make sure to close streams in right way and release file descriptors while an average programmer forgets about that.
2. Ask candidates about how to quickly sort any array
Average developers will tell you about the quicksort algorithm, but good developers will start by asking about the size of the array. Why? because if the array is small enough, then the fastest way to sort it will be to use insertion sort. In fact, most of the library methods which are based upon quicksort will usually use insertion sort for small arrays.
For example, in Java API, the implementation of the
Arrays.sort() method sorts small integer array of fewer than 286 elements using quicksort, and a tiny array of elements less than 47 using Insertion sort.
Note: this is why you should follow Joshua Bloch's advise on always using library method if available (See Effective Java). You will never get this kind of optimization right in short duration of writing your library, forget about all the testing users have done on open source library.
That's it for this tip on differentiating average programmer from a good programmer. As I said, this is just one of the several points many interviews look at, For programmers, it provides them an opportunity to show their thought process and how good they are in understanding requirements and finding gaps.
This tip has helped me in the past but it's not a hard and fast rule to find good developers. In fact, there are no rules on how to find them. You just have to work through some indicators and your gut feeling.
Let me know what are the tips you guys use to find good programmers during interviews!
Here are some good generic tips on how to interview software developers!