Software developer interview questions: is speed everything? [closed]

Question

Maybe I'm just less smart than other people but for once I'd like to say that all the puzzles, riddles, code questions and code-on-paper exercises seem just a bit hard to me.

I've always thought of myself as a above-average smart guy, but in an interview when they ask me to solve something or write code on paper in order to ask something, I think I'm just not suited to that.

Maybe I'm not as productive as someone who is totally reactive and a fast-thinker, but I repute myself a creative thinker, someone who is able to solve every problem if he's given enough time (which is not EONS, just some time more than a fast'n'furious minded applicant). In my opinion is not guaranteed that a fast thinker is smarter than a less-fast thinker (not slow, just LESS fast).

Is speed everything in face-to-face-with-paper interviews?

Answer 1

No, speed isn't everything, but it isn't nothing either. The following is an approximate order of best candidate to worst candidate:

1. Correct answer quickly. Note however that if all answers are in this category, I assume my questions haven't been challenging enough.
2. Correct answer slowly. This includes if you ask intelligent questions of the interviewer and use his answers to come up with your solution.
3. An I don't know, but with a clear explanation of the criteria you would use to determine and evaluate the correct solution (i.e. more than "I would google it."). For example, "I don't recall the difference between those two exact containers off the top of my head, but when I select a container, I look at memory usage and the asymptotic complexity of operations like inserts and deletes from the ends or the middle, lookups, and sorts, and select one that best fits my application."
4. A completely unelaborated "I don't know."
5. Incorrect answer quickly.
6. Incorrect answer slowly, although possibly better than 4. and 5. depending on if you showed your thought process and it's clear you would have made the right choice given a compiler and a proper reference.

Answer 2

Speed is one of the factors I take in account when interviewing people.

This factor is more or less important depending on the questions.

1. Basic technical questions

For example, when I ask:

What is the difference between Stack and Queue?

Personally, I expect a nearly-immediate answer.

• Either you know the answer and can immediately talk about FIFO/LIFO,
• or you are unsure, in which case it's not what I expect for a question so simple,
• or you don't know the answer.

On the other hand, as mentioned by Konrad Rudolph, it's "very easy to make mistakes on trivial questions when under stress [...] so this is even more of a reason to take my time".

If you answer immediately, you may make a mistake. If you spend too much time thinking about an answer, the interviewer may believe that you don't remember the answer well.

2. Problem solving

When I ask to solve a problem which requires thinking, the time it takes you to solve it is really not important at all, given the stressful context.

3. Advanced technical questions

Some questions even require thinking. Hurrying things will not help the candidate, since I expect a clear and detailed answer, not the first thing which comes into his mind.

Not only you should take time understanding such question, but also finding a correct solution among others which may come to mind, and finally presenting an answer in an easy to understand way.

That's what you see on Stack Overflow: some questions can be answered in a few seconds and in a few words. Others expect long answers which take time to elaborate.

Notes

Note that if the interview is made by phone, it will hurt you, since the interviewer may think that you're taking time searching for an answer on the internet or in your notes or books or, as suggested by Jeff O, being helped by somebody through Skype.

To conclude, if such interviews are an issue for you, try to show that you have a solid profile in a different way, for example by publishing lots of your source code, explaining in details your personal projects related to software development and showing your interest in them, etc.

Answer 3

In the US the job market for developers is pretty good right now. Nethertheless, it's competitive. If you are hiring someone you may look at 25 resumes and interview 5 candidates in person. Other things being equal, why wouldn't you lean towards the candidate who was faster off the mark? In business it's true that time is money.

"But wait" you cry, "my eventual solution would have been better than theirs!". First, you don't actually know that. The person after you may very well have come up with the same solution in a quarter of the time. There are some very sharp folks out there! Second, just like you, the interviewer is working under constraint. They have "real" work to do, and the interviews have to be squeezed into an absurdly short time frame. The tools they have to assess your competence are crude and unreliable. A candidate who can't make real progress on a problem during the interview is no different from one who simply can't solve the problem. It's not true of course, but in the absence of other information, it's all the interviewer has to go on.

