How appropriate is the interview question: "Show me a piece of code you like"?

Question

I recently interviewed a candidate at our company and asked him

Show me a piece of code you like, yours or something you snatched from the internet

The candidate was not really able to properly answer that, just fumbled around aimlessly and unsure of what to make of this kind of response I took it to my google+ stream where most people are in the same profession. The comments were mostly negative about the question itself along the lines of:

"I'd up and leave if asked that!"

"How is that relevant?"

"This is just stupid!"

"Leave it, he isn't supposed to be obsessed with his code"

"If someone "likes" his code, he should go see the doctor"

I wonder - is it really that bad? I thought being enthusiastic/proud of your code/job is supposed to be a good thing, right?

The question was really supposed to test what the candidate likes and is enthusiastic about. There really was no correct answer, just that he wants to talk about something he found interesting recently, which means he IS interested in what he is doing.

Answer 1

Short answer: It's not really an appropriate question for an interview situation.

I've been a programmer for 20 years and I couldn't answer this off the cuff in an interview. I would find it one of those "WTF?" type questions that doesn't make any sense to ask. It seems to me to be more of one of those over-a-coffee-in-the-lunchroom type conversations you may have with a co-worker.

I'm struggling to see what value there is. What are you trying to determine with it? How will identifying a specific piece of code inherently improve your perception of the candidate? If you want this, ask the poor candidate to bring something with them to the interview, or beforehand.

I've been through many interviews as both interviewer and candidate. If you want to ask them what they like or find interesting, ask them that. You might find you will gain more insight than an ambush-type question :)

Answer 2

I've been a professional programmer for almost 25 years, and been on both sides of the table in interviews, but I don't think I would have a good answer for this question.

I also detect some age bias in the question. Today, web apps are king, but I worked mostly on desktop apps in my career. I don't know what you are interviewing for, but I can tell you that almost none of the code I have written in 25 years is available to show you. All the public web apps I've worked on are protected by authorization. All the rest are internal projects. Young programmers were born into a world where the Internet always existed and there is plenty of open source. But there are a lot of programmers like me who have been around a while who didn't work on projects like that. I would love to show you some really cool stuff I did at my first job in 1991. I got to invent stuff and was present at the creation of some really important things. It set me up for a fine career, but I can't show you any of that. I'm sure that code exists somewhere, but nowhere I can get to.

This is the kind of question that would sour me pretty quickly on the interview. It's a no win question for me. I can't show you anything of mine. I can only throw out something random that I think is cool, like Angular or moment.js. But now what? I didn't work on any of it, so I can't really talk about "the code." It's a question that would kind of suck the air out of the room.

Answer 3

It depends on why you're asking the question and how.

In the right context, it could be a great question.

Did you ask them that on the spot? That's really hard and tests how well a user can recall situations in which they had a particular emotional response, which is really not a key skill. Interviews test for this too much already (avoid asking more than one "think of a time when you did X" question). Plus, they might not be able be able to access (and redact) their best work in the middle of the interview.

What do you do with the answer? It will sound to the candidate like you are asking to judge them on their choice and the quality of the code in their choice. That's daunting, and would probably be a bit unfair, as it may be rather subjective. I'm hoping that you're asking this so you can use this as a springboard for them to show enthusiasm about something, for you to ask probing questions to test they understand the ingenuity or the limitations on terms that they're comfortable with. But that's not clear to the candidate and part of your job as interviewer is make them feel at ease so you're judging their natural ability, not their ability to do job interviews.

I thought being enthusiastic/proud of your code/job is supposed to be a good thing, right?

Yes, it is. However, you cannot expect people to show this on demand (unless you are hiring actors). Some people tend to bridle when you ask them to to show emotion, and this has nothing to do with whether they are in fact proud of their work or enthusiastic about code. What you can do is set up situations in which that will come naturally, and even then, be wary of assuming that someone is not enthusiastic/proud merely because you cannot tell. It's a bonus and often a positive sign of dedication if you do see it, but you can't infer a great deal from its apparent absence in an interview context.

If I were asking this, I would hope to be be more up-front about my intentions. When inviting them to interview, I would ask:

Bring two short pieces of code that you have seen or written that you found interesting, elegant, or challenging and would be be willing to to talk someone through. This will help us get an idea of how comfortable you are understanding new ideas or complex problems and explaining them to others.

