Preparing for Java and Spring Boot Interview?

Join my Newsletter, its FREE

Thursday, July 27, 2023

10 Technical Software Developer Interview Questions Answers

Conducting an Interview is not cheap and costs both time and money to a company. It takes a lot of time to find the right candidate for a job from the 100s resume you receive from consultants and agents. They will always tell you that this guy is a Java Guru, this one is SQL Expert and the next one is the full stack developer you are looking for. If you have to trust them blindly and invite all of them for face-to-face interviews, you are going to be disappointed. One of the first things you should do is to filter candidates who claim to have certain skills like SQL but don't have them, the faster you can weed out those candidates the cheaper will be the hiring process. 

A phone screening interview is just for that purpose, it doesn't cost you much and is also suitable for candidates, as they don't have to take off and come down to your office. It's flexible for both parties.

When I phone interview someone, I spent the first few minutes listening to them and then I go for my list of weed out programming questions to see if the candidate is good enough to spend another 30 to 40 minutes. They have saved a lot of time, where I found out that candidates having words like "Strong knowledge of Java", "Exceptional in SQL" and "Programming gurus" fail to answer these simple questions.

If you are a candidate and have gone through a couple of interviews, you might have noticed that almost all interviewers make up their minds in the first 10 minutes. The rest of the interview gives them reasons supporting the said decision, but not all is lost.

