59

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.

  • Comments are not for extended discussion; this conversation has been moved to chat. – jmort253 Jul 22 '15 at 10:07
  • 3
    I always use a question like this ("Show me some of your own code that you like."), but I also always contact them a few days ahead of time to tell them to bring the code with them. Then I ask them to explain what it does and why they think that it is good. This is better because 0) they have a chance to think about it and prepare for it, 1) it's their code, 2) there's no excuse for not knowing what it does or how it works. – RBarryYoung Jul 22 '15 at 16:25
  • 2
    I lack the rep to post an answer, but I think it would be much better for the interviewer to supply a few code samples. Then you could talk with the candidate about what they think is good or could be improved in the code. It would be a clear, focused discussion since you both would have the code right in front of you. And it wouldn't be putting the candidate on the spot which is never fun for anyone. – dennisdeems Jul 22 '15 at 19:23
  • 1
    I fully agree with your intent, and those hostile responses you got are uncalled for. An important change would be to ask them to bring something as you described, so advance notice is key. As one who has hired, I believe it foolish to hire an artist having never seen his/her work. Likewise with software developers. I am amazed how, even today, nearly no one asks. – donjuedo Jul 22 '15 at 20:52
  • The real question (for you) should be "What does this achieve, and how can I achieve it better?". If you want to see what the candidate considers "good code" then give them a chance to find it or throw an example together: don't just drop it on them and expect an instant response. Since you actually wanted to test "What the candidate likes and is enthusiastic about" then perhaps the question you wanted was "Tell me about a project you really enjoyed".... don't trick your candidate. It's an interview, not a test. – Jon Story Oct 26 '15 at 14:11

17 Answers 17

107

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 :)

  • 3
    it is quite possible, that I am measuring ppl comparing them to myself, which might be slightly incorrect. When asking the question I really thought that I myself will have no problem finding a few snippets I felt proud of/ interesting solutions I found on SO while trying to solve problems. Kinda thought this should be the case for everyone. – Zeks Jul 19 '15 at 11:47
  • 28
    There is nothing wrong with holding candidates to a high standard. I do this when I am looking for staff to place in my team. However, you have to think about how a person feels in an interview situation. They are nervous, they are concentrating on skills, experiences, how to answer the next question "right". Your question is really more of a conversation starter than a question one would ask in an interview situation. – Jane S Jul 19 '15 at 11:50
  • 37
    I think asking the candidate beforehand to prepare a piece of code they like would make the question more productive. The candidate explaining why he likes the code can provide information as to what kind of programmer he/she is. – Paul Hiemstra Jul 19 '15 at 17:34
  • 19
    Perhaps the more meaningful/useful question (and one I have seen used with success) would be to produce one piece of code that you (the interviewer) consider high quality, and one that you consider poor; then ask the candidate to criticise each of the two. That way you have something concrete to build from; you're not putting the candidate on the spot. It's easier to bring up things the candidate might have missed ("what do you think of the variable naming here?"), and you have a baseline expectation for what you think people should be noticing about the code. – Dan Puzey Jul 20 '15 at 9:10
  • 20
    @Jasen, "do you code for fun" is a horrible qquestion. It does nothing to weed out bad programmers (plenty of people who code for fun are bad programmers)and it excludes everyone who does not have the time to program at home due to their responsibilities such as child care. – HLGEM Jul 20 '15 at 17:27
102

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.

  • 1
    Welcome to the site Mohair; an excellent first answer. I agree that the OP shouldn't neglect the possible negative impression that a question like this can give to candidates. I'd be worried that the company was hiring people who can interview well rather than testing or probing for technical skill and knowledge. – Lilienthal Jul 19 '15 at 17:12
  • 33
    +1 - I'd go further and point out that just because there's lots of open-source, it doesn't mean the interviewee has had the time or desire to contribute to any projects. The original question biases towards the sort of people who spend a lot of their time outside work coding. – Julia Hayward Jul 20 '15 at 7:17
  • 8
    There's also, I think, an assumption of really simplistic code. Sure, I could show some code I'm proud of (if I'd brought my laptop to the interview), but a) there's about 10K lines of it; and b) it really requires some prior knowledge of the particular field to understand why I'm proud of it. Same applies to most non-trivial stuff. – jamesqf Jul 21 '15 at 1:40
  • 5
    Agree with @jamesqf, anything worth being proud of doesn't fit in 10-line snippet. – undu Jul 21 '15 at 12:50
  • 1
    @user11177 That's a false dichotomy. What about people who enjoy the craft, but who have other things going on in life? Relationships, families, other interests...? – Julia Hayward Jul 23 '15 at 21:39
