Many years back when I attended an interview conducted by a UK based software development company. What they did was first get me to introduce myself over Skype, with their counterpart at UK. After exchanging few questions & answers, I was given a task broken down into few parts. It comprises of a true/false kind of theory test & 2-3 coding tasks. I was told to bring that home and submit my solution the following day via email. Those problem statements are nothing complicated, like to write a function that convert any figure into words.

Now do all that without a computer, compiler, everything on the whiteboard and a marker pen within 30-60 minutes.

You just described my programming exam back then in university.
The only different is we did that on a piece of paper instead of whiteboard. We were given a problem statement and require to write the code on a paper, similar to writing an essay.
I attended another interview by a local company based at KL with the similar question too, where I was asked to write the code on a piece of paper.

Which probably explains why so many companies complain about not being able to hire 'quality' programmers. Their interview process is broken because it is dominated by egoistic nerdy programmers who cannot see beyond those tests.

When I interviewed candidates I never make them do those tests. The ones I hire was able to do the work anyway so it wasn't an issue.

My only complaint is lack of application of the job position.

Wished all my interviewers have your mindset. definitely agree with your points. I don't fancy interviewers that judge a candidate based on whether he/she still remember the language syntax/detailed implementation of some data structure/algo that one has studied like eons ago which can be easily referenced via google nowadays.