If you ever feel that you have messed up with your chance, try coming off some really good answers on the rest of the questions, if you can impress the interviewer to an extent that encourages you to go deep, you may be able to change his initial decision. To get some feedback and improve upon my method, I have decided to share my list of weed out programming questions (don't bother about sharing questions, I have many similar questions on my secret question bank and you can create them easily as well).

I have chosen one or two questions from a common programming skill set e.g. Java, SQL, XML, Programming, Coding, OOPS, Multi-threading and UNIX. I am looking forward to know what you guys do, what do you ask to check same skill set before calling candidates for face to face interviews. Comment if you agree or disagree.

10 Questions to Start Your Software Engineering and Programming Interview

Here is my list of filtering or weed-out questions for different programming skills. As I said it serves two purposes, it gives nice warm-up to the deserving candidate, make them comfortable but same time weed out programmers who can't programmer or SQL expert who can't write JOIN queries.

In SQL, My first weed out question is asking them to describe a Left Outer Join. They don't have to get it exactly right, I just want to see if they have ever done anything more than a two-table inner join.

Depending upon their answer I ask them classical SQL queries like writing ALL departments and the number of employees in that department to verify that whether they only know theory or can apply that knowledge as well. 

If they use Inner join instead of left outer join they will miss out on departments with no employee.

Top 10 Technical Interview Questions with Answers for Screening Round

For a Web Developer, the first weed out question is to explain the difference between a GET and an POST. Here at minimum, I want them to know is that a GET is what you generally see in the URL and a POST is commonly what you see in HTML Forms. 

Again depending upon their answer, you can also further question about limitation, security, and usage of GET vs POST method. This question will give you enough hint that whether they really know something about the internet or not.

In UNIX, one of the popular weed out question is rather simple, how do you find a particular process and kill it? Here I expect them to tell me about psgrep and kill. Also to gauge their level of understanding you can ask them about ps options e.g. what does a, f and e means in ps -afe command. 

The second level weed out the question in UNIX can be about command to find large files in UNIX e.g. files which are greater than 2GB etc. Don't get me wrong but if a person cannot answer these question, it would be difficult for him to work in a project which has tons of process and connected to tons of other server. 

One counter argument question against my weed out question, I always hear that it would take just 5 minutes to learn those commands, but they fail to answer me, when I said why they didn't spent those five minutes before coming to interview.

In OOP (Object Oriented Programming), my weed out question is difference between Class and Object? Here I expect slightly more than the popular definition of classes are blue print to create objects, yes that's correct but how do you know that he understood the concept and not just have mugged it, Ask him to give examples, and then cross question him on that e.g. where does object get created, who creates it etc.

In Programming, particularly when it comes to code, the most popular question to weed out the non-programming programmer is the "Fizz-Buzz" test. If a programmer cannot write a Fizz-buzz in 10 to 15 minutes, he probably needs more practice and is not ready yet. This is something I don't ask on phone interviews but on written tests I have before face-to-face interviews. 

There have been instances in the past before we had a proper interview process of multiple rounds where I had literally asked Fizzbuzz, and their answer took the better part of an hour. Another weed-out question in my list for programming is to have them write the Fibonacci series and ask them to optimize it. 

Fibonacci is very common but you would be surprised with a number of programmers failing to write in using pen and paper and even on IDE. It also weeds out programmers who understand recursion than who don't. My experience is the programmer who understands recursion are usually better than those who doesn't. This is where most of the natural programmers come in.

In XML, my weed out question is the difference between DTD and XML Schema? Some one may say that it is slightly harsh to judge someone's XML skill with just one question, but you would agree that this is fundamental. 

I know there are many programmers who has worked in XML and can work in XML but doesn't familiar with this fundamental but shouldn't it's their responsibility to learn fundamental like this, just working is not enough, you also need to fill your gap.

In Java, my weed out question is the difference between JDK, JRE and JVM? It's such a fundamental that I expect anyone who has worked or learned Java should know about it. Here I expect that they should mention some tools which comes with JDK, at least javac (the Java compiler) and JVM, which actually runs every Java program.  

One more question in my list to weed out non-Java programmers is difference between PATH and CLASSPATH? I have a hard time teaching this fundamental to a couple of people and have found that if you don't know the difference between these two, you will struggle to set up your project, debugging and fixing those nightmarish ClassNotFoundException and NoClassDefFoundError. It's again a must-know detail for any one who claims to work in Java.

In multi-threading be it in Java or any other language, one of the good weed out question is asking candidate to write code to avoid deadlock. You can ask this question differently either by giving him a practical scenario or just asking about how to code so that deadlock doesn't happen. If you have not done many interviews, you will be surprised with how many programmers, with professional experience of 2 to 4 years fail to answer this question correctly.

In data structure and algorithms, the first question I ask to candidate is about how to add or remove elements from linked list , because I believe that as a programmer you must know array, linked list, set, map and string algorithms. If you want to add another level of cushion than you can also ask about how to remove duplicates in array without using any library function. This will give you enough idea whether to proceed further or not.

I know trivia is not a good way to find programmers, but questions that are closely related to practical experience are a good way to weed out someone who claims to know something but is not there yet. The best way to find a programmer is to sit down with them and examine their projects or have them pair programs with you. Ask them what part are they most proud of and ask them what part they would change, why they would change it, and how they would change it. 

Once you do this, other than personality questions there is nothing more that you need to ask to gauge their ability to program. But if you do this with 100 programmers, you are not wasting a lot of your time but also your organization's time and money. 

Before you invite programmers for face-to-face interviews, you must ensure they deserved to be there. It's not practical to call all the guys based upon their agent's claim only. Let me know what are your set of weed out questions, what do you ask to C, C++, Ruby, Python, or JavaScript developers to check whether they deserve your time or not.


Anonymous said...

please provide the same for Ruby and Javascript.

Anonymous said...

Man.... there is another way to look at it... My personal experience: 4-5 interviews I passed in the first round and flunked in the second round, in a row.. I lost like 4-5 hours on each of this interview going onsite and attend these interviews .. Its not just interviewers time loosing here.. at least they are doing the interview from the luxury of their office ..
I am risking my current Job and spending like 4-5 hours for one interview... and the interviewer enjoys the godly figure from the comfort of their office... you shouldn't be worrying too much about their lost time.

javin paul said...

@Anonymous1, Though I wrote this post on interviewer's point of view, I completely agree with you as well. It's actually right way to save time of both parties. For interviewer, trouble is he has to spend lot of time interviewing candidates until he found that they lack the skill necessary to do their job. I know selection cannot be done in just 10 minutes but you can easily weed out those who you know for sure that they are not going to make it. It's beneficial for candidate also, as you said they don't need to take time off from their office and appear for second round of interview.

javin paul said...

@Anonymous2, I think you missed the point. It's not about most frequently asked question but about weed out questions. Best example is, If a programmer cannot write FizzBuzz test in 10 minute, no second look. It's something in the line of minimum skill set.

javin paul said...

@Anonymous 18th Sep, Sorry but don't have such questions for Ruby, Python and some other language. Please feel free to share if you come across such question. Criterion is question should demonstrate some practical experience just like the question shared here.

Anonymous said...

Thanks, these are actually very good pre-screening pre-interview interview question :-)

