8

Possible Duplicate:
Asking for a code sample of the company at an interview

Last year I changed jobs twice.. In the interviews with the companies, everything was so ideal and perfect. Latest frameworks, design patterns, distributed systems, scalable and enterprise systems, etc.. But in both cases something was not as expected..

First day after joining the company, you open the solution and find legacy code in a 10 year old technology, tightly coupled layers, design patterns incorrectly applied..

So, my questions are.. Has this ever happened to you? Is that often? The interviewer makes sure I'm the proper developer for the company, how can I make sure this project/company is the proper one for me? Can I ask them to show me the code???

Improve this question
5
  • 7
    This is perfectly normal and common occurrence.
    – Euphoric
    Jan 10, 2013 at 14:13
  • 1
    I feel like I've answered this question before, either here or on theWorkplace, but cannot find it. That happens all the time, and you can ask for code but I doubt you'll get it in most locales (usually due to legal concerns).
    – Telastyn
    Jan 10, 2013 at 14:14
  • I don't see what that's objectionable - it's not like they have to give him a copy - he's not going to memorize it if he takes a quick look at it.
    – Mansfield
    Jan 10, 2013 at 14:19
  • 2
    You can always ask. Be polite and explain why. They shouldn't consider it a ding against your skills, personality, whatever. And worse they can say is "no, it's sensitive".
    – Jesse C. Slicer
    Jan 10, 2013 at 14:24
  • One strong candidate once asked to see our DB schema. We did not have any problem with that.
    – Den
    Jan 10, 2013 at 14:35

2 Answers 2

Reset to default
12

Absolutely.

In my opinion, any candidate requesting an overview of the code base goes up a notch in my review. Regrettably, few ask.

Part of the challenge with this request is that they may not have scheduled time for it during the initial interviews. You may have to come back at a later point in time, or they may be able to extend out the length of the interview session to give you an overview.

I would start by asking about general architecture questions.

  • What technologies are the using?
  • What amount of time are they spending on defects vs. new development?
  • What's the trickiest part of their code base, and why?
  • How long does it generally take to make changes?

All of those questions can give you very telling answers regarding the state of the code base.

If / when they are able to provide you a walk-through, consider asking about and looking at the following.

  • How is the code organized?
  • Who owns what areas and how are problems resolved (note that the names won't be meaningful to you, but the answer can be telling.
  • Ask to see the more "interesting" parts of the code. The interviewer will likely choose from some areas they have written, and that should give you some insight into the layout and structuring.
  • Ask to see their common library and what routines they provide within their framework.

The key is to show genuine technical interest in their code base and how things are laid out. Every application has its warts and ugly code. Every application has faced time crunches and less-than-optimal code had to be put in place. Every application carries technical debt. Look to see that the fundamentals are in place, such as encapsulation between layers of the application.

Improve this answer
4
  • I just realized that an answer "we spend only a little time on defects" could mean that they produce almost flawless code because of TDD and great tools, but it could also mean that they don't care to fix bugs. On the other hand, an answer "we spend a lot of time fixing bugs" sounds like a bad news, but it could also be an opportunity to be the one to introduce the new technologies in the company (however, it still is a red flag that nobody did it before).
    – Viliam Búr
    Jan 10, 2013 at 15:15
  • 1
    @ViliamBúr TDD enables programmers to 'produce almost flawless code'?
    – user39685
    Jan 10, 2013 at 16:05
  • @ViliamBúr - sometimes, it's how the question is answered that is more important than what was actually said.
    – user53019
    Jan 10, 2013 at 16:13
  • @MattFenwick: An exaggeration, certainly. But also this is how it might appear to a manager -- if I test my own code, find my bugs and fix them, the manager does not have to know I ever made most of them. On the other hand, if I never test my code, all my bugs are found by testers (or worse, customers), and thus they get reported to my manager. Some companies do the former, some do the latter.
    – Viliam Búr
    Jan 10, 2013 at 16:23
2

You can always ask, but it is highly improbable they will show you.

You can try asking them to write a quick coding test so that you can evaluate, but I doubt that will fly either.

The closest that I have to figuring out how to detect this situation in advance is to ask about their coding standards.

  1. Ask for a copy of the their coding standard.
  2. Ask if they adhere to it.
  3. Ask what they don't like about it.

The aim of these questions is to raise any red flags and let you know the depth of what you may be getting into before you get into it. I know it does not directly answer your question, but I do hope it helps somewhat.

Improve this answer

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