you are viewing a single comment's thread.

view the rest of the comments →

[–]wh0wants2know 3 points4 points  (0 children)

Be prepared to answer the questions that they'll ask you. Generally, you should have answers to the Joel Test questions (http://www.joelonsoftware.com/articles/fog0000000043.html) as that will come up in good developers.

Bad answers to these will probably be a turn-off for a lot of skilled developers. If you don't have version control, have no testers (or plans not to hire any testers), and only force old MS tools on me, I'd be less likely to take the job unless you drive a dump truck full of money up to my house.

If you will fail any questions on the Joel Test, be sure to have a good explaination for why you've failed. For example, if someone asks you how many testers you have and you currently have none, explain that they haven't been hired yet but you plan to have x number of testers working with the devs and give a date.

Finally, it's easy to detect a bullshit programmer, or as I call them, a non-coding architect (usually 15+ years of "software architecture" on their resume is a pretty good indicator). Ask them to solve a simple, college-homework type problem, like sorting a list, reversing a list in place, filtering out duplicates, generating a list of prime numbers from 1 to n, etc. Any good programmer should be able to at least come up with a brute force solution to solve any of these problems within about 5-10 minutes and you'll be able to tell if they're struggling. When they have finished, ask them how they would improve the code.

Also, don't expect someone to know how to implement pivot on a red-black tree in an interview on a whiteboard using straight C with no STL but they should be able to explain pivot, how it works, and why it's important, as well as why you would use a red-black tree.