IT Employment

10 things you may be asked during a developer interview (and how to handle them)

These tips will help you clear some of the most common interview hurdles when you're trying to land a developer job.

Many software developers I have talked to absolutely dread job interviews. And I have seen job candidates absolutely flub a number of questions. Some are standard interview questions, but a developer will still need to answer them in a way that relates them to the job. Other questions are specific to the software development industry. Here are 10 job interview questions that come up in development interviews, with tips on how to address them.

1: Tell us about your current position

Employers want to know about what you are currently doing a lot more than they want to know about prior positions. The reason for this is simple: The world of software development moves so fast that what you did two or more years ago is interesting for background but probably has little bearing on their current work. When asking this question, the interviewer is trying to relate what you currently do to the position the company is offering, and you will want to answer with that in mind. For example, if the position you are applying for involves a lot of database programming, emphasize where in your current job you have worked with databases.

2: Programming challenges

Many employers will present you with some sort of programming challenge. These range from being asked to sketch out a piece of pseudo code that implements some business logic or being handed a piece of code and told to find the bugs to being put down in front of a computer and asked to code away. What they are usually looking for is not just a certain level of competency -- they also want to see how you go about solving the problem. You can offer to narrate your thought process as you solve the problem. If they take you up on it, that will help them to learn what they are looking for. Or perhaps when you are done, you could walk the interviewer through how you solved it.

3: Do you have any examples of your work?

Employers love to be able to look at real-world examples of your work. Unfortunately, this is rarely possible. The truth is, in most circumstances, your work is the property of your employer and you can't be taking it outside of the building without permission. And it would be unusual to have a boss say, "Sure, go grab a couple of your best apps from source control to take on the job interview!" Instead of being unable to provide any samples, contribute to an open source project or work on an application at home that is sophisticated enough to let your skills shine. Then you will have something that you can show the interviewer and also be able to demonstrate an ability to work on your own and manage your own time, too. These side projects can often serve as a great talking point in the interview.

4: Brainteasers

Apart from asking you to demonstrate some programming abilities in the interview, some employers may give you a variety of brainteasers. Some people are really good programmers and stink at these, but the idea is to test your overall problem-solving skills. Luckily, you can prepare for these a little bit by picking up a few brainteaser books (usually only a dollar or two) at a book store or supermarket and doing a few every day. Most of these brainteasers follow a similar format, so by practicing, you will understand how to approach the most common types. There are also a few standard ones that come up on a regular basis, such as the one where you need to get a group of people across a river with a boat of limited capacity.

5: Do you have a security clearance?

Depending upon the job, a security clearance may be required. Employers prefer hiring people with one already because it simplifies things. It would be a big hassle to hire someone and then discover that they can't get the needed clearance to do the job. If you have a clearance, make sure that it is up to date. It's also a good item to list on a resume.

If you do not have a security clearance, ask before you come in for the interview about any security requirements for the job and research whether you are eligible for any security clearances needed. This way, when asked, you can answer with something like, "No, I do not have that clearance, but I have looked into it and I can obtain one if needed."

6: Background check and criminal history information

Information about criminal history and other background check items typically will not come up in an interview with a hiring manager, but they will often come up in an interview with HR or a recruiter (especially the recruiters). They do not want details, for the most part, but they want to know whether it will be a waste of time interviewing you. Obviously, it is great to have a squeaky clean record, but there are plenty of good job candidates who don't. You will need to be honest here, because things show up on the background check anyway. If what you say does not match the check, they will feel that you lied to them. At the same time, limit your sharing to the minimum. You can start with something like, "I have a misdemeanor conviction from three years ago" and take it from there.

7: What is your experience level with XYZ?

When interviewers ask about your experience level with a technology, they really want to get a feel for what you have been doing with it, not how long you have been doing it. For example, if they are asking about SQL, is it important to them that you have been writing statements no more complex than, "SELECT id, name, city FROM people WHERE state = 'NY'" for 10 years? Not really. Performing complex data transformations, correlated subqueries, etc., for six months will be much more impressive. When talking about your experience level, emphasize the kinds of challenges you solved with those technologies and the unique aspects of the technologies you used to solve the problems.

8: What's the hardest challenge you have had to overcome -- and how did you approach it?

This is a stock interview question, but it has some special pitfalls for the programmer. One of the failures I've seen in interviews is that candidates do not properly set the context of their answer. I have faced some challenges that at that point in my career were difficult but that later on were trivial. If I brought them up in an interview without explaining my experience level when they arose, it would put me in a bad light. The interviewer would be thinking, "Why would someone with his experience struggle with this?" So when you answer, give a short (one sentence) scene setup. Also, put your focus on the problem-solving steps you took, not the technical details. No one really cares if the problem turned out to be that the variable was one character shorter than the data going into it; they want to know how you did the research to discover it.