40

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.

  • Yes, I agree, that asking about that beforehand so that he had time to prepare would be better. I don't have a lot of experience interviewing ppl so I didn't think of that. – Zeks Jul 19 '15 at 11:32
  • I was trying to gauge his enthusiasm about his profession and see what he likes. Prior to that he was kinda poor at answering language questions so I was trying to look for redeeming qualities. – Zeks Jul 19 '15 at 11:33
  • I didn't ask him this question straight from the start of the interview.It was only after we talked about what he did at his current job, his experience (which is more than 5 yrs), and quizzing him a little about the language we expect him to work with. – Zeks Jul 19 '15 at 11:38
  • 1
    It's really an 'opener' question - one which starts a new conversation. You should definitely be trying to ask everyone the same opener questions, prepared in advance, although your follow-ups will inevitably vary. Otherwise it's hard to compare candidates. "Why do you want this job" is a common question that might elicit enthusiasm and one to go for early on. If you've not got a feeling by near the end of the interview that the person is capable or that they're enthusiastic, I'd resist the temptation in future to make up questions on the spot. Remember, it's a learning process for you, too! – user52889 Jul 19 '15 at 11:48
  • 4
    My first reaction was also that this could be an interesting question but that it would be a terrible question to hit someone with cold in an interview situation. I know I could not possibly answer it without some time to think. – Carson63000 Jul 20 '15 at 1:52
22

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.

  • 7
    @Zeks Clean up a few times after people who lost their enthusiasm and passion and finish what they were supposed to do on top of everything you have to do, and it's quite possible that you'll make me look like a cheerleader :) On the other hand, I'll know that I can count on you to get it done come hell or high water once I tell you it has to be done - that's not a small thing to me. – Vietnhi Phuvan Jul 19 '15 at 12:06
  • 8
    This. Not everybody runs around wittering about pieces of code going "omg I have such a passion for this" and memorising individual functions that turned them on more than other individual functions. The question is totally stupid. – Lightness Races in Orbit Jul 19 '15 at 16:15
  • 5
    I really don't think it's stupid. not quite appropriate - maybe, as this thread showed, but I see a programmer of 5 years with no passion for his job whatsoever a little strange. Especially after technical questions showed he never learned to spot things like returning a reference to temporary. – Zeks Jul 19 '15 at 18:03
  • 2
    He was given a very simple function (4 lines) and asked "what is wrong here?" Not spotting return by reference to a temp in such situation is kinda indicative.... – Zeks Jul 20 '15 at 13:03
  • 1
    It depends how you approach programming: 1. you could approach it as a craft like writing. However, there are many bad writers out there - and there are many bad programmers, too; 2. you could approach it as a discipline. Those of us who do that call ourselves software engineers. Any passion I had for my job as a chemical/environmental engineer was for the impact of my job on society. The job itself - meh. You'll have a tough time finding a civil engineer who gets ecstatic about the sewer lines that they designed or the shopping mall that they helped built. – Vietnhi Phuvan Jul 20 '15 at 14:42
