How to estimate the quality of an employer's code base in an interview for a programming job?

September 12, 2008 5:39 AM

I have an upcoming interview for a programming job. I'd like to find out a bit about the quality of the code of the product I'd be assigned to develop, i.e. is it dailywtf material or decent enough. Any ideas how to get some information out of the interviewers, at least some of whom are assumed to be technical people?

Some good indicators include things in the Joel Test: if the company fails on many of these counts, it's a safe bet that the coders aren't too "professional" and probably don't know what they're doing, and the code will most likely be similarly bad.

Asking "is your code any good" probably won't produce an useful answer, or make me look too good. It's probably a better idea to ask about things similar to the Joel Test, things that are closely connected to the code or the coding process, and then form a good enough picture from this data. Asking coders or other well informed technical people good questions is crucial, so what type of questions would you ask, and what other telltale signs would you look for?

posted by lifeless to work & money (12 comments total)

Well first of all you can learn a lot about what the team is like just by the kinds of questions they ask in the interview. If all of the questions are along the lines of "What are your personal strengths and weaknesses? How would you rate your Java skills?" and they don't ask any tough technical questions or ask you to write code, it's a bad sign. It's not usually possible to get a good team that writes good code without having in-depth interviews.

The best question I know of for getting a good feel for a team is "Let's say feature X was requested or bug Y was reported, what is your process to plan, write, and eventually release the code?" Their answer to that will answer a lot of Joel's questions and other important ones, and if they are vague about anything you can always ask follow up questions. Other good process questions might be "Do you refactor or otherwise modify the core design of your code when major changes are made?" and "Do you have formal coding standards and if so what are the main points?". You could also probably ask specific technical questions, such as "Do you use many global variables in your code?" and "Do you separate UI code from program logic?".
posted by burnmp3s at 6:09 AM on September 12 [1 favorite]

Definitely revision control, such as subversion or cvs, and a bug tracking system like bugzilla. I use primarily C++, so I'm interested in knowing if they use STL, are familiar with design patterns, follow common code structure guidelines for the language/platform, and as burnmp3s mentioned keeping the UI separate from the algorithms and utility library code.

This may depend on the company size and whether the application is for in-house use or a shrink-wrap product. I'm used to in-house apps, working alone, and being close to the people using the software, so that if there's a problem I fix it the same day, push out a new release, and everyone is happy.

I tend to get anal when managers try to implement things like mandatory code reviews before a commit to the trunk (more of an issue with nightly builds, since a break tends to waste time finger-pointing). Mostly an issue with larger companies, and managers that have come from larger companies and try to apply the same practices they're used to.
posted by hungrysquirrels at 6:50 AM on September 12

I'd like to find out a bit about the quality of the code of the product I'd be assigned to develop, i.e. is it dailywtf material or decent enough.

You could assume that code quality will be reflected in final product performance. Then you could ask how they evaluate prerelease products compared to their own and their competitors' released products; and how they would respond if these comparisons were unfavourable.
posted by Mike1024 at 7:03 AM on September 12

Another option is to sign an NDA, volunteer for a week or two, or a short-term contract, before going full-time. Or just accept the offer and quit if you don't like the code and environment, probably burns some bridges though.
posted by hungrysquirrels at 7:14 AM on September 12

One good question to ask is "what kinds of problems do you guys have in your code", or "what's the hardest bug you've had to fix?" You can learn a lot from someone by what they consider challenging.

You're smart to reverse the interview and ask them some questions. Don't do too much though lest you come across as arrogant.
posted by Nelson at 7:48 AM on September 12

Good shops have good process. You're expected to interview them just as they interview you, so ask questions about what a typical week on the job is like and how they do certain things, do they have a mandated style, naming conventions, etc etc. It's good for you to demonstrate that you have a good grasp of these things anyway, so this gets you the information you want and promotes you as a person who knows how to get things done right.
posted by phearlez at 8:23 AM on September 12

I'd ask whether their code is well documented, and what the prevailing attitude is about in-code comments.

How long would they expect it to take a new programmer to become familiar with the existing code base?

If there's a bug, do they favor a "do whatever's necessary to fix it fast" approach or a "do it right even if it takes longer" strategy? You can make that question a bit more diplomatic by couching it in terms of how they deal with business pressures. There's always a give-and-take between the customers and sales people who want things changed NOW, and the developers who want to do it right so it's easier to maintain later. If they do take the quick band-aid approach to keep customers happy, do they ever have time to go back and fix it properly?

Get a sense for how they determine their project deadlines - is it based on when marketing "needs" the thing done, or is it based on a realistic timeline for development? Obviously there has to be a balance between the two, but different companies find that balance on different ends of the spectrum. If the deadlines are set without regard to how long the job will take, and especially if management is not willing or able to hire more people to handle the compressed timeline, you can expect sloppy code (not to mention disgruntled coders who are sick of working overtime).
posted by vytae at 10:02 AM on September 12

You're smart to reverse the interview and ask them some questions. Don't do too much though lest you come across as arrogant.

Gotta say, I think this is completely wrong - if the last guy I interviewed had taken control of the process and started selling himself and asking me probing questions, I would have been delighted - that's exactly the sort of person I want to be working alongside. God knows I gave him enough opportunities, but he just sat there fiddling with his tie. Oh well, maybe the next one will have a bit of life in him.

I might ask who did their interaction design, or to see some of their project documentation, but I think burnmp3s question is better.
posted by Leon at 1:19 PM on September 12

nth'ing reversing the interview and asking them good questions. Act as though you're a consultant they've hired to work on their code, and ask them questions you'd need in order to get a sense of their needs and the challenges they're facing.
posted by lsemel at 4:47 PM on September 12

burnmp3s has it exactly right, and that's a great set of questions as well. A good shop won't be offended by that kind of questioning either, so there's no reason to put on kid gloves.

Where I work, candidates get a good look at our code during the evaluation process. In fact, we have them make a few simple changes to our system as an exercise. So, you might just ask if you can see the code for yourself. Not all shops are paralyzed by IP paranoia.
posted by chrchr at 6:14 PM on September 12

Excellent suggestions so far, even better insights than I dared hope for. Thank you all, this thread will really help me get a nice array of questions together.
posted by lifeless at 6:55 AM on September 13

a little late on this one...but I just wanted to make some more suggestions for future reference.

The thing about the joel test is that it just sets a minimum level of process maturity. A shop with all of the joel test items doesn't necessarily have great code, just decent practices. On the other hand, a shop with few of the joel test items is FAIL.

If you're just looking for "decent enough", then most of the stuff here is good. The really big ones IMHO on the Joel Test are #1, #4, and #10. You can't work without source control and without some proper QA/testing. The other things are great, but you can live without them.

If you are looking for a great team, you want to find a company that has good processes and can even explain why their processes are good (as opposed to just dumb bureaucracy). A truly great development team will even reevaluate and actively try to improve their processes over time.
posted by kenliu at 9:37 PM on September 15