Asking a job seeker to show some code is a fairly common practice for a software company. However, would it be acceptable for the candidate to ask the interviewer to show him a small piece of code that he thinks is well written?

Answer: Always ask (43 votes)

I want to know what I'm getting into. Of course no software firm is perfect, and I don't expect everyone to pump out marvels of elegance all the time (because neither do I), but if I ask for a company's very best code, and all they can show me is a sub-par spaghetti mess, I know I'm in for a miserable time, unwrapping hairballs and fighting the technical debt to get anything done. Looking at the best code a company can show establishes an upper limit of what kind of quality is possible there; even if it's unlikely that all their code looks like that, you still know it is something they strive for.

Looking at code samples tells me a lot about a company's coding culture. Do they use documentation comments? Do they lean towards an Object-Oriented style, do they have Functional Programming tendencies? Are they conservative or progressive? Do they value consistent naming, proper formatting and indentation, and neat code in general? Is the code easy to follow? How do they structure their projects? How do they approach the important things—automated testing, error handling, etc.? How defensive is their coding style?

Seeing their existing code will allow you to judge whether you can live up to their standards.

The fact that a company is willing to share code samples alone is a good sign in principle. It means that they offer me, the applicant, some trust, since their codebase is one of their most valuable assets. It also means that they are not ashamed of their code, that they are confident that showing me the code will help interest me in working with them.

If they won't show you any code samples, then that doesn't have to be a red flag, but it is wise to both ask why they won't share (quite likely, they simply can't for legal reasons), as well as explain why you want to see some. I don't think showing interest in their code is going to be seen as a negative sign, as long as you ask politely and positively.

Companies that do agree to show you code are unlikely to just send a tarball of source files containing the latest version of their entire codebase, for obvious reason. If they show you any code, they will do so in the form of a little demonstration, which is great: it means I get to talk to one of my potential peers; it allows me to ask more questions about their coding culture, processes, and codebase; and ideally, it will help start a professional discussion in which I can both demonstrate skills and knowledge and learn more about the work environment. It also means that I get to look at the tools they use, which is also quite insightful—for example, if the project they show me relies heavily on a particular IDE, this means that everyone uses that, which can be good or bad. And finally, talking through a bit of code gives a good impression how well future professional communication might go.

Answer: It Depends (3 Votes)

I see a job interview as bidirectional. The company finds out about you and you find out about the company. Asking for code may be a little bit much, but asking development related questions should be OK.

For example, I would not accept a job where the company doesn't use agile techniques or TDD or doesn't plan to embrace and encourage such practices. I also appreciate when a company is proud of their product and their code—when it seems the interviewer is waiting for you to ask to see it so he has an excuse to explain all the cool stuff they do.

Think you know if it's OK to ask for code samples during an interview? Disagree with the opinions expressed above? Bring your expertise to the question at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, patents, and (almost) everything in between.

I would just look at the products that have been shipped recently, and if they're good products and the pay is adequate then I'll take the job. If they have never shipped anything, then I won't work there at all. Been there, got burned, never do it again.

Basically, by the time I go to a job interview I have already decided I want the job. All my questions can wait until after they've hired me. If I realise I made a mistake, then I'll quit. Easy.

Presumably the job interview is with your future manager or boss. So you should assume they they know more about code style/etc than you and don't say anything to imply you know better than them. Even if you think they're wrong, keep your mouth shut until you've worked there for a while and proven yourself.

I've seen a lot of new (and occasionally old/experienced) coders turn up, tell everyone they're doing it wrong, and try to force some different coding style or toolset. Sometimes they get fired, other times we try their stuff out and it turns out to be a disaster. Don't be that guy.

Our best hires, who did have something to offer, spent a year or two working within our existing system before starting to suggest improvements. They waited until *they understood the problem* before suggesting a solution. Everything we do is being done for a reason, even bad choices have at least some good points.

I've seen a lot of new (and occasionally old/experienced) coders turn up, tell everyone they're doing it wrong, and try to force some different coding style or toolset. Sometimes they get fired, other times we try their stuff out and it turns out to be a disaster. Don't be that guy.

