What are the tell-tale signs in an interview that a developer is not competent?

Question

I'm specifically talking about interviewing for a position for a very experienced and competent C++/C#/Java systems developer, not a html, javascript web developer position. In my experience nervousness is often not a good indicator, because many good developers get very nervous under pressure, so what is a good indicator?

---

Hmmm... sorry, this didn't pop up when I went to ask this question. I've been told previously I'm not necessarily meant to delete it, but just post a link to the existing one. Please, if people think I should delete it, post a comment here to let me know, quite happy to, it seems very similar to the other one.

... or should I just close it?

Answer 1

Tell them to write code...

Any who's applying for a Senior Developer position should be able to write some code.

Would you hire a magician without see first a magic trick?

Answer 2

I typically read through their resume to see what they say they did in specific on prior projects then ask them a series of easy questions on one of them. So if they way they are a ASP.NET developer I'd ask them something like what is one of the events in the page lifecycle or some softball like that. If they can't answer an easy question on a technology that they have highlighted then it's pretty obvious...

Outside of some sort of real programming task (i.e. really developing something), I'm not sure how much you can make of someone in a single interview outside of getting a sense of base level competency...

Answer 3

Ask them a real world programming problem that is not able to be answered by reciting a chapter of a programming textbook. Problems that you have encountered and that developers have to solve in your environment are ideal, as these are what you will need the new employee to handle.

If you are going to ask for code, which is a fine idea, pseudo code is just fine. Good developers are not characterized by the ability to remember programming language exact syntax; the IDE handles that!

Answer 4

See their response when they hear about something they don't know about, for example, lisp or prolog. If they know vaguely about it, and are interested, it's a good sign. Good developers should be very inquisitive and attentive when someone (hopefully the interviewer) knows about something that it would be helpful for them to know.

Answer 5

Beside letting them write code, I also asked them to debug some. I showed the candidates several problems from "How not to program in c++". I selected short programs and asked them to locate and describe the bug. following the candidate efforts to find an unknown bug were very telling. I tried to make this test game like, to make sure that stress does not play part in the responses. most people liked it and had fun. Even if they did not recognize the bug, what they hypothesized about could show experience, or lack of it.

Answer 6

Obviously, there are tons of things to ask to verify general developer skills, but I have a few "baseline" language-specific suggestions:

When interviewing candidates for a C++ dev position, the first thing I check is that they understand construction/destruction order and how different types of storage classes works. I consider that very basic knowledge (and crucial for writing exception-safe code) when it comes to C++ and if they fail at that, it's a very bad sign. I'm surprised how many people that claim professional C++ knowledge that just don't know how these things work.