I would probably also indicate that there's no expectation that the code will need to be executed live.

Answer 4

I am never enthusiastic about my code - I am just happy if the code is useful. I am pleased that some of my Python coding is as well done as the best coding that's done in say www.codewars.com but it's a kind of feeling that lasts about 20 seconds before I move on to other things - I've got a lot to do.

You feel enthusiastic/proud of your code/job? Your enthusiasm/pride doesn't mean a thing to me. All I care about is that I know what you're doing, that you've got the right reflexes and that you think straight when the poop hits the fan. Enthusiasm/pride is something I felt when I was a teenager but my teenage years are long gone. What matters to me now is that the job gets done no matter what else goes wrong.

I've cleaned up and finished after people who lost their enthusiasm often enough over their decades to view enthusiasm/pride with amusement and cynicism.

All I really care is whether the task/job is necessary. If it is necessary, I will get it done no matter how I feel about it, and I will get a task that I hate done as effectively and as efficiently as if I loved every minute of it.

As feelings go, my enthusiasm and pride ebb and flow and they are not a reliable barometer of anything except the here and now. I used to do scientific/engineering programming. I was enthusiastic about web programming until I learned it and decided web programming is mindless. I used to say that javascript is the worst language I ever loved until I got pretty good at javascript and then I decided that I just hate javascript. I used to be fascinated with algorithm design until I assessed that machine learning solves a much larger class of real world problems than the class of problems for which a specific algorithm can be found. And as a result of recently participating in several hardware hackathons, I am very much taken with IoT - the Internet of Things.

If you were interviewing me, your question would be lost on me. I just don't operate the way you do. I am not wired to operate the way you and I DON'T want to be wired to operate the way you do. Getting the critical stuff right is what matters to me and what keeps me up at night. The rest of it is really of no consequence to me.

Answer 5

I've never been on the hiring side of the table in an interview, and I do think this is a good question, as long as it's relevant for the position. Emphasizing some parts of the original question:

Show me a piece of code you like, yours or something snatched from the internet

• If it's not obvious from other trusted context (such as recommendation letters with a description of the work done), you should be able to gauge whether they are technically proficient at all:
  • Do they hunt and peck? I think I have to agree with Jeff Atwood.
  • Do they know the basics of a browser, even somebody else's? You don't have to double click anything, there's a URL bar near the top, you don't google a URL, and if you know the name of something but don't know the web site you can find it. This is IMO an extremely basic foundation, and I would expect a professional developer (even a newbie) to know this and more.
• Asking for a subjective opinion on code can be used to gauge at what level they understand the code. Can they walk you through what it does, at any level (bits, algorithms, control flow, architecture, anything)?
• Asking for their code, even if they don't develop as a hobby, can judge whether they take an active interest in fixing issues in the software they are using at work (and can understand other people's code sufficiently to fix it). These days everybody is using open source in at least some places, and all software has bugs. And surely no developer works for a long time without ever looking at code online? Even if it's just examples in an API reference.
• On a side note, "snatched" has negative connotations related to thieving, and should be replaced by something more neutral ("found") or even positive ("discovered").

That said, I would add another escape clause: They could instead show a piece of code and tell you why they don't like it, or you could show them a piece of code and ask them what they think of it. This is a bit tricky, since you want them to be honest without fear of reprisal. If you think the code is good and they can't stop with the four-letter words, they might be a good programmer or they might just be opinionated (or both), but at least you should be able to tell whether they understand anything of what they're reading.

Answer 6

Assuming this candidate was interviewing for a software developer position, then the question is relevant, otherwise not.

However the question does have a couple of problems:

• I would not expect anybody to come up with a good answer on the spot. As a developer you sometimes come across a piece of code which you like, and that can be either some of your own or something that somebody else wrote. But it is very rare to see code so likable that you remember it a few weeks later.
• The candidate may not even be allowed to show you that piece of code due to confidentiality or copyright.

Assuming you ask the candidate this question as preparation for an interview and they have a few days to come up with an answer, then they might come up with something.

Chances are they will come back with whatever code they happened to look at during those days, which best fit the criteria. They might very well be in a position that most of the code they work with is confidential, and the only code they could show you is any open source code which happen to be part of the platform they are working with.

