Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am a CS undergrad but I landed a programming job last year and I like it a lot. We are currently 3 programmer in the development section of the company and we have to work with pretty much anything were asked to do. We deal with many different languages and learn them as needed for some quick jobs etc etc.

We want to hire a 4th programmer and I'm asked to suggest some students in my class, a year younger, since I failed a class. I don't really know any of these guys except my teammates which I wouldn't suggest. We don't really want to interview them all so I thought we could make a little challenge to help us choose who to interview. We're in need of someone who understand the business even though they're new to it, and likes to learn new stuff and code. Any idea on a programming challenge or a kind of letter saying why we should take them?

TL;DR: We need a new undergrad programmer, we want the best to come to us without interviewing them all. Any challenge or test you could suggest?

share|improve this question
A little white space would make your question so much easier to read. –  DominicMcDonnell Nov 2 '10 at 2:30
add comment

closed as primarily opinion-based by gnat, MichaelT, GlenH7, Kilian Foth, Bart van Ingen Schenau Oct 8 '13 at 9:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers

up vote 15 down vote accepted

Run them through the Programmer Competency Matrix and see where they fall.

Identify problem solvers. People who get 100% on assignments are great, but might not be the most out of the box thinkers. Look for people who ask questions and work around problems without following traditional routes.

We don't really want to interview them all so I thought we could make a little challenge to help us choose who to interview.

This line in particular worries me. You should sit down with every applicant for at least five minutes unless the interaction you have shows such a gross lack of knowledge it would be worthless. You might end up (as mentioned above) with people who are great at finishing specific tasks but lack an overall "big picture" view.

share|improve this answer
That is a great link, thanks for that. –  Jeremy Nov 1 '10 at 20:30
Interesting link indeed. I think I fall about a Level 2 all the way down. –  jcolebrand Nov 1 '10 at 20:38
Huh, I seem to score n or log(n) for the most part, but TDD? Really? I bought a book on unit testing/TDD and rolled with it for about a month to try to convince myself that TDD is great, but it doesn't seem like a very good criterion. –  Rei Miyasaka Dec 27 '10 at 17:42
@Rei: It's good to have written code with TDD as the mindset. In practice I don't think you're able to write everything like that. –  Josh K Dec 27 '10 at 17:55
Ah, right. That's pretty subtle, hah. –  Rei Miyasaka Dec 27 '10 at 18:06
show 1 more comment

three things matter when choosing teammates - or employees, for that matter:

  1. do they really, really want to be there?
  2. do you get along? can you work with them? under stress? and can they work with you?
  3. are they willing and able to learn whatever the job requires?

don't skip the interview process. it's not as serious as getting married, but they are, to some degree, moving in with you

share|improve this answer
add comment

Say that the barrier to interviewing is to solve X problems from Project Euler (http://projecteuler.net/) and at the interview ask to see their answers, and perhaps let them do the FizzBuzz program while you watch.

share|improve this answer
add comment

I'm not sure if you have a large enough candidate base for this, but you could try coming up with a set of problems similar to the puzzles from Facebook, ITA and Google. Each problem should have many different possible solutions. The idea is to look at the submissions and evaluate them based on:

  • Fulfilling requirements
  • Coding standards
  • Design
  • Performance
  • Testing
  • Documentation
  • etc

Invite the best candidates in for interviews, discuss their solutions with them (to validate they actually wrote the code and to further see how they think/work) and then make your pick.

share|improve this answer
Asking people to constantly solve problems is a bad idea. Note I did not downvote this, but I can guess that they were thinking the same thing. If they're worth hiring in the first place, they have a good sample project they can show you that you can discuss code over. –  jcolebrand Nov 1 '10 at 20:39
Uh, why the down vote? –  Yevgeniy Brikman Nov 1 '10 at 20:39
As an undergrad, most of the code I had written was either (a) for class and not terribly discussion-worthy or (b) for a job/internship and therefore not legal to show others. I suppose some undergrads have side projects they could showcase - and I agree this is often a sign of a quality candidate - but just because you don't, doesn't mean you should be ignored. –  Yevgeniy Brikman Nov 1 '10 at 20:42
~ You didn't have even one class that focused on group teamwork and developing an actual application (no matter how small) from design through all the stages of documentation? Ours was a battleship program (hosted on sourceforge but maybe not still active?) and that was the one that I sourced to my current boss when I was interviewing here. –  jcolebrand Nov 1 '10 at 21:16
I plenty of those in my masters program, but not too many in undergrad. And the ones I did have in undergrad were typically not worth showing to a potential employer. Right or wrong, undergrad is typically all about solving a problem: for input X get output Y. Design, coding standards, maintainability, performance, testing, etc are all secondary. It's not that I didn't think about those - I had to know them in internships - it's just that they rarely factor into class work. Discrete math problem sets, mergesort implementations, and SML snippets are not enough to pick out good job candidates. –  Yevgeniy Brikman Nov 1 '10 at 21:29
add comment

The candidate who has written a real program useable by others is the one you want.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.