Interview projects

Author: Dave Cassel  |  Category: Software Industry

I’m in the process of changing jobs. After 5+ years working with Lockheed Martin, I’m moving to Mark Logic. The process of finding a new company gave me a topic to discuss here.

I interviewed with two companies, and both required something I hadn’t been asked to do before: complete a project as part of the interview process. In one case, I got to pick my own project within some parameters, including basing the project on the company’s software. For the other, I was given a smaller-scope, more specific task.

When I’ve discussed this with friends, the response often starts with snickers about “that’s one way to get some work done cheap.” I think that response leads to the first rule of requiring a project for your interviews: make it something that clearly isn’t going to be used directly. Otherwise, it’s exploitative. Fortunately, that wasn’t a problem with either company I talked to.

Still, it’s a lot of work that may or may not lead to any return. So why would I be willing to do it? A couple reasons.

First, I had established confidence in both companies that I would want to work for them. In one case, I had a phone interview in which I got to ask lots of questions, then I did the small project, and then I went to their office for the full interview. For the other, I had the full interview first and then did a project. But in both cases, I started the project with reason to think the company would be worth the effort.

Second, I had the confidence in my abilities to think the effort would pay off with an offer. In fact, things did go well with both companies and I took the job with one. Had I not had confidence that I would be able to make a good impression with the project, I would have been much more reluctant to do it.

That leads to my third point, which is the big one. When I go to work for a company, I want to know that the company is going to be successful. That generally comes down to the people who work for the company. So here’s the rub: I couldn’t just talk my way through these interviews, I had to demonstrate that I knew what I was doing — and so did everybody else who works there. That was the realization that made it worth the effort for me. I’m sure they lose some applicants who think they shouldn’t have to prove themselves, but the fact is, it’s hard to tell from an interview how good a techie is. And if they lose a few strong applicants to weed out lots of weak ones, I’d say that’s a fair trade.

I hadn’t seen this approach of requiring a project before, but when I brought it up with my dad, he told me an interesting story:

As part of my interview process … in 1984, I was handed a pad of paper and a pencil, placed in a private office, and instructed to write something in one hour. Neatness and formatting didn’t count–an admin would type it up (pre-PC days). The topic was totally my choice (although I expect a perfect sonnet, one-act play, or themed set of haiku poems would have been misinterpreted). The objective was to assess my ability to write, as well as to think under pressure. We don’t do that any more, unfortunately. It was a good idea. If we did it today, we would probably hire no one. ;-)

Very interesting. I think this makes a lot of sense. And if I needed a writer, I’d probably be willing to hire someone who could produce a sonnet on the spot.

So I like this approach of doing a project in the interview, but I think there is room to improve it. First, I think you can get the benefits of a project within a reasonably small number of hours by either allowing an applicant to submit prior work, or by providing a partial/imperfect solution to a problem and asking the applicant to finish it. (After all, it seems most projects are modifications to existing code bases, rather than starting from scratch.) One company told me the project should take 2-3 hours (the solution consisted of identifying an appropriate algorithm, finding an available implementation, and building something around the library to solve the problem). The other company didn’t provide guidance about how long it should take, but it definitely took more than 2-3 hours — after all, I had to learn how to build an app using their software.

The second improvement I would make comes after the project is done. In both cases, the company  had one or more of their techies review my submission. I would take it beyond that, and make discussing the project part of the interview. “So, I noticed that you applied this pattern/used this language here. What led you to that approach? How is this better than approach B?” For completing a partial solution: “what  is good (or  wrong) about the partial solution?”.

Discussing the project gives the candidate a chance to strut his or her stuff without the interviewer having to wonder if the applicant is just BS’ing. It also means that if the reviewer doesn’t like the way something was done, the applicant has a chance to explain, perhaps convincing the reviewer that the approach was valid.

This approach has an important implication — if the order is phone interview, project, full interview, then 1) the phone interview really needs to let the candidate assess the likelihood of wanting to work there — this can’t be a 5-minute phone screen; and 2) because of the remaining uncertainty, the project scope does need to be limited.

Bottom line, if I get to the stage of hiring developers at some point in my career, I will want to apply the project approach, and I won’t object if I’m asked to do one in future interviews. After all, if you get the job, you’ll probably spend some number of years there. Isn’t it worth spending 5 hours or so to make sure you’re a good fit? Especially for the confidence you’ll have in the company  knowing everybody there already had to do the same thing.

Tags: ,

5 Responses to “Interview projects”

  1. Dustin Getz Says:

    I’ve heard of a high performing company asking for a link to a candidates GitHub–and only after passing this prior work test, will they look at your resume.

    One side effect from hiring like this is you vastly restrict your applicant pool, and thus will need to incent the candidate to relocate. Industry median salary probably won’t cut it.

  2. Dave Cassel Says:

    Interesting, I hadn’t heard of the git test. I understand the appeal of it, because it’s simple, but as you say, it will disqualify a lot of people. I’ve been developing professionally since ’96, but I would have nothing to show. I think what test selects for is 1) people who use Git (and are presumably up to date on technology, and 2) people who contribute to Open Source projects. Both are good to have, but, by themselves, I don’t see that either means you’re a solid developer.

    All the same, that’s an interesting criterion. Anybody heard of other ones?

  3. Dustin Getz Says:

    I think they just want to restrict applicants to those who have built something nontrivial outside of work. Kind of like, a test for passion. I’m sure mentioning Trovez would get someone like you through the gate.

  4. Dave Cassel Says:

    Now that — the passion test — is something I can buy into.

    Funny story: the team I’ve worked with the last ~2 years, I got to by applying for a job I wasn’t actually qualified for. Naturally, I didn’t get that position (didn’t expect to), but having Trovz on my resume showed enough passion that they found a different position for me. Side project FTW!

  5. Geert Josten Says:

    I think asking an applicant to do some coding is a good way of getting an overall impression of the applicant. Phone and in-person contact, particularly short ones like for job interviews, can give an inaccurate impression of someone. First impressions are not always true, and hard to adjust if not using various approaches to get to know someone better.

    The code itself is a small confirmation of someones skills, but there is so much more to it. Did the applicant understand what had to be done? How did he/she approach the challenge? Was it difficult or easy for him? Can he/she explain how and why? Was there attention for detail? And did the work appeal to the applicant?

    I agree it has to be small, just about enough to show a bit of technical skills, and all the other things I mentioned. I applied such assessments myself on applicant too by the way, with success.. :-)

Leave a Reply