Disclosure: This post includes affiliate links; I may receive compensation if you purchase products or services from the different links provided in this article.
When it comes to interviewing Programmers or Software Developers, the goal is to find the most suitable person for the job, but its easier said than done. In practice, it's very difficult to judge someone's caliber, experience, and expertise in a short duration of an Interview.
I know there is a process starting from the phone interview, written tests, to a face-to-face interview, but it's still not easy to hire or find a good programmer.
The process can help you to filter candidates, but eventually, it will come down to your experience and gut feeling to find good programmers.
As you take more and more interviews, 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 to find right candidates.
Similarly, I have also learned a couple of tips from my experience of interviewing many programmers, which have helped me to differentiate between an average programmer with a good programmer in the past.
Today I would like to share one of such tips with you guys to see if you agree with my observation or there is a flaw in my understanding, and hopefully, I can learn a couple of more tips from you guys to find some good programmers in future.
One of my most used tips is finding gaps in requirements. I have found and learned it over the time that ---
Good developers have a knack of breaking requirements into pieces and finding gaps,
which is very important to produce quality software.
Though this skill mostly comes with experience, a good developer, even with less experience, has this ability.
In this article, I will share an interview scenario to check what an average and a good programmer will produce given the same requirement.
This is a hypothetical interview to demonstrate my tip, but it's very close to the real interview.
You can change the requirement based upon your domain, candidates' experience and domain expertise and job description. Key is to give one-line requirement to a candidate and compare the quality of the program developed by multiple programmers.
In this scenario, I have used a very general requirement, which doesn't need any domain expertise, like finance, healthcare, or manufacturing, but requires some programming experience.
Interviewer: Can you write a script to archive files older than 30 days and which can be run on 1st day of the month using a cron job?
Programmer 1 went on to code immediately and produced a script that does exactly what is in the requirement.
His script can find all files in a directory provided as input, can create an archive in the same directory with the provided name and backup date as a suffix.
Looks good, right?
But hold on something is missing :
- He did not exclude archive files created by script itself, which means in next month script will also include last month's archive. If you are not monitoring, you will only realize this problem when you need to retrieve something from the archive.
- He did not think about two contradicting parts in this script, finding files older than 30 days and running it on the 1st of every month. Since the script's objective here is to back up last month's data and month can be any of 28, 29, 30, or 31 days. So if you run this script on 1st march, it will not archive any files because all of them are less than 30 days old because February is usually 28 days long.
- His script was not removing files after archiving though this was not stated as part of the requirement; it's an implicit requirement until the interviewer specifically mentioned not to do so.
I agree he shouldn't assume anything, but at least he should clarify that with the interviewer. Even if he brings this point, I would have given him a brownie point for understanding the job in hand and bringing things that even the user has not thought about it at the time.
This is the key difference between a good programmer and an average programmer
These are just some of the examples of missing requirements, but this case is quite common in real-world programming.
Many users give requirements like this, and experienced programmer knows that "the devil is always in details." Before doing anything, the first step is to understand the purpose and then think about what is missing.
Just like when you go to a doctor and says that you have some problem, he asks a couple of questions to understand the problem better; you should always ask questions to clear doubts, let the user know what is missing, etc.
Being an expert in the area of software development its your responsibility to get enough details so that product meets user expectation and can withstand test of time.
I like to ask this kind of question, which is not very domain-specific and very general in nature. This gives not only an opportunity to gauge the candidate's expertise on any particular technology like Perl, Python, Java, or Bash script but also his overall thinking process.
Any developer who can think through and find gaps in requirements is going to be an asset for the team.
BTW, like all the things, this is not always the case, and it's not a hard and fast rule, It's just another indicator, which can potentially help you to find good programmers.
Here are a couple of more examples to differentiate between an average programmer and a good programmer.
One of the interesting tasks is to ask the developer to write code to read a file; a good programmer always asks questions about file content, like binary or text.
If text, then what is the encoding, while an average developer just writes the code to read a file.
A good developer will make sure to close streams in the right way and release file descriptors (resources) while an average programmer will generally forget about that.
For developers and programmers, if you get these kinds of questions, where Interviewer ask you to do a real job, consider understanding requirement better and asking right questions.
Like in our previous question, you could have asked about all those missing requirements which surface when you start using your script.
Needless to mention, that second programmer ( good programmer) was a bit more intelligent and practical and was able to fill some of those gaps.
This tip has helped me in past but it's not a hard and fast rule to find good developers, in fact, there is no rule to find them.
You just have to work through some indicator and your gut feeling. Let me know what the tips you guys are using to find good programmers on interviews are.
Here is a couple of more question for your practice :
1) Write a wordwrap() function, which can take a String and break it based on screen size?
This was a real J2ME question, which I have faced when mobile devices are very small and don't have enough API support.
Since mobile phones or smartphones has varied screen sizes, wrapping words based upon screen size was a common task.
Though not stated, the goal here is to make this function work for every device. The function should consider line breaks, white spaces, font sizes, etc.
You can now use this question for Android and iOS interview, as smartphone sizes are still not uniform.
2) Write a function to replace a given character from a String in Java?
This is rather a simple question but asks him to write a production like code and then see if the candidate takes care of obvious things like null string, empty string, String contains all character which is there to replace, etc., here is the sample solution of this problem.
Here are some more popular Coding questions you can use:
- How to design a Vending Machine? (solution)
- How to Check if a String is the rotation of another given String? (solution)
- How do you count the occurrence of a given character in a string? (solution)
- How do you print the first non-repeated character from a string? (solution)
- How do you convert a given String into int like the atoi()? (solution)
- How do you implement a bucket sort algorithm? (solution)
- How do you implement a counting sort algorithm? (solution)
- How do you remove duplicates from an array in place? (solution)
- How do you reverse an array in place in Java? (solution)
- How are duplicates removed from an array without using any library? (solution)
- How is a radix sort algorithm implemented? (solution)
- How do you swap two numbers without using the third variable? (solution)
- How do you check if two rectangles overlap with each other? (solution)
- How do you design a vending machine? (solution)
- How do you find the missing number in a given integer array of 1 to 101? (solution)
- How do you find the duplicate number on a given integer array? (solution)
- How do you find duplicate numbers in an array if it contains multiple duplicates? (solution)
- Difference between a stable and unstable sorting algorithm? (answer)
- How is an iterative quicksort algorithm implemented? (solution)
- How do you find the largest and smallest number in an unsorted integer array? (solution)
If you need more questions or if you are a programmer preparing for interviews, You can check out the Coding Interview BootCamp course or Gayle Laakmann McDowell's classic Cracking the Coding Interview book, one of my personal favorite for quick review and initial screening of candidates.
That's all about this tip to differentiate an average programmer with a good programmer. As I said, this is just one of the several points many Interviewer looks on a candidate; for programmers, It's an opportunity to show their think through ability and how good they are in understanding requirements and finding gaps. If you want to become a good programmer, you can also read these ten tips and these ten articles.
Further Learning
Data Structures and Algorithms: Deep Dive Using Java
10 Books to Prepare Technical Programming/Coding Job Interviews
10 Algorithm Books Every Programmer Should Read
Top 5 Data Structure and Algorithm Books for Java Developers
From 0 to 1: Data Structures & Algorithms in Java
Data Structure and Algorithms Analysis --- Job Interview
20+ String based coding problems from interviews\
20+ linked list problems from interviews
20+ basic algorithms based problems from interviews
Closing Notes
Thanks, You made it to the end of the article ... Good luck with your programming interview! It's certainly not going to be easy, but just paying attention to details and askin good question can make a lot of difference.
If you need some more practice questions then you can also check out these additional 50 programming questions for telephone interviews and these books and courses for more thorough preparation.
All the best for your coding interview.
Top comments (29)
I think the biggest issue with technical interviews is the fact that a lot of the time the interviewer is not clear on what they want, so say you complete the tasks successfully, and then you get points off because its missing unit testing, or it uses ES6 syntax (happens too many times), or some other arbitrary thing that was never disclosed. As an interviewee, we are pushing our CVs to more than a single company and figuring our how your specific company works for free is not a good deal. For interviewers, I wish you could just be clear, set expectations and metrics and let us do the technical part, the problem is that most interviewers are not clear on these points either and every interview ends up being arbitrary. Good engineers end up with impostor syndrome because of bad recruiters.
Hey good point, I agree interviewers should be prepared and know what they want. One thing I would like to disagree is where you mentioned "let us do the technical part". what do you mean by this? Because in my view as a software developer it is not only "build a script with x stack", it goes beyond that, it takes problem solving, use of analysis, planning, etc.
Also, keep in mind a more seasoned developer will always take into account testing, IMO I rarely see a practical interview that requires a unit test, but it is not a reason to "take off points", as an interviewer I would even be opposed to using a "points" system...
Absolutely @jose and I couldn't agree more. If I really want that job, I will follow Interviewer's mind and tell him what he wants to listen to, but, if not then its also a good indication whether you want to work with close-minded people or not.
"files older than 30 days"
You specifically ask to delete files older than 30 days and then later suggest that candidate should have assumed that he should have archived last month's files. How he's supposed to infer that ?
Now if you asked me:
Can you write a script to archive files older than 30 days and which can be run on 1st day of the month using a cron job?
I would just say
:)
:-) think me as a client, That's why I posted that image. Most of the time don't really know what they want and we need to ask to confirm that. In this, you should ask, why you want to delete 30 days of files? That would lead to a real requirement that he want a monthly archive. I mean, you can disagree but that's the way I generally find what a user really wants.
I get your point, just a bad example with the script IMO. Must absolutely convey that questions as a client, because most people would completely trust a recruiter to get his requirements right. I would.
In one interview I was asked to perform a practical task. I came back with additional questions, because I wasn't sure about the exact requirements and hence the best possible DB solution. I was ridiculed for not inferring the requirements by myself.
After I said I would not continue with onboarding, I asked interviewee to disclose all details. He had no idea about the potential problems with real world implementation of the said task.
I guess my point is that people tend to have a sort of tunnel vision and rule out good candidates based on bad assumptions.
That's true and it happens many times and unfortunately, there is no way to really stop it because nobody questions Interviewer why he rejects a candidate?
This is a pretty good approach, I agree that good developers are good at spotting holes in the requirements and asking questions, but this takes experience too (technical and life experience) , I don't think people are born with any specific skill.
For a fair process I'd apply the method you described as long as I made it clear to the candidate that I expect something around those lines from them. For example presenting the task and telling them "do you need any clarifications before you proceed? Take 5 minutes to think about it and get back to me if you need more details about the requirement". Otherwise it's like putting the candidate to play a game in which they don't know the rules.
Thanks @rodbv , definitely we need to be careful while taking any advice as they don't apply in all the scenarios. If you ask this question to two graduates you don't find much difference but if you ask this to two senior developers, you will find a lot of difference. Also, giving hints is a fair way and shows that you are there to select and not looking for a reason to not-select the candidate.
When I became more senior I had the impression that good developers don't ask too many questions.
This had two reasons.
First, I had to ask less questions because I was working with the stack for many years now and knew it like the back of my hand and not because I was a good dev.
Second, we hired a bunch of devs coming right from university that knew next to nothing about developing and were asking questions constantly about the most basic stuff.
I constantly had the impression they knew next to nothing.
In the end I got the insight that the problem wasn't that they didn't know much, but that they asked in an intrusive fashion.
Sure, requirements have to be clearified with the people who made them, but otherwise try to get the answer from the Internet.
Ask a co-worker if anything is unclear OR you think that their answer would save you hours of online research (and you didn't bother them too often this day, haha)
Hello K,
You are right, but there is a difference between a functional and non-functional requirement. Senior Dev knows both of them so obviously they ask less but they definitely ask the right questions, particularly to users who often don't have any idea what they want. Our job as professionals is also to lead them towards what they really want. Also, on junior developers, there will be some who ask questions and some don't, Mostly the devs who don't ask questions means they are afraid unlike they understood. So, we need to help them and encourage them to ask questions.
Javin
Most of my life is spent answering other people's questions.
So much so, that I have tasks assigned at the moment to create a simple micro service (http get, RPC then DB call & return a simple model). If I had dedicated time, including 100% test coverage, that's two days of work. At worst.
I told PMO to expect 4 weeks, and if they're bringing snacks for me daily, they might get it in 3 weeks. Unfortunately, the PMO estimate is genuinely my considered thoughts on delivery time.
All interviewers want to find themselves on the next developer who is in the interview. That's not going to happen. Advice: drink a coffee or beer with the guy and see if he/she is a good person. All the rest, anyone can learn it.
Just to known, will the good developer drink beer or coffee?
Just to known, will the good developer drink beer or coffee?
Of course. But the main idea is try to get a social encounter with the person.
For me recruitment is more about the creation of well structured, maintainable code, with good tests than anything else. Team work and communication skills are also important factors.
Want to split a word based on screen size? I would assume that even the most experienced programmers will sometimes do a little bit of research beforehand just to see if someone has a better way.
I am on-board with questioning and suggesting requirements but this tends to come from experience in the application domain. Should I presume as someone who doesn't know anything about the context that the 30 day rule has issues? In a real work situation a may ask for clarification but in an interview, I'd only question this if I know that the interviewer is trying to catch me out.
This is a perfect article to demonstrate why an "AI" is not going to be replacing "humans" completely in the field of "computer programming".
Nor "common users" replacing "dedicated programmers". Both ideas that I have read about repeated times.
Thanks for the Article @javinpaul , do you have any advice for average developers, how they can get to the part where the automatically think like good developers.
@Peace Dube, good questions, while I am also an average programmer, but I can share a few things which I have seen good developers doing and learned from them
And, you can also find some more tips on my article javarevisited.blogspot.com/2014/01...
And, May be other great guys here can chip in and advice so that we all can learn from each other.
I'm sorry, but "don't commit time" sounds like bad advice.
We have a junior dev that refuses to give story point estimates & his reasoning is always "I need some time for analysis first" (even when seniors & PMs have broken the task into simple statements that require no thought).
That dev has been parked on our documentation project, and if that ever dries up, they'll be fired.
A good developer needs to learn how to forecast time, manage expectations & deliver on time.
This is a very interesting approach, based on my experience interviewing people, it doesn't matter how many things you try to get out the candidate, it is always a gamble. I read from someone in the comments that the interviewers most of the time don't know what they want, I agree... As an interviewer you need to do your diligence and hash out the things you need for the position and want out of a candidate, still it doesn't mean you will find the perfect person.
Great article!
There's no client can describe their requirements thoroughly, at least most of the clients. It's the our job to clarify the requirements.
Indeed, that's the point of this article. As a professional, it's our responsibility to get the requirement right just like a Doctor asks questions to diagnose a disease.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.