Modern Programming: Interview Question?
Sometimes I have to interview people applying for a programming/R&D position in our company. Admittedly, I didn’t know how to conduct an interview, I figured beside the normal chit-chat of who the candidate is I should test their programming abilities with an on-site test.
The mostly used (by companies, #1, #2) on-site tests are logic/programming riddles. Sometimes based on some optimal algorithm solution that is required to really excel at the test (#3). These quiz-logic type of questions assume that the most important skill to test for is solving quiz problems in algorithmic fashion. Now, don’t get me wrong – it is a great skill to have as a programmer. That said, it hardly has anything to do with what most modern computer programmers do every day.
Every day modern programming is not about finding the best algorithms (mostly) but more so a job of managing data and logic in large systems in a way that is desirable by us. Hardly any system that is built really needs elaborate algorithmic solutions. Clearly there are exceptions to this and sometimes it really is needed to be a highly-efficient ninja-coder to squeeze everything out of a system.
There is also the added bonus that some people get stressed doing logic riddles in an interview. Masking their true value at what it is you’re actually looking for in your candidate.
Microsoft was especially known to search for algorithmic programmers/creative thinkers. Even getting to odd questions such as “How Would You Move Mount Fuji?” during an interview. Frankly, I don’t understand what is the value of that question in the interview for a modern programmer.
For that reason, I use a different kind of on-site test to see if someone is a good programmer. Candidates are requested to build a small game roughly equivalent of a memory game in a programming language of their choice (Java/C#/AS3).
Not something that requires fancy algorithms or any insights.
Every-day programming task that is simple, understandable and tests:
- How good is the design/code of the application.
- How clean the programmer writes.
- How understandable and maintainable the code is.
- Does the code contain any/many bugs?
In my opinion, this is about as close as you can get to testing if someone is a good programmer. If someone is good at solving a logic puzzle it has no meaning in regards to how well their practical programmer skills are. Algorithms and puzzles have their place, but they test a different skillset.
Software Programming != Computer Science
This & That 
All interviews are fundamentally flawed. The purpose of an interview is almost never to test if a candidate can actually do the job in question, but rather infer if they can from tiny things like assessing their personality, clothing, experience, etc. I’ve always found interviews a poor method to assess possible employees since before I became a software developer. Think about retail jobs where you get asked something like, “tell me about time that you had to overcome a challenge when working in a team.” How exactly is that relevant to my ability to sell stuff to customers, or even a real judge of how well I work in a team?
For software developers, programming on a whiteboard is nothing like writing a real program. First off when you’re really programming you have an IDE, ability to compile/test your code, and the internet. Take away these three things and a programmer’s skill level drops considerably even if they’re a good programmer, and why shouldn’t it? Why memorize all the methods of some Java GUI class when you remember it was “get… something” and let the IDE’s auto complete show you the options? As frameworks get larger and code reuse becomes more common, a programmer’s job shifts from developing low level algorithms to gluing together libraries and finding pre-existing solutions to problems. If your first response to needing a sorting algorithm is to start hacking away at a quicksort implementation instead of Googling and checking your languages documentation to see if you can find one already implemented, you’re probably a less productive coder than someone who goes for code reuse first and algorithmic details only as a last resort.
Like most things that are flawed though, programming interviews aren’t as easy to fix as they first appear. One factor is time, unless you’re interviewing at Google or some other company with epic long interviews, the interview process consists of about an hour of time for both you and your interviewers. Given the fact a company might interview 20 people to fill 1 position, trying to review a bunch of code they spent all day programming can be a bit too much. Another is risk of cheating; in order to trust they really did the coding, you’ll probably have to have them do it in office. You can observe someone writing code an a whiteboard easily enough, but trying to make sure they didn’t get help from their more experienced peers, payed someone on rentacoder.com to do it, or flat out copied it from the internet somewhere can be difficult when you just tell them to send a memory game next week.
Another thing is that figuring out what kind of employee they’ll be may not have anything to do with their coding abilities. Some people are amazing at coding but can’t handle boring tasks for long and get distracted easily. And even worse for figuring out employee potential, for some people this is a problem and for others they can still be amazing employees even though they only spend half their time getting real work done and the other half wandering slashdot and playing Tetris while ideas peculate (see http://www.joelonsoftware.com/articles/fog0000000339.html ).
The best answer to all of this: internships. A lot of companies that can afford it and need junior programmers have figured this out. Hire 5 interns for a summer and then at the end, give 1 or 2 of the best ones an offer. 3 months of on the job experience can separate the rock star coders from the unskilled code monkeys better than any interview, and summer internships let you avoid the messy problems with firing bad employees.
hey ;),
I agree that interviewing someone is a hard thing to do. I too beleive that interviews really can not tell how certain people will behave when the going gets tough during a project, what their quality over time is, their dedication, social-fitting, all sorts of things that are hard to pin-point in a 1+ hour interview. Still though, interview has it’s merit and sometimes has to be used in small companies (like in mine).
Letting someone program on a white-board or paper is plain silly. It is even more silly to later on judge someone on his memory abilities of how the syntax works exactly or what’s the name of that SDK class. Couldn’t agree more :), the type of interview question I speak of is different. It’s a very practical and simple problem that should be solved using some basic programming skills using a computer and an IDE of your choice, the test is roughly 5 minutes where the canidate explains how and why he coded it in a certain way.
This is my guide-line while interviewing:
* Use any language of choice: C#/Java/etc
* You can google anything, just don’t download a solution.
* Pay attention to code structure and clean design.
* Don’t dedicate too much time on making the GUI look good, functionality is what we’re looking for (you would be suprised, people always spend quiet a while on a button to look just right).
* You have 60-75 minutes.
These guidelines really do put the canidate in a scenario that he will almost certainly face at work very constantly. Here’s a problem, here’s an IDE, internet, solve it in a reasonable time-frame.
Letting someone do their interview-work at home is very much a problem, it can’t really weed out any person with a programmer friend. It’s not completley useless but generally only means something if the test isn’t being completed and sent in.
Figuring out specifics of a canidates personality in any interview – quiet possibly impossible, the whole theme of an interview is I am here to impress and shine. Very hard to get any accurate read on a canidate, you can try to find if a candiate is of reasonable nature, perhaps a hint of if he’ll fit in socially, but probably not a lot more.
Generally a good idea, though I am a bit unsure as to if this idea causes bad blood to occur between employees ? I’ve never seen this idea executed, any thoughts?
Cheers