Kris Kemper

I recently checked the statistics for my blog and I was surprised to find that one of top reason that someone came to my blog was because I had tagged a previous article with the “Thoughtworks interview process” or something to that effect. Unfortunately for those people, the article was brief, and didn’t reveal much more than the Thoughtworks interview info page.

Given that I have been involved in the interview process at thoughtworks, I thought I would share my perspective for anyone who’s interested - the perspective of a developer at Thoughtworks that may be interviewing you at some point.

General Considerations

Here are some general consideration that go through my mind when I’m evaluating a candidate.

1. Are you a top notch developer
2. How much do you know about Agile, and do you have experience in Agile
3. Are you a fit for consulting - ie: can you travel, will you be mesh well in a variety of client environments
4. Are you generally interested in Technology
5. Will we want to work with you, are you fun to work with and would I learn from you
6. Are you poly-skilled - will you be able to work in many programming languages, platforms, and frameworks
7. Are you open to learning / are you open to new ideas

Specific Tips

1. Spend some time researching us and have an idea what we care about. This doesn’t mean you have to know a detailed history of the company, but you should have an idea of some higher level points of who/why/what we are.

2. Take the code submission seriously. This is the one of the first major gates that needs to be passed to get to the interview process. It’s your chance to express to us your coding philosophy. Don’t communcate “I don’t care about this part” or “I didn’t have time to do it well.”

3. Don’t try to tell us what you think we want to hear. Don’t try to show that you have more knowledge/experience than you do; it’s very easy to spot that. Be yourself, honestly express what you know and don’t, and what you are interested in, or not.

4. Have fun. We hope to have fun on days were we interview people, and it’s great when the candidates have a good time as well.

5. Get a good nights sleep before the day of the interview. It’s going to be a long day, and you don’t want to try to swing it on 4 hours of sleep.

If you don’t get in, don’t worry

1. There are many points of failure - Our process is not easy. Unlike the way many other companies interview developers, candidates don’t just show up and talk to a few tech-lead or architect people. This means that if you have an “off day” there are more stages that it can affect.

2. Our process has variation - There is no perfect pass/fail criteria in the process. It depends on a myriad of factors that might be different on a different day.

3. Perhaps you just weren’t a good fit overall And that’s okay. No one is able to work anywhere. You are probably exactly what someone is looking for.

4. You might not be ready yet, but that doesn’t mean that you won’t be next time around. Sometimes, there are people that have the right background, and the right attitude, but they are a little short on experience or skill-sets.

Jay Fields recently published a blog post where (amongst many other points) he mentioned the concept of the Net Negative Producing Programmer, referred to as NNPP.

I’d never heard that specific term before and I enjoyed the read. Almost every project that I have worked on had a healthy number of people who’s efforts were borderline negative to the teams productivity. I say borderline because I’ve never actually measured it - but I have worked with people that would take a week to do a days work, and it would be defect ridden when they claimed that it is done.

The part that struck me about the paper though was that it said that dismissal of an NNPP is a last resort. I do agree with the paper that it argues against measuring the person with absolute statistics in making this decision, but on collaborative/agile projects, it’s usually easy to spot the weak links. I can understand that it can be expensive and risky to fire someone, but software teams must have a way of weeding out these individuals, and removing them. I don’t just mean moving them to another team; I believe that they should be laid off. I wouldn’t even feel too bad about it, IT is still a high demand industry, and even the worst of the NNPP will find some giant company to disappear into.

There is a better way however, one that will prevent companies from getting into the position of having to worry about this in the first place. Improve the hiring standards. If you can keep the NNPP’s out of your company in the first place, you don’t have to worry about firing them.

At Thoughtworks, the interview process is pretty rigorous, there are phone interviews, a code submission, logic tests, and lengthy in-person interviews with people of varying roles. The highlight for me is the code submission. It’s pretty telling from looking at a code submission whether the candidate is worth pursuing in the first place. I don’t care how many languages and technologies someone claims to know - if they can’t create an elegant and working solution to a short problem when the expected outputs are provided, then they most likely aren’t top notch.

There is also a scale to the problems, from easy to hard. Personally, botching the easy problem is unacceptable, but I’m a slightly more forgiving with the hardest problem. In general, the reviewers are usually pretty harsh, so, it generally takes a good solution to even be considered acceptable. Oh, and experience level is factored in - junior candidates have to write pretty good code, but an experienced candidate needs to nail the code submission.

It’s a HUGE differentiator. Every company that is serious about staffing the best talent (or even just good talent) should require a code submission.

I’ve even heard of some offices doing pair-programming during the interview. This is also a great idea. Someone may know how to write great code, but still not be good at actually doing it. I’ve paired with (non-Thoughtworks) people that were supposed to have 5+ years of experience and watched them struggle to write a method with a single for-loop and get it to compile. Alternatively, I’ve paired with people that are like some freakish melding of man and machine, writing with blinding speed, and what they write is beautiful. If I owned a company or ran an IT team, I’d do my best to get the freakish cyborg artist types.