views:

348

answers:

6

For all of you that read candidates' sample code: Please provide some examples of what people are looking for when they ask this.

Most of the code I've written in my professional life (C#, Java, PHP) has been pretty domain specific, and I rarely run across something I have to solve using things I learned while earning my computer science degree such as implementing sort algorithms, tree traversal, and the more engineering-oriented aspects of programming.

While I have dealt with complex issues in some (mostly web) applications like database caching or transaction management for example, it's typically not something I implement to fix, rather it's something I resolve by gaining a tighter grasp on whatever API I'm using (nhibernate).

I use design patterns everyday and can talk about them, but again they're not things that I've specifically implemented. The 'complex' problems I most often have to deal with involve designing the domain in an object oriented way. I feel like it would be inappropriate to hand in 5-6 classes and associated interfaces. Typically the programming challenges that I'm faced with that seem like they are very complex at first eventually get refactored to decently OOP'd solutions, and then, they don't look very complex at all.

Is it proper to throw a class hierarchy in my code samples, or should I just rehash some of the more 'clever' things that I did in data structures classes in college, proving that I know how linked lists and such work?

Apologies for the wall o' text.

A: 

I feel the same way sometimes.

I use design patterns everyday and can talk about them, but again they're not things that I've specifically implemented.

I would spin this in a positive light... as you say:

Typically the programming challenges that I'm faced with that seem like they are very complex at first eventually get refactored to decently OOP'd solutions, and then, they don't look very complex at all.

So...

Well, you see, I've found in my experience that when looking at a complex problem, at first, it might seem hard, but after fully understanding the task at hand, a fairly straightforward solution tends to emerge. If I haven't seen that solution yet, I probably haven't truly understood the problem. And for those few tasks that are truly hard, I tend to find that someone else has already considered that problem, and written an elegant solution for me to use. These two cases are true virtually all of the time.

Steve Klabnik
+1  A: 

Another take on your problem - find some "interesting" problem you like and just work on it on your free time. When you have something decent to show, publish it as open source.
Sample code doesn't have to be related to your professional career. In fact for me, the code I am most proud of I wrote in my hobby projects.

shoosh
+5  A: 

From my personal experience, complex problems usually deal with translate some relatively complex interface to something that is easier to deal with. For me, this has historically dealt with abstracting hardware interfaces making it easier to build applications on top of the hardware.

Anyway, back to my point... a complex problem will usually involve using things like sorting, linked-lists or vectors, etc... to greatly simplify something that at first glance looks hard to solve.

Honestly though, when I interview people, I don't ask for something complex. I ask for some code the candidate wrote that he is proud of having written.

When I interview people, I do NOT want them of re-implement sorting routines or linked lists -- that is stuff you do in school and is available in standard libraries. Rather I expect candidates to use the proper tools (which may involve sorting and linked lists) to solve their particular problem. Candidates who successfully combine two or three different concepts get first priority in further interviews.

Anyway, I hope that helps. Good luck in your job hunt!

Kevin
A bunch of these answers helped. I've taken advice from most of the upvoted ones. Thanks.
zmf
+2  A: 

There are probably at least as many answers to this as there are people who ask the question (and I'm not one of the askers). However, I'd estimate that people are looking for a wide variety of things, which could include any or all of:

  • What does the candidate consider is a complex problem? (If the complex problem is a simple sort of an array of integers, then there had better be some exquisite reasons why it is considered complex.)
  • What language does the candidate show me? (If the answer isn't on their CV (resume), then what gives?)
  • How is the code organized, commented? (Since this is presumably some of their best work, it should be well organized and sensibly commented - not over-commented, not under-commented. Is it written without spelling mistakes or cutesy names?)
  • How old is the code? (If they are showing off something that is 10 years old, what have they coded more recently?)
  • Are there any signs of version control? (I regard version control as a sine qua non; if there is no sign of any version control, what do they use, and if they don't use version control, why don't they use it?)
  • How does the candidate explain the problem? (Can the candidate talk, or write, coherently, with good command of their language.)
  • How huge a piece of code do they submit?

These sorts of questions give a general overview of how well the candidate can do the basic programming activities. It is not a perfect system - no system is - but it does at least give some indications.

Jonathan Leffler
+1  A: 

When I conduct an interview, I often will ask this question (or a variant of it) and what I am actually looking for is a view into the candidate’s problem solving skills, basically a description of how the candidate goes about decomposing a complex problem into smaller solvable units of work. Much like math teachers like to see the "working out" part of the question ;-)

Also, FWIW when I ask this question, candidates who prattle on about patterns better damn well know what they are talking about and not just regurgitate the gof book.

Tim Jarvis
A: 

There are a couple of different cases here I think:

Take-home code test: This is where one is given what looks like a simple problem to program like handling various types of employees and what class structure should there be, what methods are there, how is the program strucutures, how are tests set up, what assumptions were made, etc. Lots of possible things to focus in on for what is generally viewed as a 2-12 hour coding project.

Whiteboard code test: This is where some pseudo code is written as well as asking for clarification about what is needed and/or what has priority of time vs. space as well as how well is the structure of what is written and why it is as good as it is. Alternatively, one could be given a code snippet and asked to refactor it which I could see as a nice little exercise.

JB King