There is nothing wrong with that per se, but they might not look at enough different pieces of such code during that time to have some really nice samples to choose from. The real problem with picking a piece of code that way is, that the reason the developer took a look at the actual code of the platform likely was that they had a problem with it. That means the selection will be biased towards poor quality code.

Overall I think the answer to the question is not going to tell you a lot. Even if they managed to come up with a likable piece of open source code, then it still won't tell you much because they might as well have had somebody help them answer the question.

Where you might get useful information from the candidate is from follow up questions. Of course the candidate will expect you to ask what they like about this particular piece of code and have a prepared answer for that. So unless you can challenge their idea on why this is a particular likable piece of code, then you have learned nothing.

The responses you mention in your question are however too negative. Here is why I think so.

I'd up and leave if asked that!

Anybody overreacting like that to a single question they don't like is not the kind of employee you want anyway.

How is that relevant?

If a programmer can't tell a good piece of code from a bad piece of code, then he isn't very competent. I expect all good developers to feel pleased when reading a well written piece of code.

This is just stupid!

No, the question is not stupid. But problematic because it cannot be answered on the spot, and you won't learn a lot from a prepared answer.

Leave it, he isn't supposed to be obsessed with his code

Would you hire an employee for his experience, if he has never done a piece of work which he is proud of?

If someone "likes" his code, he should go see the doctor

If a developer has never written a piece of code which he would feel pleased to read at a later time, it can mean one of two things.

• He is not very good at writing code.
• He has been unfortunate enough to only work on projects where corners had to be cut on every piece of code he wrote.

Either way I pity those developers who haven't written one piece of code which they like.

Similar questions which can work well

You choose a piece of code and let the candidate comment on it. Maybe even give them two pieces of code and ask them which they like better (the catch being that one piece is stylish but buggy and the other is not very well formatted but happens to work correctly).

Ask them about code they have developed and are proud of, but don't ask them to show the code instead talk about the design.

Answer 7

Something different of an answer:

The question could be fine, if the wording better addressed the values that sound implicit in it.

Show me a piece of code [1] you like [2], yours [3] or something you snatched from the internet [4]

1. You want to understand that they do more than just write-and-forget. You want to be sure that they reflect and contemplate code.
2. You want to hear them demonstrate an understanding of 'good code.' Good is subjective, so this is an open-ended possibility for them to impress you with the way they think, and the depth of their thinking.
3. You hope they have an example of their own code that meets these criteria. You hope it's online because that shows connectivity with FOSS community practices.
4. You want to see that, in the absence of #3, that that seek out others' code that demonstrates good practices, and that they remember the last bit of such code they looked at.

Whew. None of that explicit in the question. Lots of people need Explicit.

Try:

I'd like to understand what you think is a great piece of code. I don't mind how you define 'great,' I just want to see how you think. If we can navigate to the code online right now then that's good, but if not then just tell me about it or diagram it here. It can be a piece of code you wrote, or something that expanded your mind recently.

Answer 8

It's a great discussion question for friends or colleagues with mutual interests and experience, but a terrible interview question. Ultimately, asking this question will fail to generate information useful for making a hiring decision.

It's similar to "show me a piece of writing you like." If a question this broad is posed in a no-pressure circumstance, like chatting with a new acquaintance, you could go in so many directions: the funny children's book you read last night with your daughter, the magazine article about the Greek debt crisis, the easy YA book you took to the beach, or your favorite work of classical literature. No matter which way you go, you can have a nice discussion with a someone--but if you talk about children's books, your new friend isn't going to learn anything about your ability to grapple with the themes of Moby Dick.

Presupposing that a candidate can show you the code and remain relatively nonplussed (see footnote, the stress imposed alone should make the question non-productive), your conversation could touch on one or more of the following (but not all!):

• Formatting standards
• Language selection
• Fluent syntax
• Simplicity
• Clean code
• Performance
• Interfaces
• Patterns
• Comments
• Source code availability
• Licensing
• Off-the-shelf solutions
• Third-party libraries
• Abstraction
• Testability
• Trade-offs

If the candidate spends 20 minutes talking about comments and licensing, but you're interested in design patterns, what does that tell you about the candidate's knowledge or opinion of design patterns? Nothing.