9: Describe your programming habits

There are a number of variations on this question, some of which just ask about things such as:

  • Source control
  • Testing
  • Variable/file/class/whatever naming
  • Application architecture decisions

Some things we do by habit are not flattering when we answer these questions, but it is because of circumstances outside of your control. For example, if your current employer does not have a source control system, do not say, "I do not use source control" because it makes you look awful! Instead, an answer such as, "My current employer does not have a source control system, but I have used TFS at a previous employer, and I use Mercurial at home for personal projects" will be much better.

Other times, we simply have bad habits; in those cases, it is better to recognize them and show that you are trying to change them. You could say something like, "I tend to not write as many unit tests as I should, but I have been working hard to ensure greater code coverage." Of course, don't lie about this. But employers like to find people with enough self-awareness to see and correct their flaws, and the honesty to be able to discuss them.

10: Tell us a little bit about yourself

Often, job candidates go way off the deep end on this question, talking about things they do not need to be discussing in a job interview, personal stories and relationships, and so on. Or worse, they bring up things that present them in an unflattering light. What the interviewer is really looking to learn is how your personality relates to the job of software development. For example, if you enjoy restoring antique furniture, you could point out that it requires a lot of patience, eye for detail, research, and so on. Of course, you will want to talk about your personality traits as well. Unusual experiences or education can be brought up here, too. What you definitely do not want to do is talk too long. Try to make it a back-and-forth conversation, but if it isn't, limit your time to a few minutes and don't trip all over yourself trying to cram in every last detail.


Justin James is the Lead Architect for Conigent.


some developers dont like to talk much and prefer to code. let developers show their coding skills, it will be best for both sides. #2 some time ago I was invited to pass an online coding testing at and it was good way for me to show my knowledge.


#9 collect and ask expereince people then browse online


it was a long time ago, though, in a tiny company. Never had to do it for any substantial job. I agree context is important; as you write, sometimes tech changes such that something hard has become easy or automated (or both; the obvious example is the Y2K issue). Frankly, my biggest challenge as a developer are not programming but conflicting requirements passed along by BAs who know the business but do not understand how programs work. Finally, thank you for pointing out source code management. Most companies use some sort of product; some use nothing other than a slew of PDS files, sometimes even without turning on the STATS attribute (zOS, obviously). Source code management is critical. I once worked at a company with an application missing 45% of its source code; imagine how hard that application was to make changes to!


I don't think that every HR manager has too much time to discuss such things deeper. Usually what matters is mainly length of your professional carrier and previous working posts and obviously the reason why you left your last job. The rest can be proven during testing period. Not less important is how much do you value yourself... :)


Which would be challenging, as I am not experienced in all languages, I would probably miss simple syntax errors. #9 describe your programming habits. I find it hard to think of anything but simple answers like, I comment lots, always notate my variables, and I always try to put the longest control path first (usually input and error checking)


@a.vovolka  Of course coding skills are important, but there are other factors involved in the hiring process, like cultural fit, communication and team skills.

I mean after all you will be working with colleges and you will discuss with them on daily bases, so you want to cover that as well on the interview.

But I must admit I never liked brainteasers... and unfortunately I have troubles with this sort of questions. Also I don't see the relevance in them, for starter I believe I have good problem solving skills, but these skills are not applicable for puzzles and riddles... also I like solving sudoku, kakuro, and other games of that nature but this want tell you anything about my math knowledge or algorithmic skills.

#3, unfortunately I found it only on rare occasions that candidate has repo for showing. Although this would help a lot in evaluation process, without it interviewer can still manage, for example you can send him some preliminary coding tests (like these that you could then review and ask him to explain his decisions.

Justin James
Justin James

The deeper, technical questions will be asked by the "hiring manager" (the person in the department with the opening who will be supervising the new employee). Any company that relies solely upon HR doing the hiring (and yes, I've seen these!) is in deep trouble because, as you mentioned, they don't have the ability to dive deep enough. J.Ja


... in 1983. (This was for a university lab demonstrator post, and the interview panel wanted me to show that I did have my claimed level of proficiency in the main language - Fortran in that case.) I was asked to take a quick look at a code print-out and show the interview panel where the four errors were located. They were more than slightly surprised when I had found six clear errors in not much more than three minutes (it was only a single page of code). Their surprise was partly due to the fact that the panel had two technical experts who were supposed to be able to spot all the errors in a piece of code like that. (They didn't say what the source of the test code was. It could have been something turned out as an exercise by one of their students.) I cannot now remember whether they subsequently offered me the job, or whether my being technically more capable than their "experts" had made them think better of the idea!

Editor's Picks