What does this mean for you? Programming problems and puzzles are not going to disappear from interviews. The better you do at them, the more you are going to impress the interviewer. This means you should practice. Find a programmer friend who can put you through mock interviews. There are many, many books and web sites dedicated to passing programming interviews; study them. Since you are weak at interview problems you need to provide the interviewer with other information that demonstrates that "other things are not equal". You need a portfolio of programming projects that will intrigue the interviewer enough to take the time to look at your solutions. Because the interviewer is always pressed for time, and always has another candidate waiting in the hall, you shouldn't expect to just hand the interviewer a thumb drive and tell him to unpack a zip file and browse the source code. It's got to be on-line, and set up so the interviewer can find it instantly, and be wow'ed by your communication and organizational skills.

Answer 4

Your feelings are how most people feel about interviews. Well, at least those who spend more time programming than applying for a job. There are several reasons behind that.

• When you are solving a real world task, you know tons of context from previous work experience; and the task typically has to get 100% completed to be of use. In an interview, you are discovering all of the context while working on the task; and the task may be designed to be only partially completed by all but the very best candidates, so that the variance in candidates' skill sets translates to a variance in how far they get on a particular task. This means that the interview task will be more frustrating than real work. The candidate may feel incompetent, not having fixed (say) a performance or multithreading problem, while even just spotting that problem and being able to explain it and to quantify its impact is considered fairly good performance for the target position.

• Even the "technical part" of a technical interview is expected to throw some light on non-technical aspects of candidate's personality: communication, learning strategies, coping with stress, curiosity, focus and so on. This benefit is usually lost if all the interview questions are so easy that most candidates good enough to join the team are also good enough to not encounter any challenge during the interview. Hence the incentive to design some interview questions (or optional follow-up questions) so that most candidates have to travel to the bottom of their ability and a step beyond.

• Finally, there are lots of cultural or completely random factors popping up in each interview. Mental compatibility between the candidate and the interviewer is one of those. You have usually met each other for the first time in your lives and you are trying to get deep into multiple technical topics together in a fairly limited amount of time, and maybe on an unfavorable medium (coding on a blackboard, designing over phone...)

When you are looking back at a particular interview that went particularly well, ask yourself whether it was due to many questions marvelously matching your unique skills and specializations, or whether anyone of your salary rank would pass this test. The hiring process is a mirror of what skills will your team mates generally possess, and how challenging will be your real work tasks if you get and accept an offer.

When you are looking back at a particular interview that drained you to the bone, do not think of yourself as performing poorly until you know whether you will get an offer or not. If you do, just assume that you have done better than most. Ask yourself where and why.

In a vast majority of cases, what you can say is more important than how fast you say it.

Time to start worrying about your "speed" is after you have had a series of "no offer" outcomes, asked for feedback, and some of the companies mentioned your speed as a factor. If that is already your case, consider learning to articulate your thoughts while still only looking for a solution, so that your way of problem solving becomes more transparent to the interviewers. That's the point of a technical interview, isn't it?

Answer 5

Speed is not enough to judge right candidate. Speed means communication as well. If the candidate has good communication skill he can deliver so fast.

my observation is, some candidate do lot of thinking before answering with solidity and in my perspective they have solid knowledge on the skills on n which they are interviewing.

Sometime, We do look for the candidate those have mix-up of knowledge + energetic as well so that he/she can take up more responsibilities.

I think just speed doesn't work there are other aspects as well.

Answer 6

From my experience, the speed comes with practice. The more the number of questions you solve, the more the number of ideas you would accumulate in solving new problems. So, practice will just help you apply your thought process in the right direction than trial and error where you would backtrack to correct your mistakes during the interview which is perceived as slow problem-solving skills. My two cents!

Answer 7

Speed is not everything in face-to-face-with-paper interviews! But if you're slow then you may well have to compensate.

If you had publically available code on the internet that you could prove you where the author of, then you might want to mention some appropriate bit of it and be prepared to talk about it in detail too.

You could research the company and what their end product may be and show an interest in the company.