Anonymous said...

Fantastic weed out questions to get rid of the people who have no idea what they are doing. I have been using couple of them from SQL, but your list is worth bookmarking. Keep it up.

Anonymous said...

I have to say I disagree with your assessment for *NIX engineers. Asking what switches mean on common commands isn't necessarily telling. I almost exclusively use `ps -aux` because it gives me what I need 99% of the time and at one time may have known what those switches did exclusively; If I need to see something else, I'll use the help or manpage.

I much prefer the second method you describe, asking someone to tell you how to do something, more useful, find large files, parse a file for a string, replace the first 3 instances of a word in a file. These allow someone to show they know how commands work rather than proving they know what the documentation says. Overall though I agree with you, spending countless hours on interviews that go nowhere is not beneficial to anyone.

javin paul said...

@Anonymous, You got the point right, regarding the first question, I only ask them when they say that they use 'ps -ef' to list the process, if they say they use 'ps -auxwww' I would ask about that, because it separate a great deal of programmer who knows what the command and each option doing rather than just using it because someone else also do that. If you know basics of commands you are using, you will be better able to understand output, take decision or troubleshoot. Having said, it's not necessary you know every option, but you must know options you which you use at-least 10 times a day.

Fred said...

Great weed out questions Javin.
Here is another simple method to check the programming abilities before hiring:

javin paul said...

@Anonymous, unfortunately that's a reality, but all this things improves your probability for getting the right candidate and reduces chances of hiring a ....

javin paul said...

@Fred thanks for sharing that. I indeed prefer to have candidate go through a coding test even before screening round of interview, just like Amazon does. In almost all cases, where a candidate has came out successful via coding test they were able to clear screening round, making it sort of unnecessary. Only issue we faced that success rate of candidate was VERY low with such online programming tests to hire developers. We end up spending lot of time to just fill one position. I am sorry to say but success rate of Java developer clearing algorithm based coding interviews is lesser than C, C++ guys. So we end up developing couple of round of questions where we can test multiple skill in short time.

Fred said...

@Javin About Java programmers you are right, we were faced to the same problem until we decided to add online programming exercises about design patterns, refactoring, memory leaks detection, OOP and TDD. Then we obtained better results...

Anonymous said...

Would you say a zero year experience junior java programmer looking for internship or junior level developer position is expected to know these queations? What is the level of these questions? Thanks.

Anonymous said...

After reading your blog, I am surprised that you had the gumption to publish it without first having checked it for spelling and grammar. Nonetheless, thank you for sharing your thoughts.
A candidate may answer all your questions to your satisfaction but still be an ineffective employee if they do not listen, confirm that they understand the question or the business situation, and stop to think and work through a design before they start writing code. It is a waste of time to do the wrong things well. It is more important to do the right things and do them well.

Anonymous said...

Being in the Java programming business more than 15 years I probably fall to a one of a kind category. I could not answer many of what you asked for. While I worked with SQL for years many years ago I forget most of what I used routinely then. There were times I looked up the difference between GET and POST, but have not used them directly, they are covered by the tools used. I use unix just as long back as doing programming, but use certain commands with "standard" options and only when I need something different I turn to man to look up what needs to be changed. Today developers use such a wide-range tool-chain and are required to keep learning new ones all the time that it is hard to keep in mind unused things. As soon as I need something I delve into it learn for the task, usually forget and proceed. Many times I just wonder what I was able to do earlier. If the code were others' I would be envy :-)

Unknown said...