12

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.

  • 1
    I don't think asking them to show some code they don't like is much better - they're also very unlikely to remember a good example, and trying to find one in a short period of time will likely lead to compromising. – Dukeling Jul 20 '15 at 13:06
  • That was the point of the last escape clause: Show them a piece of code you picked and ask them to walk through it. – l0b0 Jul 20 '15 at 16:50
  • Horrible thought, if I said "I downloaded OpenSSL and I loved it", what would you do as the interviewer? – gnasher729 Jul 20 '15 at 19:53
  • 1
    @brian_o Necessary != sufficient. You might want to read my whole answer. Adaptable != writes a ton of code to solve a simple problem. And slow, stubborn and intransigent != knows how to design worth a damn. – l0b0 Jul 21 '15 at 22:22
  • 1
    @jamesqf Still a straw man - I never mentioned learning a specific browser in depth, certainly not at an interview. And the comparison of violinists and pianists is more like comparing a Python expert with a JavaScript expert. Just like I would expect absolutely anyone to know how to operate any electric kettle, I would expect a developer to be able to operate a browser on a basic level, no matter whether the back button is on the left or the right of the address bar, or whether the search bar is at the top or the bottom of the window. – l0b0 Jul 22 '15 at 7:04
10

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.

  • 2
    "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." This sentence pretty much says it all! I'd consider placing this at the top. – Dan Henderson Jul 20 '15 at 12:35
  • 4
    IMO your comments on the responses are not useful enough (and probably too opinionated) to take up that much space. If I were you, I'd get rid of it and optionally replace it with a sentence or two. – Dukeling Jul 20 '15 at 12:58
  • 2
    @Dukeling, this entire discussion is too opinionated IMO. – Mewa Jul 20 '15 at 18:53
  • Answer is good except your statement about it being relevant – SoftwareCarpenter Jul 27 '15 at 19:06
6

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.

5

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.

  • 2
    To say it's appropriate for an interview, you're going to have to argue about more than how easy it is to come up with a good or acceptable answer (in the moment one might think a question is good or bad based on one's ability to answer, but there are other, perhaps more significant, factors to consider). – Dukeling Jul 20 '15 at 18:18
5

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.

  • The interview was kinda lengthy so time to produce something was not a problem. He also had a laptop with him with some of his previous code that he showed us before the question was even asked. I simply wanted to see if he had anything there he was willing to talk about. – Zeks Jul 31 '15 at 15:47
4

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.

  • 5
    Actually, no. If he showed me a piece of simple code and explained that he liked it because it is simple to understand and explain how it works, I would be ok with such an answer. Like I said in the original post, pretty much any answer will satisfy me as long as it shows something other than indecisiveness and allows further conversation. It was not a question with a single valid answer or train of thought. – Zeks Jul 20 '15 at 9:08
  • 2
    @Zeks: it may be true that you would be ok with that, but an interviewee may be nervous and probably feels pressure to show something impressive, or at least interestingly complex. – RemcoGerlich Jul 20 '15 at 9:13
  • 4
    NO. The difference is that in the actual job I'm just doing my best to create a good program, while in the interview I need to quickly think of an example that I hope will help convince an interviewer that I am a good programmer at first glance (because there isn't time for more). Good programs don't at first sight look like they needed a good programmer to write them. – RemcoGerlich Jul 20 '15 at 14:41
  • 3
    @ReallyTiredOfThisGame: It's not about standing behind it. Of course I stand behind such code and would defend it in an interview, I just would never choose a "boring, simple" piece of code as the one example of all my work I show an interviewer. Interviewers choose the candidate they are most impressed by, so in such situations I try to think of impressive things I've done, as would most people. Daily programming on the job is not about selling yourself, interviews are. – RemcoGerlich Jul 20 '15 at 21:30
  • 3
    If this is the only such question in an interview, he basically did. – RemcoGerlich Jul 20 '15 at 21:34
2

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.
1

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/

  • PS I think I'm going to start asking this question during interviews. A question I've often asked is "if you had to do a 1 hour tech presentation for your fellow engineers, what would it be about?" – Alan Wolfe Jul 20 '15 at 2:04
  • Most of your answer is about what you would respond, rather than whether or not the question is actually appropriate - you've essentially got a single sentence answering the question, which is not particularly substantial, and not particularly appropriate given that this question doesn't have a clearly correct answer, thus any answer needs to do quite a bit of justification. – Dukeling Jul 20 '15 at 17:42
  • This question seems heavily opinion based so was throwing my opinion in, justifying it with an answer I think is appropriate to show the value of the question, and mentioning that I am at a notable employer in my field. I didn't mention details cause it seems like tacky name dropping, but I'm in a senior engineering position at a company that is well known globally for game development. – Alan Wolfe Jul 20 '15 at 17:46
  • 1
    Hmm. not sure how your code prevents repetition of the same indexes. I can see it's less common, but assuming the hash is semi-random, I can't see that you've ruled it out. (Would have commented on your blog but don't do FB logins.) – Thomas W Jul 21 '15 at 3:06
  • 1
    BTW great question. It's a really crazy technique that doesn't seem like it should be possible :p – Alan Wolfe Jul 21 '15 at 3:26