On the other hand, people who get along all the time, often don't warn you when you're about to make a serious mistake. There's such a thing as too accommodating; you don't need another yes-man.

I work as a consultant and I seen more coding styles than you can imagine. And everyone always complains about something in them. If you don't, I wonder if you would speak up when you think we are making a big mistake.

I think shawnhcorey's list is a better one than asking for a code sample.

I've interviewed many programmers who thought they were doing me a favor by agreeing to even be interviewed, let alone work for the company. They were, of course, nowhere near the best candidates.

Coming off as having an attitude that you might be too good to work for a company isn't a good sign, and even with the best of intentions, asking to review *their* code is going to smell like you have a chip on your shoulder.

On the other hand, people who get along all the time, often don't warn you when you're about to make a serious mistake. There's such a thing as too accommodating; you don't need another yes-man.

True.

shawnhcorey wrote:

I work as a consultant and I seen more coding styles than you can imagine. And everyone always complains about something in them. If you don't, I wonder if you would speak up when you think we are making a big mistake.

I complain all the time, and always start a discussion if I think something doesn't look right.

But when it comes to suggesting improvements, I'm a lot more cautious and I've been working at my current programming job for over 6 years now. As a brand new employee, I would never assume that I understand something enough to say it's bad (unless it's really obvious, bugs all over the place etc).

I'm not saying you should just blindly do whatever everyone else has always been doing, I'm saying you should not assume that you know a better way to do it — especially in a job interview where you have only had 30 seconds to see the "bad" code.

I'd be very impressed if a candidate wanted to see a bit of our code, especially if he/she has provided some and it's good. It would be hard to show them proprietary code, though.

However, I'm happy to share details about our environment, and I expect that they ask about it, if they actually care. A good candidate wouldn't take a job somewhere where they use like, StarTeam or where there is no version control whatsoever.

As a regular interviewer at my company, I'd be quite shocked if someone asked to see our code. I'd also tell them there's no way we'd let someone see our code if they weren't actually working for us. I work for a large well-recognized software developer though, so perhaps that makes it different. I could see people doing this at small firms where little is known about the company. But if you interview at a large firm, honestly, I think you're doing yourself a disservice by asking. Just my opinion of course, but I've done ~150 interviews for my company and I'm really not sure someone asking to see our code would sit well with me. The answer is so obviously 'no' that I'd really have to wonder why someone would ask.

I don't lie in interviews, I don't expect the interviewer to either, sometimes you need proof.

The real problem is that some interviewers think they company works like it says on paper. That's why you want someone who works "in the trenches" present when the work environment is described. If he cringes, reality does not agree with facts.

Go ahead and ask but don't expect to see it and do expect the request to count as two strikes against you. I always ask the candidate to write something simple like a bubble sort just catch those who can't even code and to see if they bother to check for errors. But to ask to see the company's assets during an interview is a bit presumptions.

The questions shawn listed are what I ask and what I would expect to answer. Asking for code is asking for a walk to the door.

If you ask them for a code sample they'll either joke about how all code is terrible, or they'll show you some really fluffy code that solves a problem we've all solved twelve times (so of course it's pretty code).

First assumption - if this job interview is for a coding position, then definitely ask the technical interviewer to see some code. Heck, I'd ask to see the overall architecture for the systems that the company makes too. Asking the HR drone won't get you very far, they've probably never seen any code outside the trash bin.

The last time I interviewed for a coding position, they didn't ask to see any code, which is good since I don't own any code that I've written. I've worked in states that do not prohibit 100% ownership of anything techincal the worker does regardless of location. It isn't my code to share. Not everyone can show their code, unless it is college level crap .... or something trivial that I hacked together over a weekend of ZERO commercial value. My "string class" is beautiful and based off my smartptr class.

Now that I do hiring, I look for smart people first and someone hungry to exchange ideas, arguements, and styles. I want out development team made up from all levels of software development. Sr, mid and Jr devs, all bringing different viewpoints to the project. I have a preference for someone that did 100% maintenance programming for a few years.