First I would like to say regarding the Web Developers weeding, if a candidate would answer that what you mentioned ("Here at minimum I want then to know is that a GET is what you generally see in the URL and a POST is commonly what you see in HTML Forms.") to me that would be a fail. I mean that is not the basic knowledge about these HTTP methods, I don't even know how to describe it but to put it simply that would be a terrible answer ...
One of the pure basic things that needs to be said would be that in GET you are passing the request parameters as query string and in POST you are passing them within the request body. Additionally I would ask comparison questions about HTTP methods and CRUD functions, but this can be a little tricky because these two do not have one to one relation because of the POST and PUT, but rather it is a specific situation based implementation.

For JavaScript I would ask the classical questions about the 'this', 'null', 'undefiend', '==' and '==='. I believe these are enough for weeding, but if needed then some follow-ups are 'hoisting' and 'closure' related questions.

But generally regarding the weeding we do not use phone screening for this, first regardless how small the invested time is that time is wasted. Also the problem we encountered was that often we needed to adjust the screening schedule because candidates cannot participate at the given time. An approach that we now use for filtering and that requires no time from us is by using an online coding tests:
We send a simple, straightforward preliminary coding tests that require the basic, the minimum, knowledge in order to resolve them and it proved to be a great filtering mechanism.

Anonymous said...

Another weed out question in my list for programming is to have them write Fibonacci series and ask them to optimize it. Fibonacci is very common but you would be surprise with number of programmers failing to write in using pen and paper and even on IDE. It also weed out programmers who understand recursion than who doesn't.

I'm sorry, but if you are telling me that recursion is faster than iteration in the case of the fib sequence you do not deserve a good programmer :)

Anonymous said...

Good article , but saying programmer who writes it using recursion is better ? Well that just proves they have mugged it up. Last time I was asked the question , I did ask back that if he knows the impact of recursive functions on JVM or simply , how does JVM perceives recursive function. Recursive functions looks good on paper but a better developer ( the one you seeking ) would know when to use it , which in my experience is very rarely. Use a for loop and get done with it. If they keep insisting about recursion , ask them to explain why in this context recursion is better than the normal for loop , if they can convince you , then write it.

BlaiseP said...

I once had the horrid task of reinterviewing roughly 200 H-1B Java consultants. Only 19 made the cut. I don't ask gotcha questions like FizzBuzz. It's a crap mentality, to think someone can be weeded out in a situation where he doesn't have access to a working compiler and an IDE. Now here's how you do it. I've been in Java since the night Sun first made it available for download. You give your candidate an assignment in a proper set of use cases. You set him up with a private github project. You send him home. You watch him code. Then you bring him back in and have him explain what he did. You see if the results are congruent with the use cases. I can teach a baboon to code. I can't teach him to think. I can't teach him to carefully read use cases. I can't make him comment his code effectively. And that's unfortunately what I see too little of when I'm interviewing these days.

javin paul said...

@BlaiseP, I must say your method is the most practical way to identify good developer, provided you give them unique questions. Unfortunately, not many companies do that and hence you need to prepare for classic way to do well on programming, after all getting job is more important for many programmers.

BlaiseP said...

@Javin Paul: There's the problem right there, that "getting job" is more important. Javin, I see these guys all the time. They think because they've got a cube to sit in and a chair to sit on - that they've crossed the finish line. Well they just haven't. I've been saddled with the "classic way" idiots for twenty years as a consulting project lead. I have to un-teach them almost everything. They can't read use cases, much less write them. They don't know how to use version control. They don't know how to operate as a team. They don't know how to seek help when they need it. They try to hide failure from me. And they can't communicate with the end users, because they think they know everything. They have no humility and no business sense. Java I can teach them. They're not making any decisions about architecture or objectives. I would rather have someone who can't code and can write a use case - than the reverse.

Technical interviews are - to put it mildly - bollox. The people who ask these questions barely know the answers to them. I've cornered at least four of them over time, answering their question - then asking them "uh, do you know nobody actually does that in production code?" I write software to solve problems. As such, I don't need a Job. I need someone who can help me provide my clients with a Solution.

Post a Comment