1

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.

  • 1
    I don't know. I don't really know any code I like. -- Not someone you really want talking to clients. Clients like features. They don't care about code (unless code is an actual product you're selling clients). – brian_o Jul 22 '15 at 19:39
  • Yeah but clients hate "I don't know", the point is come up with a fancy way of saying it like "I'll get back to you.". In this case, maybe "I don't have the code but I always liked how foo did bar." – coteyr Jul 22 '15 at 20:30
  • @brian_o A developer should think of the internal "askers of things" of clients even if they don't talk to "real" clients. Your sales guy doesn't want to hear IDK any more then a real client. (Except when it gives them room to make things up) – coteyr Aug 1 '15 at 19:02
0

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.

  • I realize the question is about coding, but all interviews could benefit by having people perform the actual work they'll be doing or at least have some sort of portfolio of previous work. Obviously, we're not going to make people perform open heart surgery as a test, so there are exceptions. – user8365 Jul 20 '15 at 16:26
  • The "Lead up to the question" part is pretty ambiguous - do you mean the interviewee should show good / bad examples, or should the interviewer? Should the interviewer label them as good or bad or is that a question for the interviewee? That part also doesn't really fit into your answer. The whole rest of your answer seems to discourage the question, except for this part, which says how to ask it. – Dukeling Jul 20 '15 at 17:29
  • I'm not saying the question is good or bad, but I think the whole point of the question is to find out how the interviewee thinks, so giving exactly guidelines as to what you want pretty much defeats the purpose. – Dukeling Jul 20 '15 at 17:31
  • @Dukeling - If that's the purpose of the question, then I don't think it's appropriate. With some improvement, it could be. – user8365 Jul 20 '15 at 17:41
  • @Dukeling - The OP is doing the interviewing, so it's from that perspective. – user8365 Jul 20 '15 at 17:43
0

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.

0

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.

  • this doesn't seem to offer anything substantial over points made and explained in prior 14 answers – gnat Jul 21 '15 at 9:00
  • I didn't see anyone mention that snatched implies theft and plagiarism. The rest of my answer was for completeness in rephrasing the question to remove the implication that the candidate could be a thief or land an employer in legal trouble. – Karl Brown Jul 21 '15 at 9:08
  • I read "or something you snatched from the internet" as allowing code that is not mine. So I would probably point to a one-line solution to "fizz buzz" that I found in a dailyWTF thread. - Not mine, but I am not claiming it is either. – Taemyr Jul 21 '15 at 14:50
  • tbh, "snatched" was the closest term I had in mind when translating the original question from Russian to English and originally it was phrased a bit different without the implications that's risen in translation. Even though I think even this term doesn't imply theft in any way. – Zeks Jul 31 '15 at 15:49
  • After all, most of the "snatched" code comes from StackOverflow (at least for me) and you could hardly call it thieving – Zeks Jul 31 '15 at 15:51
-1

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.

  • 1
    There's many steps between 9-to-5 programmers and "artists". And frankly, most "code artists" I've met have been horrible developers - in the end, you have to produce something of value to the customer. – Luaan Jul 21 '15 at 9:03
  • Re "every variable name a short sentence": Now that I would call really bad (= unreadable) code :-) – jamesqf Jul 22 '15 at 6:21
  • @jamesqf Fools sneer at the gods. – Socrates Jul 22 '15 at 12:50
  • @Socrates: I'm an agnostic, myself. And frankly, anyone who would use Lisp as a macro language is closer to a demon :-) – jamesqf Jul 23 '15 at 0:12

protected by Community Jul 21 '15 at 16:05

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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