If the position is not about coding, then I wouldn't ask. If you have skills writing code, almost any position can become a coding job provided it helps efficiency.

As a regular interviewer at my company, I'd be quite shocked if someone asked to see our code. I'd also tell them there's no way we'd let someone see our code if they weren't actually working for us. I work for a large well-recognized software developer though, so perhaps that makes it different. I could see people doing this at small firms where little is known about the company. But if you interview at a large firm, honestly, I think you're doing yourself a disservice by asking. Just my opinion of course, but I've done ~150 interviews for my company and I'm really not sure someone asking to see our code would sit well with me. The answer is so obviously 'no' that I'd really have to wonder why someone would ask.

Why? Why would you be able to ask for a code sample, but not the candidate? Remember, they're interviewing you just as much as you're interviewing them, if not more so.

Go ahead and ask but don't expect to see it and do expect the request to count as two strikes against you. I always ask the candidate to write something simple like a bubble sort just catch those who can't even code and to see if they bother to check for errors. But to ask to see the company's assets during an interview is a bit presumptions.

The questions shawn listed are what I ask and what I would expect to answer. Asking for code is asking for a walk to the door.

Why is it presumptuous? And would it not be equally presumptuous of you to ask to see their code?

Why? Why would you be able to ask for a code sample, but not the candidate? Remember, they're interviewing you just as much as you're interviewing them, if not more so.

s73v3r wrote:

Why is it presumptuous? And would it not be equally presumptuous of you to ask to see their code?

Because most companys are run by super-egotistical narcissists who think it's a privilege to be in their present, yet alone, to actually work for them. It's not a two-way street simply because they're so much better than you.

As a regular interviewer at my company, I'd be quite shocked if someone asked to see our code. I'd also tell them there's no way we'd let someone see our code if they weren't actually working for us. I work for a large well-recognized software developer though, so perhaps that makes it different. I could see people doing this at small firms where little is known about the company. But if you interview at a large firm, honestly, I think you're doing yourself a disservice by asking. Just my opinion of course, but I've done ~150 interviews for my company and I'm really not sure someone asking to see our code would sit well with me. The answer is so obviously 'no' that I'd really have to wonder why someone would ask.

Large, recognized companies often have crap codebases and a developer would be walking into living hell.

While I understand that it's not always possible to show proprietary code to a candidate, I think the interviewer has to try to answer as many technical questions as possible. As a developer, I wouldn't want to walk into a horrible environment with crap code and horrible, outdated development practices. Or if I was going to, I'd like to know ahead of time, so that I could ask for enough money.

Also, I see a candidate that doesn't care or doesn't have any questions as a bad sign.

Showing of proprietary code is simple and easy; ask the candidate to sign an NDA. There are other times when code is shared/shown/etc. with orgs and people outside the org that owns the code, and that is what is done - it rarely causes problems. Most codebases I have seen have little in the way of something that a person would want to steal - if anything - indeed, in most orgs it is a running joke that the worst thing they could do to a competitor would be to let them steal their codebase (I've worked a number of places where that was not a joke, it was a fact).

As for asking questions - sorry, the answers are usually lies or at the very least incorrect. I've worked a number of places where the reality was just the opposite of what was presented to me in the interview, despite some very relevant and explicit questions. Sometimes the interviewer just doesn't know what they are talking about (e.g., an interviewer who doesn't know what unit testing is) or they think they are only slightly embellishing their answer, or they have no idea that their level of quality is so far below that of the rest of the world that it is laughable.

A codebase is a very good way to judge what kind of mess you are likely to get into - and it is a lot more objective than the answers of a human as to the quality of their code. This is especially true when you remember the fact that most incompetent people wholly do not realize that they are incompetent, much less how incompetent they are. The more competent developers would likely downplay the quality of their codebase while the incompetent ones will think what they write is golden - in fact, if they think it is so golden that you might want to steal it, then run, don't walk away.