How to Differentiate Average Programmers from Good Programmers

Published Jun 26, 2017
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:

  1. 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.

  2. 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).

  3. 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.

Conclusion

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!

P.S. If you want to become a good programmer, don't forget to read these 10 tips to become a good programmer and these 10 articles every programmers should read.

Discover and read more posts from javinpaul
get started
Enjoy this post?

Leave a like and comment for javinpaul

46
7
7Replies
Laszlo Marai
3 months ago

I’m not sure if this is the single thing that differentiates a good developer from a bad one, but 100% agree that it’s a very important skill and maybe even a mindset(!). I routinely win clients by asking questions when they first describe their requirements, and while initially I can look stupid (you actually have to be pretty brave to ask questions sometimes) as soon as I point out a gap, where the client’s response is “hm… I haven’t though about that” I’ve won.

Because smart clients realize that that was a hidden trap. It also helps as a manager to help you build trust with your new team.

Regarding the interview questions, I’ve been doing the same. And you can do this with algorithmic questions as well. If you just say write an algorithm that takes a number as an input, and … [whatever the puzzle is] you’ve already put in a gap. Actually sometimes it’s just coming up with the question and then removing a bit of the specification that you have put in because you are a good developer and don’t like gaps :).

Evgenii Kozhanov
3 months ago

I don’t agree with you. If I will findinging gaps, my PM will decide that next tasks may more and more gaps. Therefore, tasks with gaps should be returned to PM.

Laszlo Marai
3 months ago

Probably it depends a lot on your organizational structure. OTOH, the point the post is trying to make is that the developer should be able to discover these gaps (unless I missed something while skimming, which is absolutely possible). Because if you can’t discover them, you can’t return to the PM/can’t ask the client (whatever applies to your organization), but will go ahead and build it based on your (perhaps unconscious) assumptions.

Evgenii Kozhanov
3 months ago

Yeah, a programmer is a person who does what you did not ask him :)

prd x
3 months ago

Hello there… interesting article… I do agree with most of your points. Well, I always leave the files behind.
First, I don’t believe that archiving means saving spaces. Space are cheap enough nowadays.
Second, people always love to open whatever they need in a snap. Extracting them from archive is not that productive. It’s already hard enough to force them to save their files to server, imagine how angry they will be when I remove all their files into a zip.
Third, archive is not searchable. You cannot find any files you need with specific text inside it in archive. You need to extract them, then search them. It will only serves to slow your colleagues work.
Fourth, archiving for me means that I can always rollback to archive, in case something wrong. So I usually keep only one year archive, and remove all archives older than a year. If it is longer than a year, I gather that they won’t be looking what they did wrong last year, would they? Besides, we should have versioning for short term.
And fifth, I always make a separate purge script, to selectively remove all unneeded files. Such as logs, and old archives. Archiving and removal have to be on separate files. Put list of files which you can and cannot remove with their life cycle. Sometimes you need to archive, but you don’t want to remove something. Putting two different actions in one bundle is a no no for me.

My ingredient to find a good programmer is to ask them to make a simple script such as bi-lingual number to text. They are easy enough, but how they make it will tell us the way their logic works. How they use interfaces, how they create language templates, and such. Bad programmer would make a hell lot of if blocks, while the worst would just make 2 functions and call them translateEn() and translateId(). A good programmer will create recursives, splitting those numbers and send them into another functions, and inject one language over another using interfaces. Thus opening possibilities for another day. That would also highlight their willingness to go for some proper code instead of working code, while I can also see how prepared and how protected their code to unusual circumstances and possibilities.

Let’s take your example, I would prefer the one that wouldn’t ask question, and he just create a script that determine file content, and load it accordingly. Like my test above, where a good programmer would just ready to inject any language into their code. Same goes with array sorting. I believe a good programmer would create some best scenarios, and sort them accordingly. Array length is determinable anyway. Good code should be able to feed them to any most efficient algorithm, so that code will be able to handle any size.

Show more replies

Get curated posts in your inbox

Read more posts to become a better developer