I've got serious problems with interviews ( I live in the UK ... not sure if my experience is the same for those in the US or else where)

When i was in university over 13 years ago i practice code and definitions on paper - mainly to pass exams

But since leaving uni i coded straight to my computer.... because i code to develop projects (not to pass exams), and with advanced IDEs such as eclipse i can concentrate on developing algorithm. Of course i do analysis on paper - vector maths, algorithms, data-user interactions, image processing, rough pseudo-code analysis... on paper. But never proper coding and never definitions because its never been necessary for my code to work. I get the full picture writing the code direct to my computer.

And i don't need to rehearse concepts in English because i know it. My focus can momentarily shift from a concept (depending on what i'm currently working on) and there are so many... but i can easily reference anything when i need it.

I don't even have to memorise definitions to get complicated code to work.

simple example: don't know the definition of anonymous inner class but i have used it b4 because once i see an example of how its used, i have always used it. My description of how i use didn't cut it with them, I have to define it using some key words.

Ok now with hindsight i can describe it better. But my using it wouldn't necessarily improve and next time it would be something else

In my opinion core algorithm development on computer (not on paper) should be the best way to test the competence and intelligence of a developer

Yet whenever i go for an interview every time again and again and again (despite pre-asking to be tested by writing code to computer) i kept being tested by definitions and crossword-puzzle kind of coding questions on paper (where i can't get- in non-trivial situations- a full picture of the problem)

Then someone calls me dumb... because i scored 6/50

They don't even consider my portfolio-projects - taking the so-called test to over-rule my portfolio

Now i'm forced to work in KFC to pay my bills

Why do employers insist on this way of assessing programmers?

Why are they so naive?

What's the experience of others (not if you a boss your-self) on this forum?

Why do employers insist on this way of assessing programmers?

It differentiates engineers from people who only learned to program.

Don't get me wrong, programming is a fine skill, and you can accomplish great things with nothing more. But the majority of employers are looking for software engineers. They need someone who can function on a team, and much of that is having shared vocabulary, design patterns and concepts.

None of which are addressed by a paper test, especially if it is a multiple choice test. If I get crossword style questions I just say I think it is a bad question (after answering it, or saying I don't know the answer and explain how I would find out the answer).

Being asked how you would detect a loop in a linked list I have been asked twice in interviews. Using a debugger wasn't the right answer ;)

Frankly, most interviewers are really horrible at interviewing. Even the best have trouble reliably recognizing good candidates.

Interviewing is a tricky art, and has little correlation to job performance; but if you want a software job, it's worth learning to interview well.

None of which are addressed by a paper test, especially if it is a multiple choice test. If I get crossword style questions I just say I think it is a bad question (after answering it, or saying I don't know the answer and explain how I would find out the answer).

Being asked how you would detect a loop in a linked list I have been asked twice in interviews. Using a debugger wasn't the right answer ;)

It's not the right answer =) It's actually valuable to know, I had a similar problem I had to solve for work, I needed to actually detect if a graph was recursive, as the graph was getting passed in by a user, so could potentially be poorly set up. One needs to be able to detect it at runtime in those cases.

Then you are the first person I know who has found a use for it ;) in 99% of the cases you use a debugger and correct the code. Knowing about graph theory is a good skill to have though, I'm not arguing against that.

Being asked how you would detect a loop in a linked list I have been asked twice in interviews. Using a debugger wasn't the right answer ;)

Those questions filter for a basic background in algorithms. If you took a data structures course in university, you probably know the answer to that right off the bat.

Keep in mind that the entire interview process is calibrated around that fact that you can't get to know a person in one hour. Assuming that, then you are left with having to filter for the things you can test for in an hour: the kind of basic CS skills taught at university, the ability to think on your feet when faced with an unfamiliar problem, and the ability to function under pressure.

I did maths at uni so I didn't do that. But ferrous is the first person I have heard of that used the algorithm in production. I know the algorithm I just think it is a poor question because it tests academic knowledge rather than practical problem solving. If I had a linked list with a loop my program would hang and I would use a debugger before writing code to validate a list.

Anyway, I agree with the Apochster, interviewers can be bad at identifying good candidates. If you need to do a written test, you should be asking things like "what is this code doing?" rather than what does this syntax mean. Written tests with no feedback are not good interview technique. Communication is the most important skill for a programmer on a team to have if they are competent in coding areas.

The way interviews work at my company, you get interviewed by 8 or 9 people and each one of them will ask you to solve some programming problem. I have interviewed maybe 30 people over the last few years. I do ask people to solve stupid toy problems that might not be very closely related to programming on the job, but I don't judge people on whether they solve the problem or they don't: I want to see how they think and -more importantly- how they communicate. If I we are going to hire this person, he'd better understand me and I'd better understand him, because otherwise we won't be able to work together.

If a candidate gets stuck at some point, I will offer hints, as a way to keep the conversation going. So far I have enjoyed working with everyone that communicated well in my interview. There was only one candidate that I recommended against and ended up working in my group, and I have to admit he is very competent. But I think I would rather work with one of the other people.

After about 15 years of professional experience, I am convinced that the main difficulty in software development is human interaction, not any technical skills. And that's what I am looking for in an interview.