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.

This question already has an answer here:

I've recently started working for an awesome company, on a product which is a steaming pile once you go under the hood.

Apart from asking for a code review (which I doubt I'd get anyway), what are the ways of estimating code quality when interviewing?

share|improve this question

marked as duplicate by gnat, Bart van Ingen Schenau, Dan Pichelman, Robert Harvey, GlenH7 Nov 25 '13 at 12:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
I usually see if my interviewers seem to have a good understanding of the language. If they do they are likely to know goodish code at least. So when you ask them about their code base, if you get answers indicating their dissatisfaction or that they are stuck with legacy, run for the door! That's what I'd do. –  nonsensickle Nov 21 '13 at 10:26

4 Answers 4

up vote 7 down vote accepted

You are correct, you cannot simply ask to see code or do a code review without coming across as a know it all, I'm right, you're wrong type of person.

What you can do, however, is ask other questions that might help you find out more about the company/team's software development process.

  • Do they do unit testing?
  • What kind of code coverage do they aim for?
  • What type of architecture does the project you (the interviewer) currently work on have?
  • How many projects do you typically work on at one time (are they a consultancy with many customers, or a badly swamped IT department with lots of users shouting for change/features etc)
  • What are your testing cycles like? (trying to find out if they actually have testers, do they have separate environments, is it easy to get new servers/VM's for those environments).
  • How are requirements managed (are they agile/waterfall, does the PM deal with it, do they have BA's, Product Managers etc)
  • What tools do you use (are they happy to buy Telerik/Ingragistics components, do they allow open source, do they use any obscure tools you don't want to have to learn, are you the dev restricted in any way)
  • Do team members work vertically (feature based) or horizontally (app layer based)?

This might not get you the answer you are looking for, and of course each project will be different, but it will give you a general feel for how they go about doing things.

share|improve this answer
1  
Great set of questions - also worth mentioning that asking the right questions (like these) at a job interview shows that you're a serious candidate –  Alex G Nov 22 '13 at 11:23
    
@AlexG - yep, good call! –  jmo21 Nov 22 '13 at 11:32

I always just straight-up ask "What's your code like?" Every answer I've gotten has been pretty honest (everything from "pretty clean" to "it's almost unmaintainable" and all points in between). Just asking about what testing framework they use and what their test coverage is will tell you a lot.

Once you're in, don't be afraid to ask for a code review. It's usually much more productive to have somebody explain some unfamiliar code to you than to squint at it for a few hours. They'll hopefully also explain local idioms the code might use (like "we have DAO classes, but all we use them for is to hold the database connection", or "this part doesn't use the same DI framework that the other parts do").

share|improve this answer

Is it really a steaming pile, or is it just your view of it? After all I've seen code that is hugely nasty... but once you get to really understand it you start to understand why they made it the way they did, what design decisions went into it and the odd pieces that everyone knows are sub-optimal (for whatever, usually good, reason) that can make the rest look bad even though its well designed. You'll find that 99% of companies have code like this.

Ultimately, I am a proponent of the view that most people think every piece of code is a steaming pile... hence the drive for the complete rewrite that plagues this industry.

Anyway, last thing you want to do is start asking for a full code review like you're some external auditor with a "I know better than you" attitude. A professional will work with what he has to hand and will endeavour to improve it in ways that are not disruptive.

share|improve this answer
2  
You'll find that 99% of companies have code like this. and the 1% remaining companies eat their market shares. –  user40989 Nov 21 '13 at 11:30
3  
Yes. It really is a steaming pile. It's ridden with copy-paste style code duplication and programming by coincidence. The code base is as brittle as glass. I'm not talking architectural trade-offs here, I'm talking gross negligence. But that was not the question. And no. Not talking about "I know better than you" here either. I'm talking about "I'd like to know how you do things around here", within the limits of being unintrusive. –  cbaby Nov 21 '13 at 14:30
2  
This is not an answer to the question. –  Alex G Nov 21 '13 at 15:29
    
@cbaby ah well, in that case you could clarify your question. Usually you can't realistically tell a good company from a bad one in interview - they'll tell you all kinds of "we're great" answers, and I would think the worst the company the better their answers will be (ie good companies will tell the truth, but that will make them appear to be bad) –  gbjbaanb Nov 22 '13 at 9:55

I've owned several homes in different parts of the US, built at different times and a wide range of values and every time a chimney sweep, plumber or electrician comes in to do some work, they always point out something that was done very poorly. It has nothing to do with the task at hand and there's no way myself or anyone else would ever want them to rebuild it. It works. There's more good than bad.

Be careful in your judgement. As you grow as a programmer, you will be appalled at the code you previously wrote. I'm not defending it, but we rarely hear anyone take a new job and hold the existing code base in high-regard. I imagine the former developer went to another company and cursed their existing code as well.

There are two things you can look into to see what kind of a situation you're getting into (bad code may be the least of your problems and is probably a sympton of something worse)

The Interview Process If they don't make sure you can write code, there's no reason the previous hires did either. They're probably not paying attention to the production code either.

The Development Process Ask what you and everyone else are required to do. Testing, code review, automated builds, requirements gathering, planning, documentation, bug tracking can have big impacts on code quality in a project of significant size. Ask how they handle emergencies. As anyone had to work over-time to finish a project? Is scope-creep a problem (Of course it is, but do you admit it and have evidence you've avoided/limited it?).

Personal Taste It may not be so much a matter of bad code, but things just aren't done the way you prefer. I like working directly with users/owners instead of having everything go through a manager. I'd rather have to cleanup and work with a bad code base than an uncomfortable environment. To me this is the best chance there is to getting things right eventhough it may take a little longer.

share|improve this answer

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