When it comes to Java candidates, my first baseline test is that they know how references work in Java (e.g. show them a few different attempts at implementing a swap function and ask how they work / don't work). This is also an area where surprisingly many claim-to-be-pro candidates fail...

I've never interviewed anyone for a C# position, so I have nothing to say there really.

Answer 7

My favorite excercise is to show them the source code for Apache Tomcat’s DefaultServlet and ask them what’s wrong with it. It’s so full of resource leaks and bad practice that a developer that wants to be hired by me needs to find at least two different things to be considered by me as a possible candidate.

Answer 8

Of course, "very nervous under pressure" might well be excusable in an interview, but might also be something for the interviewer to be aware of.

If you have a huge deadline or need your developer to interact with senior management/important client/PR/esteemed visitor/etc. then someone who gets nervous under pressure might very well be someone you want to avoid.

My warning signs in interviewees are a lack of clarity and when the little things haven't been given the care they deserve. Developing is about getting things right on a micro level, possibly more so than on a macro one.

It starts with the CV/resume/application form: almost any typos are a bad thing. If you can't use a spell checker or ask someone to proof your writing, then you aren't showing enough care.

But more generally, waffle and bluster are a sure sign that someone's trying to pull the wool over your eyes - if you ask a question about specific projects or times when they've worked in a particular way, you want detail, you want precision, you want confidence that this person actually did those things and isn't just reporting on the experiences of others.

I mean those little sparks of empathy when you're talking about foo v2.6 and when you mention that little glitch with the grommet driver and they say "oh we got around that by reconfiguring the bar API, it's all in the wotsit implementation - still it was all better in 2.7" - you know they've been there, not just heard someone at the water cooler (or remembered it from some response on the internet about interview questions).

Answer 9

I always like to ask this question:

Given a set of N numbers, how would you find the duplicates?

What I'm fishing for is: Do they grasp the difference between O(N^2) vs O(NlogN).

As they answer, if they need it, I'll provide a few hints to guide them along.

If they suggest a double-for loop O(N^2), I'll inquire if there is a more efficient approach. Or how long they think it would take to run with 10,000,000 numbers.

If they suggest sorting O(NlogN) followed by comparing adjacent values O(N), well that's good enough.

The ones who ask:

• Are these floating-point or integer numbers?
• How wide (8/16/32/64-bit) are these integers?
• How large is the set?
• Or who suggest an array of counters (for small-width integers).
• Or who suggest O(N^2) for very small set sizes.

Those I really want to keep!

But it can be hard to think of all the details under stress & time-pressure.

---

Look, nobody knows everything. Most people can be taught. But when an individual lacks the fundamentals, really basic algorithmic complexity theory, it's going to be an uphill battle.

(And yes, I've had many coworkers straight out of Dilbert who didn't understand what O(N^2) meant and didn't want to learn! Somehow they always got fast-tracked into management...)

---

---

Amended to add:

You seem to be quite a fan of the big-Oh :) - eljenso

I needed something simple/elementary/basic that's common to all structured programming courses of study. We're talking Freshman/Sophomore level here. When you get to the more advanced stuff, people go off in different directions and subfields. It's harder to reliably test.

At the same time, I needed something that would clearly be neglected in those "Learn C++ in 30 days" community-college type classes.

---

Out here in the Real World, I've seen things you would not believe!

• One fellow coder took down the production server with an inappropriate cartesian join. Even after I explained O(N^2) vs O(NlogN), and how to use GROUP-BY & HAVING clauses to achieve O(NlogN), he still couldn't wrap his mind around it. He insisted it was impossible to solve right up until I sent him the code. (All 5 lines of it!)
• Another fellow thought int * foo() { int a; return & a } was an appropriate mechanism for memory allocation. Sadly, he was not the worst member of that particular team. Another programmer, who couldn't manage to grasp a for loop, took top (bottom) honors there.
• At yet another job I was criticized for breaking my code into small methods/functions. Apparently, when my boss wrote code, she just used one big function. Self taught, of course. Same lady eventually arranged for my termination so she could take over and do the coding "correctly". God help them!
• Yet another coder, sadly one of the better members on this particular team, wrote a threading library I needed to use. I asked him where the mutexes where. He said "I tried it without mutexes and it works, so we're not using them". I got hauled out on the carpet for rewriting his code. But that seemed the best course of action to take.

Seriously, I can't make this stuff up.

---

While I'm amending... Two other suggestions:

(1) Give them some simple code and ask them to explain what happens to the stack as the routines execute. Code should involve malloc or new, data on stack (including pointers), manipulation of said data, a function or method call, etc. Keep it short.

(2) Give them a simple problem, such as write code for some basic complex number math (add, subtract, multiple, square root, etc). Point out to them up front how to do the math. (Especially for square root.) Complex number math knowledge is not what you're testing.

See if they come up with an Object-Oriented (OO) solution or a functional decomposition approach.

Some folks do write functional code in C++. That will get ugly & painful real fast!

Answer 10

Obligatory

• The Phone Screen
• The Guerilla Guide to Interviewing

Answer 11

You've had some very good answers so far, but I'd like to make a few additions.

Besides pure coding skills and puzzle solving I usually ask in which style they write their code. I am not interested here in a lot of buzzwords, but what I want to know is if they know how to write clean and readable code. Obviously if you have some code they have written I want to make sure that they have good methods names that provides context to what takes place inside the method. That anything inside that method is of the apropriate abstraction level and not to low detail. If we dont have any code I usually provide a class which is not so clean and nice and ask them how they would refactor it into readable code. If they manage to produce a class that starts off with a high level abstraction and then moves into lower and lower level I am happy. If they think they can add comments to a code that should be split into several to provide apropriate context I wont be impressed.

(I promise I wont rant any more about comments in bad code any more this week)

Answer 12

Well, I'm not a hiring manager anymore (now I'm just a simple coder and thanks for that), but when I did do interviews, I usually asked the candidates to tell me about their all-time best project and tried to get them to explain to me what was so exiting about this.

When people get to pick their favorite topic they are usually eager to talk, and you can expect them to be able to tell a great deal, which is a good way to get the interview started imo. It is also a good opportunity to ask about the candidate's specific role in the project. In my experience this tells a lot about if the candidate was a driving force on the project or just tagging along as well as their ability to understand some technology (and be able to explain it).

I would also ask candidates to talk about a specific technical problem from their past. The problem should be non-trivial and hopefully have caused some headaches. For this I would ask how they approached the problem. Again, looking for specific actions (not how you could potentially do it, but what they actually did). It is not really important if they solved the problem or not. I looking for their ability to describe technical problems and trying to get an idea of the problem solving skills.

Another technique I've used is a variation of Joel's impossible question. Instead of asking a "random" question (like how many mail boxes in Seattle), I would usually pick something from their favorite project / past experience and remove an element from the setup and ask them to talk about how they could work around this obstacle.

Answer 13

When interviewing candidates, I give them some FizzBuzz style questions they should be able to answer. I also give them some very difficult questions that almost no one gets right.

The point to these questions isn't whether or not they can solve the problem, its whether or not they can approach the problem. Can they break the problem down into smaller pieces? Can they formulate and ask insightful questions about the problem? Can they come up with techniques that might shed light on the problem. Solving it is the end goal, but how you get there says a lot.

The worst candidates just freeze up, and can't work on the problem, can't ask questions, and just stare blankly, hoping that something comes to them. The best candidates will discuss with me what they are thinking, what approaches they are rejecting and attempting, and discuss ideas and ask me questions as they work on the problem.

Answer 14

The tell-tale sign that a developer is not competent is when you ask him a question that he doesn't know the answer to and he doesn't say "I don't know."