I think you're asking this question because you care about something technical. I suggest you figure out what it is and ask them specific questions. Otherwise you'll rank mediocre candidates who made a lucky guess about your pet preferences above highly qualified candidates who can't read your mind.

If you're asking because you want to see if you enjoy talking with them about code, you'll rank otherwise mediocre candidates who are sociable above highly qualified candidates who don't have the gift of gab. Or worse, you'll bias toward people who think and talk like you, and your company could end up mired in group-think.

If you don't care about anything technical in particular, nor are you rating their conversational ability, it seems like a waste of time.

If you know it's a terrible question and you're asking to see how they react to stressful situations, you risk alienating qualified candidates who don't want to play head-games and end up with mediocre candidates who will willingly jump through your hoops.

`* In order to be remotely effective, the candidate must recall examples of "code they like," select one that is publicly accessible, access a computer, navigate to the code, and figure out a way to display the code (maybe a browser is okay, maybe it's not). All in less than X minutes, where X is a number around 2. Can you imagine the building stress of 5 minutes of dead-time because you're searching around for a code sample that exhibits some ill-defined "likableness" knowing that your potential employer is judging you based on both speed of selection and content of whatever you find? An employer is probably inadvertently biasing toward candidates with good showmanship, shallow experiences, or experience in non-proprietary software.

Answer 9

As a software developer I have a major issue with the question: I try to make all code seem as simple and unremarkable as possible.

I like clean, simple, very easy to understand code, especially if I know that it was convoluted before I made it simpler. It doesn't always work out that way, but if it does, that's the code I like. The day you go home with a grin on your face because you just deleted 1000 lines and made the code faster and ready for the new feature.

But during an interview, you wouldn't be impressed with the end result, would you? You'd just see something trivially simple.

In an interview situation, I would feel pressure to try to think of some exotic technique we had to use once for some insane requirement, so I could show off and explain all sorts of things about it. But those don't happen that often and I don't like them that much.

There are also bits of code that I like a lot because they're like puzzles that take a while before you understand their dirty trick (Duff's device), but that's not the kind of thing I would write in the typical software I work on. I have no idea how you react if I answered with something like that, even if it's a fair answer to the question.

If you want to talk about code with the programmer, maybe it would be good to go to some random obscure library on Github and start reviewing the code together.

Answer 10

The thing about interview questions is people like them if they personally have a good answer, and hate them if they don't. I suspect in this case, most people didn't have a good answer off the top of their head, and so reflexively disliked the question. It took me 5 minutes with a web browser to find an answer I liked that I wrote myself, but I did find one.

Then I wondered, "What if I didn't happen to have been working on a personal project recently?" So I spent a minute finding an example I liked from an old project I have up on bitbucket.

Then I wondered, "What if I had never worked on any projects with code that's publicly accessible?" So I spent a minute finding an example from Clean Code, which I have for Kindle.

Then I wondered, "What if I had never read any books with coding examples on Kindle?" So I spent a minute picking a random file from a random open source project, and found some examples of functions I liked and disliked in there.

Then I wondered, "What if none of those ideas had occurred to me during an interview?" So I spent a minute pondering how I might explain that even though no ideas occurred to me in the moment, what attributes I consider when thinking about code I like, and what attributes cause me to dislike code.

Then I wondered, "What if I were interviewing someone who had no idea what kind of code they liked or disliked?" I concluded I probably wouldn't enjoy working with that person. Programmers without opinions on code they read probably aren't too picky about the code they write.

I encourage anyone who thinks this is a bad question to actually go through the exercise of trying to answer it. It doesn't have to be your most favoritest code in the whole world. I was surprised at how little effort it took to find reasonable examples.

Answer 11

It is a very bad question to ask at an interview without telling the candidate ahead of time you are going to ask it.

However it would be a great question to ask at an interview if you ask the candidate to bring with them a printout of some code that they like, saying you would expect them to discuss it at the interview. The candidate should be given at least a few days warning of this.

A variation on this, is to ask a recent comp sci student to bring a printout of their 3rd year project code, then pick a few pages at random and ask them what the code does and why they wrote it in that way.

You are looking to see if the candidate can reason about the code, and show that they considered other options, and can accept that there is more than one correct way to solve a problem.

Follower up questions can be like.

• Why did you not set the local variable p to null at the end of the method? (Do they understand garbage collection etc.)
• What would have happened if you forgotten the “+1” in the call to malloc? (Do they understand how to debug memory issues.)
• How can this code be tested.

Answer 12

I think it's a great question to see if they are passionate about what they do or not.

I would answer - using encryption to create a storage less shuffle. It's a way to generate a random number that is guaranteed not to have been generated before, without actually having to check what numbers have been generated. It's how credit card numbers are generated by the issuing companies apparently and is called format preserving encryption.

I'm passionate about what I do, I enjoy what I do, and these facts have gotten me to a great place in my career where I'm near the top of my field :p

The code on my blog: http://blog.demofox.org/2013/07/06/fast-lightweight-random-shuffle-functionality-fixed/

Answer 13

Most of the answers here say no, but I think, if your hiring a "programmer" this is an awesome question.

First, it's not really meant to be answered, but how the person forms their response could really tell you a lot about how they are going to handle being "the guy" that solves all the problems. As a lead programmer your often asked questions that your honestly can't possibly answer, but you still have to come up with something.

Example: Screw you I'm leaving, I'm not answering that. -- Not someone you want to hire.

Example: I don't know. I don't really know any code I like. -- Not someone you really want talking to clients.

Example: I don't really have any code to show, but I would really like to see how this thing works. -- Good answer. Shows thinking on ones feet.

Example: I was always fascinated by the bit of code that does this thingy here. -- Good answer shows genuine interest in a field.

Second, If they provide code that is copyrighted or some such, you know that this person doesn't have a grasp of the laws and practices that are common in the industry. If they can't provide code, or say something like, "I had this one project I worked on where we did foo using bar. Un-fortunately I can't really share the code." or even "There have been some that I really liked, but they are covered under NDAs, basically it had to do with string minupliation and regex." That means they at least have a general respect for following "the rules".

Finally, I like to put people I interview off balance a bit. Not Earth shattering, but a little bit. If I only ask the expected questions, how am I to judge this person. Specially when they me be constantly on the spot.

I think it's a great question. Not all questions need to have an answer. I don't know is ok, but it's how the person says I don't know that's important.

Answer 14

I find the question completely relevant, refer to Joel 11.

I would refer to recent code from my portfolio or some (obviously better written) open-source code I have been reading recently.

Failing that? Then I don't like coding, I like money. Do you want to hire me?

Answer 15

I don't think it is such a horrible question, but you could find a better use of your time. Some people may look concerned because they're scrambling their brains trying to figure-out how they're going to get access to it if they don't have public code projects.

Lead up to the question Show some good and bad coding examples. Give some context to what you're looking for. Do you have strict coding standards? Good programmers have standards, but not when they go to far and get in the way. Some are more tolerant of lock-step processes than others.

Write code during the interview The problem with questions like these "Hey, let's talk about coding." take time away from actual coding. Isn't that what the job is about. Are you hiring people to write code or just talk about it? Coding Trivial Pursuit or I know something you don't know are examples of time-wasting games.

Let's not get extreme here. Of course teams need members to communicate. Software creation is a team sport, but like most team sports, there are positions to play and sometimes an individual has to take on individual responsibilities. The person you want performing the kick is not the player who is most chatty in the huddle, but the best kicker.

Answer 16

There is often no way to know if a question is good or not. However, there can be many ways to decide if an answer is any good. Specifically as worded, I'm bothered by the question even though I'd work at providing an answer. It's unlikely I could "show you" such code; yet I could probably describe and discuss such. It's not so much an issue of 'copyright' or similar. Rather it'd be a matter of accessibility.

Some 25 years ago, I was on an interview panel. We were a group of developers interviewing potential managers. A question on my list was "Please describe your personal choices of SDM and PMM."

The first candidate had no clue what the question was about. To tell the truth, that was the first thing I wanted to know, whether a candidate had familiarity with the acronyms or not. The next candidate generally recognized the acronyms, but gave a pretty BS answer.

Before the third candidate's appointment, two of the other three panel members jointly confronted me to say they thought I should drop that question. I replied that even though I'd like a truly good answer, the actual goal was seeing how the candidate formulated and presented an answer.

The very next candidate not only understood without any questions like "What are SDM/PMM?" from her; she clearly gave her philosophies in both areas. She also went on to point out flexible elements she could adapt to the structure of our department and our application needs. She became the unanimous recommendation of our panel out of five candidates and was an excellent manager for us in the subsequent years.

The two members who confronted me, along with the final member who also had reservations but kept quiet until after, all said that it was the question and answer that convinced them. It's easily possible that a particular question can be viewed negatively by a majority. It's not so easy to be objective about it and be convincingly certain. I've been interviewed four times in 40+ years, and there was always at least one question that I wished wouldn't have been asked (though I thought they all had value).

TL;DR: I'd find a wording that didn't initially expect "Show me" as part of the answer, preferring maybe "Describe" or "Discuss". I might follow up with a kind of "Show me" if it seemed appropriate after the initial response.

Answer 17

Looking at your question, I can see the purpose. It's not worded in the most useful manner to get you a useful answer.

Show me a piece of code you like, yours or something you snatched from the internet

Show me suggests they have to a) have the equipment to hand, b) have the legal right to show you, and c) can actually find it easily. If the code was written to be obfuscated then there's also the chance they could show you something you can't read, and if it's completely obfuscated they could be showing you gibberish.

snatched from the internet implies they've stolen the code. That may or may not be true, but they still wouldn't want to be accused of plagiarism. They could be feeling defensive after that ("He's accusing me of stealing?!") and give a worse interview after that question.

Taking both into account, a better phrasing might be

Tell me about a problem you've encountered on a project and a solution you coded that you're proud of

That gives them the chance to demonstrate problem solving, talk you through the learning journey they went on, and also talk you through the principles for a piece of code even if they can't legally show you the finished code.

Answer 18

Both the question and most posted answers start from the perspective that the answer to the question is the goal of the question, and that having a fitting answer to the question is tallied as a pass/fail result; but that is not always the case in an interview.

Some questions are asked because the answer indirectly reveals other information, such as the applicant's character or whether they'd culturally fit in with the current staff.

Similarly, unanswerable questions or curveball questions can be asked, not with the intention of causing the application to fail at answering, but to gauge how they deal with unknowns.

Let's explore possible answers to this question and how this can be meaningful to an interviewer. I'm going to use clear cut examples because the focus of this answer isn't on how to read between subtle lines.

"Ehm [looks around nervously] erhm.... erhm... [closes eyes and muttering to self] erhm... [muttering] Oh God come on Tony pull yourself together."

This person seems to be rather nervous. This information can be used in different ways:

• It can be a mitigating factor if the application blanked on earlier questions
• This applicant may not be suited for high pressure environments

"I'm not quite sure how to answer this. Do you have an example of what you mean?"

This applicant deals with unknowns in a constructive and eloquent manner.

"How the f#%* am I supposed to answer that!?"

That is someone with a combative character and/or anger management issues, and a penchant for swearing. That's probably not the kind of person you'd want to hire.

Shows an example on how to get around profanity filters on PG-rated forums

It's not a wrong answer to the question, but it does show a certain lack of awareness of their current surroundings and judgment on how appropriate that example is.

Shows an example of [new technology]

This suggests an interest in new technologies, specifically the one they picked. Given it's the first thing that came to mind, this is probably the technology they are most interested in.

Shows an example of a solution found on a blog post

This suggests that the applicant keeps themselves up to date on what happens in the development sector.

Shows an example of something outdated

This suggests that the applicant's skills may not be up to date either, unless they specifically address that it's a historically interesting example and not current.

---

Answer 19

I think it is a reasonable question. If you were hiring someone to paint your portrait and asked them what works by other artists they like, would they not have an answer for you?

Personally, I would have immediately answered that the code by PieGuy in Google's Code Jam I find to be amazing. He competes every year and generally finishes very well. His solutions are always incredibly terse and efficient, really eye openers, almost like reading magic. Also, I kind of like Stallman's code. You have to respect somebody that has written 1+ million lines of code and still has time to make every variable name a short sentence. It is really easy to understand Stallman's code because his variable names are so well crafted.

The drawback to a question like this is that it will annoy the 9-to-5 type programmers who just consider programming "work" or a "job" and have zero interest in programming as an art. But, then again, it does not seem like you want to hire such a person anyway. From that standpoint, the question is a good discriminator.