[qw]

We had a surprise at my company. The candidate had a masters degree and 2 years experience in a known software company.

We relied too much on the resume and mostly talked during the one hour interview. After hiring the person turned out that our new employee would have had serious issues with FizzBuzz. Maybe even looping through arrays...

When we interview people know we test for basics, regardless of their resume.

[Sorreah]

I'd consider the interviewer as much of a problem as the hire in this case. Talking to someone for an hour and not being able to figure out if they could write basic code? Hiring someone based on their background and not doing a background check (after getting their approval ofcourse)?

[mcguire]

How do you find out if they can write basic code without asking them to write some code?

If you talk about past projects, they talk about architecture and project management. If you ask about code they have written, they say it's all proprietary.

[tkxxx7]

Ask them to think up a way to implement a function to do X. Keep X simple, simplify further until you find common ground. Any other ways to implement? Tradeoffs? What about under this or that constraint?

Ask about some peculiarities of their favorite languages.

Have them describe a recent difficult bug (very insightful - in their description's wording, the scope of the bug itself, steps taken to solve, etc. - but could be 'proprietary').

[ballenf]

At smaller companies who have trouble attracting better talent, avoiding technical questions is a (flawed) way of showing deference to the prime candidate. It's a way for the company to say, you are special to us and we respect you so much you don't have to do tricks for us.

Again, it's flawed, but trying to find and attract talent at a small company who maybe can't pay top dollar makes people take risks like this.

At least that's my experience!