What's your opinion of wkkay's kind of test? (post #12 on page 1)

it pretty much simulates a real world situation. open book type of test, especially on the time limit where you're rushing to fix an urgent issue before the deadline.

On the contrary, I agree with wkkay, and that we can sniff out bs better (faster, and more consistently) by giving a coding test and seeing how you actually try to solve the problem. e.g. Touch typist? Which code editor? Can function well in new environments? What excuses given if something's not working?

It's all in the how and what coding test you give. The downside is that this only works well more the more experienced interviewer.

The test method is not very clear since we do not have a clear understanding of what the problem is.

At the very least he provides a pc and tools to do it.

The ones I am talking about are those whiteboard/paper stuff. NO hardware allowed. No googling.

But you have to understand one thing. Depending on the nature of the problem, 60 minutes may or may not be enough, so unless we know what question he is asking, we can't really say if it's a fair question for the candidate or not. The software the candidate wants to use also might take some time to download if necessary so he might exceed 60 minutes if problems crop up.

But the fact remains this. There will be less and less interest in such jobs in the future precisely because of the way interviews are conducted by egoistic programmers who're made to be in charge of the interview process.

The very same nerdy egoistic group of insecure people who have not moved on from that anti-social behaviour will be the ones who would eventually drive away interests in such jobs, and already declining pool of applicants.

Eventually when companies still cannot find the required talent, they may need to revise their hiring process and see if their developers/programmers are inadvertently sabotaging the process because of their egos.

Once again, if you can't smell bs during verbal interview and require coding tests to do it, then you as a programmer/software engineer, lack soft skills and good judgement.

I wonder why you come out so strongly against tests. Are you approaching it from the point of view of a candidate or from the point of view of the interviewer.

Candidate:
- all these stupid tests, why am I standing here at the whiteboard, can't even use google to look up references?
- they want me to write 500 lines of C code with pen an paper? Does it need to compile without error?
- I don't remember how to do this. I left college 5 years ago.
- this task would take 5 days, and you want me to do it in one hour?
- I don't see how this is relevant
- I'm tired of doing all these tests. An interview will take only 15 minutes tops. Hour long tests are too long. I've 8 other interviews to go to today.

Interviewer:
- if you need to use a computer to look up references, you should ask. We give you extra points for that
- only broad outline of an algorithm in English
- if you forget or don't know, we expect you teach yourself using the Internet. And do it quickly and efficiently
- we only want an outline of how you would approach the problem, and start a llittle bit of the detailed work
- you don't know what's relevant, you haven't worked here yet. Or, we're testing something else indirectly, not what you think
- so many candidates, half cannot write any program at all, how do I tell them apart? Should I spend 15 minutes talking to each one or spend 30 minutes making a test

Test can be made badly yes. But I don't think tests are always bad.

In an ideal situation, the interviewer would be able to tell just by talking to the candidate, but in real life,, the situation is not always ideal.

What if the interviewer is not that good an interviewer (because that is not his primary job function), or they are hiring someone to plug a hole in their expertise rather than hire a junior/assistant for an existing programmer? Think of a smaller company of 20-50 people, rather than a large one of several hundred with full time HR staff.

'Chat' interview will just make bullshiter/textbooker looks more promising.

A simple test will just weed out large portion of these people.

Hehe.. Last time 2007 .i ask one simple thing.create hello world...in any lang.pening boh

@wKkaY, @dkk

Regarding my interview approach suggested in post #19, do you think it is good way?

True enough. My Current job, when i go through with interview with this company First Phrase some chit-chat(self intro to HR), 2nd Phrase taken to a computer with a question ready on the able. Choose one question to code. Surprisingly a lot of people gave up half way.

I think it is a pretty sane approach.

imho having some written coding test during interview isn't inherently a bad thing.
key is how it is evaluated.

expecting a full working code with perfect optimization, etc... if there is any candidate that fully meets this expectation, it would be safe to say that odds are the company can't afford them

a more realistic expectation would be to see how the candidate reacts.
does he freeze up? does he give up and say i don't know? does he come up with an alternative i.e. pseudo?
this can tell a lot about the candidate and can somewhat help help gauge the experience they have


on a more specific note on ts original post.. it seems to be gripe about the interviewer testing specifically on specific areas while ignoring the rest.
it can be that this is to fill a very specific spot which needs that specific set of skills/knowledge. this "plug-n-play" approach is actually quite common although the effectiveness is questionable. i've seen some department in my company do this. they even tag on a referral incentive of upwards 4k and the result was over half a year and no success

This guy's experience in hiring developers mirrors mine. That's how I find candidates too.

http://devinterviews.pen.io/


Hiring Developers: You're Doing It Wrong

When Evan Carmi posted his Google job interview experience (http://ecarmi.org/writing/google-internship/ ) on HN, I felt reminded of my bygone startup days. In over a decade of "modern" IT startup job interviews we have made no progress whatsoever. If anything, I was part of the problem there for a few years. I simply copied a hiring mechanism that seemed like a standard at the time, and in doing so I failed miserably at the most important goals a company should observe when looking for new developers. Today the tech front pages are full of Larry Page's efforts to turn around the company, but I think performance problems at developer-centric companies may to a large part be burned into their DNA by a deeply faulty hiring process.

How We Did It
‾‾‾‾‾‾‾‾‾‾‾‾‾
My cofounder and I were running a small web development shop in Germany. We had started working literally out of my friend's basement. Over time, we grew, and moved into real office space. At first it was easy to find new employees, we could just ask our friends to come in and work for us. Of course, that model didn't scale, but it performed a very important function: it made sure we hired people that were a good fit for the company, both on a personal and a professional level. Then came the day when we needed to fill positions by bringing in people from the outside.

One of the redeeming features of the German regional unemployment offices is they will send you a large stack of CVs on demand, within a few hours of calling them on the phone. I was pleasantly surprised that we didn't have to hire an agency to do this. Together with the CVs we already had from people who applied to the job posting on our website, we now had some sifting to do. In the end, we agreed on about a dozen of the best and invited them for an interview. This is the part where everything went wrong:

The Standard Dev Interview
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
A candidate would come in, usually all dressed up in their best suit and tie, we'd sit down and have a talk. That talk was essentially like an oral exam in college. I would ask them to code algorithms for all the usual cute little CS problems and I'd get answers with wildly varying qualities. Some were shooting their pre-canned answers at me with unreasonable speed. They were prepared for exactly this kind of interview. Others would break under the "pressure", barely able to continue the interview.

To be honest, when we first started doing this I had to look up these puzzles in advance, mainly to make sure I didn't embarrass myself. This should have been the first warning sign that maybe we weren't exactly testing for skills that were most relevant to our requirements. If these doubts occurred to me, I must have dismissed them very quickly. After all, it was the way everyone approached the interview process.

Of course, we ended up hiring the candidate with the smoothest answers. Inevitably, the next job openings came, we did it again and again in the same fashion, for the rest of the company's lifetime. If this sounds familiar to you, you are clearly not alone.

Actual Job Performance
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
But how did the candidates we selected measure up? The truth is, we got very mixed results. Many of them were average, very few were excellent, and some were absolutely awful fits for their positions. So at best, the interview had no actual effect on the quality of people we were selecting, and I'm afraid that at worst, we may have skewed the scale in favor of the bad ones.

What does bad and good even mean in this context? Let's have a look some of the benchmarks that I consider important:

Company Culture. In hindsight, one of the most important features a new employee should have is compatibility with the spirit of the people who already work there. The Standard Dev Interview performed worst in this area, for obvious reasons. It's difficult to judge people's personalities in interviews because they are not exactly themselves. In fact, they're incentivized not to be themselves.

Programming Competence. Somewhat counterintuitively, the code examples done during the interview were a bad indicator for actual competence on the job. Real world projects rarely consist of implementing binary searches without access to a parser or literature. It turned out that employees who had done very well in the code examples were not always able to transfer theoretical knowledge into practical solutions. Having candidates write sorting algos on the whiteboard is a method that rewards people with great and precise short-term memory who come prepared for exactly these kinds of questions. In our case, we needed resourceful coders who could write neat, stable, and elegant software - and the interview process wasn't delivering them to us.

Project Management. People who did well in the interview were not necessarily good team mates or even good presenters in front of our customers. This result, too, was surprising to me. Turns out, sucking up to an interviewer for an hour is a completely different skill set than, say, being good at coordinating with your coworkers or the people who pay our bills. Nor was their interview performance indicative of the ability to write good documentation or how to behave in online communications.

The Result
‾‾‾‾‾‾‾‾‾‾
The results of a hiring process such as this may be one of the factors responsible for a company to lose its startup spirit and its creative soul. This was certainly the case with our company. As the CEO our ultimate failure was certainly my fault, however, having the wrong people on the job was a large part of the company's inability to deliver the quality and quantity of output needed to sustain it. Infighting poisoned our teams. Incompetence was covered up with good presentation skills and ass-kissing. Good people left the company because they hated the new atmosphere.

Though I had to let go many people for different reasons over the years and in the end had to deliver the hardest speech of my life on the morning I dissolved the company, I only went "full Trump" once on an employee. It was the one who had displayed the best interview performance and the best academic references of them all only a year before.

Sure, that's an extreme example. Most companies succeed regardless. But I still believe we can vastly improve the chances of finding candidates that are good fits by radically changing the way we do interviews. And in our case, that would probably have made all the difference in the world.

An Alternative
‾‾‾‾‾‾‾‾‾‾‾‾‾‾
So what should a developer job interview look like then? Simple: eliminate the exam part of the interview altogether. Instead, ask a few open-ended questions that invite your candidates to elaborate about their programming work.

- What's the last project you worked on at your former employer?
- Tell me about some of your favorite projects.
- What projects are you working on in your spare time?
- What online hacker communities do you participate in?
- Tell me about some (programming/technical) issues that you feel passionately about.

These questions are designed to reveal a great deal about the person you have in front of you. They can help you decide whether the candidate is interested in the same things as you, whether you like their way of thinking, and where their real interests lie. It's tougher for them to bullshit their way through here, because the interviewer can drill deeper into a large number of issues as they present themselves.

What about actual coding ability? Well, take a few moments after the interview and look into some code the candidate wrote. Maybe for an open source project, maybe they have to send you something that's not public, doesn't matter. Looking at actual production code tells you so much more than having them write contrived fiveliners on the whiteboard.

I'm sure you can come up with even more questions and other ways to engage the interviewee. At this point, pretty much any idea will be an improvement.

Nay-saying
‾‾‾‾‾‾‾‾‾‾
Most people are quick to defend the status quo, and sure, that's a rewarding position to hold. It's risk free and you can always fall back on the old argument "a lot of smart, rich and successful people do it the old way, so my money is on whatever they are doing".

❜❜Nice, but that doesn't work for large, successful companies. Your idea doesn't scale.❛❛
Sure it scales, in terms of effort per interview there is no difference. There is no reason this couldn't work in larger companies. In the end, the interviewer always makes a personal and deeply subjective decision, I'm merely suggesting a way that delivers more relevant information for that purpose.

❜❜The best programmers have no spare time projects.❛❛ or: ❜❜The most talented people I know work from 9 to 5 and then go home to watch football/be with their families/whatever.❛❛
This is not my experience. I'm not saying that a good programmer should not have a life. But I do believe that a certain amount of enthusiasm for programming is called for. And really, if you have such a great skill, not using it for fun seems kind of wasteful to me.

❜❜In my spare time I'm working on making the next million for my company. Oh, when I'm not working for my company? I'm with my family or friends.❛❛ (verbatim from http://news.ycombinator.com/item?id=2385148)
That's great, those people can surely show me something they have been working on. I would, however, consider the lack of any hobby projects a warning sign for _some_ development jobs.

Final Thoughts
‾‾‾‾‾‾‾‾‾‾‾‾
It has been my experience that the traditional developer interview is insufficient at finding good candidates. While the typical whiteboard coding exercises correlate somewhat with general CS competence, they are poor indicators of actual programming performance. It is my contention that we have been doing them this way for years simply because they're easy to administer, but the data that's coming out of these interviews is largely irrelevant at best. We as an industry should move to more personalized interview questions that focus on the entirety of a developer's skill set. Also, I believe it is more productive to judge production code as opposed to abstract modular puzzles that have no real connection to the actual job in question. Most importantly, I am convinced that gaining insight into the developer's real personality is just as important as checking for professional competence, because one bad fit can destroy an entire team.

The above article is not about good developers. It is broader and about good employees in software development job setting.

Let me say about other things. There are probably two types of smooth-talking talented developers. I can't back up these claims but it is solely by my readings and observations. And only one type of not so smooth-talking interviewees.

First type is all-rounded talented i.e. he/she can write beautiful and accurate code on whiteboard as well as a smooth-talker.

The second type is he/she can't write code in a bat (i.e. while somebody's watching but how do you now that because he/she could by lying) but is a smooth-talker.

With regard to the second type, the only way is to examine his/her coding ability online and gauge his talent and make sure you're better than him/her in order to be a good judge.

The other one is antisocial and surprisingly he/she could be talented and you have to refer to your company's culture whether he/she is good fit.

All in all finding good people is tough.

@TheSolver, in your opinion, what is a good way to hire great programmers?

no such animal really.

here's something from a few years back, during a conference when people from Pivotal (before they got bought over) were describing how they work and the emphasis on pair programming, and how they really adhere to that despite having their offers being turned down some of the people that they really want to hire because of the enforced pair programming bit.

the presentation after that was by somebody from GitHub, also describing how they work, and the first thing they said was that they don't do pair programming.

the best you can do is to hire people who can fit into your organisation well and can adapt well to the technology stack that you're using.