HN Explorer

Ask HN: "a piece of code you're proud of" - what does it mean?

23 points by relix ↗ HN
I'm looking for a job, and sometimes during the application process, companies ask you to copy+paste a piece of code you're really proud of. I can only imagine they want something incredibly mind-blowing, like the Fast Inverse Square-Root [1].

But I don't have such code. I've been programming for years, and there's no singular piece of a couple of lines that stands out. It's mostly boring, readable, well designed code that is maintainable. There's nothing sexy about that.

Sure, I'm proud of some large pieces of code. Thousands of lines that span an MVC architecture and three different platforms, for example. But the interviewer can't possible take the time to read it all and understand why I'm proud of it.

Should I whip up something incredibly complex, using the most esoteric syntax elements possible for optimal premature optimization, a nightmare to maintain, just to appease interviewers in this situation? What do you do HN?

[1]: http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code

42 comments

[ 3.9 ms ] story [ 98.8 ms ] thread
tyng
"The devil is in the details", they say, have you ever coded something that by changing just one line it improved the performance of an entire system?

The interview question is designed to see whether you are the type of person that has lots of initiative, and would always walk the extra mile to improve an existing system, I suppose

relix
Sure, but this won't be clear without context or backstory. I could explain why it did that, but I guess the employer wouldn't know if I'd be telling the truth. Wouldn't this diminish the effectiveness of it?
kranner
I'd think the combination of unnecessary complexity, esoteric syntax, etc. would do the opposite of appeasing interviewers, which might be a waste of time for you overall.

Perhaps you could put together the most elegant solution (to your taste) of a well-known toy problem, and use that in such situations?

Online judges are eminently suited to this sort of task. They're a-dime-a-dozen these days. Heck, you'll find one in my profile!

relix
I've implemented a solution to the maximal clique problem in a very elegant way, and have used that piece of code in the past, because it's optimal and quite small (about 100 lines). I guess that fits your description, so I've been on the right track all along.

Thanks for your suggestion of online judges. I didn't know there was such a market for code-judges, interesting!

Jach
I didn't know companies actually wanted you to copy-paste: they should consider your proudest code is closed to them, especially if you've worked at other places before.

My understanding was that such questions were more correctly phrased as "Tell us about a project you've worked on that you're proud of" (and I've had something like this a couple of times), in which case you briefly mention some details of a project that "spans an MVC architecture and three different platforms" or something else. If they want some specific code, you tell them you developed it at another company and cannot give any source, but you can describe the overall function of the software. (If it's open source, say you can link them to a repo.)

They probably want you to tell a story about the code and reveal loads of information about yourself, and it may help to do so, but you should only do that when you really know what type of story the hiring person wants to hear. I'd keep it strictly to the purpose of the software, and even something as innocent as "I made an abstraction that replaced 700 lines of Java with 40" can be taken many ways: "He's awesome, we want people who can make abstractions, let's hire him!"; "He coded 700 lines and didn't see the abstraction until then? He must suck."; "He's not afraid to make fairly large changes to teammates' code?[good or bad]"; "He thinks lines of code are awesome metrics?"; "Ew Java."

If they really, really want code, and it has to be a simple function or something, you could throw in a simple Scheme implementation of the map function and go off about map/reduce.

relix
I've had several run-ins with literal "paste here some code you're proud of" textareas.

As you said, when they're asking to describe something you're proud of, like how Y-Combinator does it, it's a lot easier and relaxed.

The several ways of interpreting such an innocent lines are revealing, thanks for the heads-up!

dpritchett
I always figured it was best to paste a URL to some code repo.
b1twise
Asking for a code snippet seems to break the question--I can't imagine anything you paste making much sense without context. My honest answer would be to quickly mention that you're not able to paste the exact code because of confidentiality with the previous employer, and then to begin talking about the code and why you're proud of it.

I ask a question very similar to this when I interview, and I'm looking for applicants truly interested in the work they do and computer science. The occasion to apply an obscure algorithm, refactoring code to improve it dramatically, unusual elegance in a solution...

_corbett
> mention that you're not able to paste the exact code because of confidentiality with the previous employer

as an interviewer I'd be skeptical if the interviewee not only was secretive about his/her code, but had no pet projects or toy scripts lying about.

I think it's a great question because not only do you get a quick sense for how people code, but the response choice itself gives you some insight in to how people think and what gets them excited about hacking.

Retric
I have pet projects, but I am not impressed by them. The type of code I write for a one off project for myself is vary different than code I would write as part of a larger project.

EX: I thought the twitter people where idiots so I codded up an outline for a solution that would fix their basic problem. I quickly got to single threaded code that was significantly faster than what they used and reasonable memory efficient so I stopped. However, it's not exactly a hard problem and it's not production worthy so I feel no reason to share it with other people.

arghnoname
This is the problem I have. I have a strong sense of professionalism, so when I code professionally, I put in more effort to meet a personal standard that far exceeds what I do for personal projects.

One simple example, if I'm writing a utility to be used by me alone, I probably don't verify input. I don't do very good error handling (if it crashes who cares), etc, but if I were hiring the lack of any of these would be a serious red flag to me in any submitted code sample.

Of course there are larger personal projects were a little more care is taken, but it is a whole other level of polish that I put into professional work. I would be embarrassed to share my personal projects. That's probably actually a good sign because at least I know it should be better.

anthonyb
I use a similar tactic myself whenever I'm interviewing people - think of it as "FizzBuzz" on steroids. It's an easy way to:

a) see if you're a decent programmer, ie. are there any obvious bugs/SQL injections/limitations, and

b) get you to talk about why you've coded something a particular way, what's good about it, etc, etc. Essentially an ice breaker question.

The other option is for me to try and find something that you've done online (eg. an open source project) and ask questions about that, but some people might think it creepy, so I try and get you to contribute code first.

beaumartinez
The code I'm most proudest of is that which solves a problem I thought would be unsolvable, with which I tried using several different methods, to then eventually settle on a final design, probably a compromise between readability and efficiency.

I think you should give them code that tells a story. One with comments which explain why you did A and not B. Write an accompaniment to it "At first, I tried A. I researched and found out X, but...".

Few people can discover something as incredible as FFT, or FISR. Those are one-offs. It shows a lot if you worked hard at getting a solution to a problem and that you're proud of it; you didn't just copy-paste, you tried different ways of solving it and ended up with a solution that's, in the words of Goldilocks, just right.

Or that's what I'd send them at least.

MC27
If you wrote your own framework then you could grab an area of the code like a database layer, caching system, template system. If you built code on top of an existing framework then that's more difficult, because it's higher level, more abstract and spread out.
thibaut_barrere
> It's mostly boring, readable, well designed code that is maintainable. There's nothing sexy about that.

Quite the contrary: I wouldn't hire someone whose code isn't like that.

RiderOfGiraffes
As an interviewer, if I ask for code it's for three reasons. I want to know:

a. ... that you can write code.

b. ... what your code looks like, to see your style.

c. ... how well your taste and judgement aligns with mine in the question of "good code".

I wouldn't want much, I wouldn't want anything world-shattering, I just want to see some code you think is clean and effective.

But that's me.

relix
Sounds good, but couldn't the applicant just copy code from the internet which he heard was good code? It doesn't prove he can write code.

This does make sense if you'd ask him to explain it at the interview, but then the applicant can also give context and explain why he thinks it's good code.

RiderOfGiraffes
Anything done on paper/email could be the work of someone else. The first thing we then do in interview is give the person a disk-less, internet-less machine and get them to write FizzBuzz. As they do it we get them to talk about their usual dev environment.

Once they've done that we move on to discussing the code they sent.

All these things are purely to weed out the complete time-wasters. From the remainder, we then try to find someone who can design, code, document and collaborate.

code_duck
I suppose, if you want to be disqualified for plagiarism. No different than handing in someone else's work for college.
ams6110
I'd assume that anyone receiving code "from the internet" could quickly determine this was the case with a few minutes' time on Google.
anthonyb
No, because in the follow up (either telephone or face-to-face) you're normally asked questions about the code (I do, anyway). It's incredibly easy to spot people who've cut+pasted something and have no idea how it works - just ask them why they did it a certain way, or what tradeoffs they made, and watch them squirm...
edw519
Don't ever do this. Just a few reasons...

1. You say "during the application process". Have you even met the hiring manager at this point? Worse yet, have you met anyone or are you just stuck in some automated process? Never forget that employment application is a two way street; you're evaluating them as much as they're evaluating you. They haven't earned the right to see your code yet.

2. This approach should be a red flag to any applicant. They want to see old code to evaluate you when they are 64 betters ways to do that? Something's fishy here - someone has no idea what they're doing.

3. Do not allow anyone to read your code out of context. You need to be there to explain the background, motivation, approach, and answer any questions. Cutting and pasting preempts yourself. Bring hard copy along only after the process has progressed far enough.

4. Only bad things can happen. This is like being the first the mention a number - you can't win. If someone wanted to hook up with you but asked for a dirty underwear sample first, would you give one? This is the same thing.

5. If your code is proprietary, who knows where it could end up? You may also be violating confidentiality agreements. Not worth it.

6. The employer-employee relationship is a never ending tension. You will always be "negotiating" money and working conditions, whether you realize it or not. Giving in to such an unreasonable request so early in your relationship marks you as a chump. You may never recover the equal footing you need (and deserve) in the ongoing relationship.

7. If they have a problem, move on. You're probably saving yourself a lot of trouble down the road.

You sound like a competent developer who should have no trouble finding a job without bending over. So don't.

[Aside: Because of this kind of thinking, I never give references before being hired. In essence, I'm telling the prospective employer, "You decide." They then have the right to rescind the offer if they don't like a reference.]

_corbett
I summarily disagree.

1. A chunk of my code is FOSS, sure they have earned the right to see it.

2. It's a red flag when an employer doesn't ask–shows me the hiring process may be more centered on solving questions/puzzles on the fly (which I'm very good at, so no bitterness-just that I'd rather work with people who love to and are talented at hacking which is not nec. the same thing).

3. Find a good coherent chunk, generate one, or put in something out of context but representative of your style as a hook to chat about the larger cooler project.

4. Not true at all, it could, in fact, land you they job.

5. You're right in that proprietary code is an issue, but I'd be skeptical of a candidate whose entire codebase was proprietary. Not even a single toy project or piece of home brewed code?

6. Taking a stand against an employer seeing you in action and getting a sense of your interests before employing you is not in your best interests while negotiating more money typically is. Remember you want to work with people equally competent and engaged as you are. You may be hot stuff, and the employer may get lucky buying your book without having seen a line of your great American novel, but it's easy to make mistakes when hiring and they are hard to correct.

7. That I do think is true–there are certainly employers out there which ask different questions, so finding the ones that are the best fits for your style and principles saves everyone time.

daleharvey
I think everyone of those points is dependant on some underlying assumption that its possible to have some snippet of code that makes it possible to evaluate how good you are as a developer, which at least to me sounds about as crazy as judging develop productivity by lines of code.
mattm
I think there is some truth to that. When I am new to an existing codebase, in under an hour of reading code I can gauge the experience level of the coder.

Of course, a tiny snippet of code would not be as useful.

_corbett
I agree with you there for sure. The more holistic the interview process the better IMO. In fact I'd prefer to see a project in addition to a snippet.

You can't tell a decent coder from a great one with a snippet, but you can get a picture of their code and their tastes.

anthonyb
It won't evaluate how good you are, but it's a very easy way to tell if you're bad. Think Fizzbuzz and you'll be on the right track. I've had people who've submitted code which doesn't run, has obvious buffer overflows and bugs, or is just plain indecipherable.

You'll also have an ice breaker if you want to interview them - just ask them about their code...

brown9-2
2. This approach should be a red flag to any applicant. They want to see old code to evaluate you when they are 64 betters ways to do that? Something's fishy here - someone has no idea what they're doing.

Seems like cargo cult interviewing. A company sees other companies doing the same things and decides "this must be a good thing to ask about!".

mattm
I'm interested in knowing the typical hiring process you go through when looking for work if you don't do any of these. Do you only offer to write code on the spot then to back up your experience?
edw519
Simple. Whatever it takes without being uncomfortable about it.

Things I will gladly do:

  - phone interview with as many people as you like
  - physical interview until I think you have enough information to decide
  - share any of my work face to face
  - on-line third party evaluation (code test, personality, etc.)
  - review any of your system with you
  - code for you in person
  - sharing on-line information (including all hn posts)
  - doing up to 8 hours of free sample work
  - provide a referral if they are a better fit
Things I strongly push:

  - in depth discussion about the employer's situation
  - reverse interviewing employees with similar jobs
Things I will gladly do, but only after a job offer:

  - provide references
  - drug test
  - credit check
Things I will never do:

  - have a generic resume (every one is uniquely targeted)
  - post any resume on-line
  - pay a fee
  - physical interview with a head-hunter
  - provide anyone else's proprietary information
  - "bad mouth" anyone else
relix
Interesting points, thanks. You'd be surprised at what high-profile company I've encountered this.
erikstarck
I feel a little proud when I can _remove_ code. Does that count?
wazoox
I personally ask for code you did for its own sake or your leisure. If you can write good code for fun, then you're a programmer I'd like to hire. I don't know any other valid metric for code because I can't know why and how you were asked to code this or that.
zackola
This sounds like pure laziness on their part. If they want to see a small chunk of code you are proud of to evaluate competence and style they should be asking you to solve some puzzle or problem with code. Etsy does this, so does Dropbox. http://www.dropbox.com/jobs/challenges
code_duck
I've seen this on some job descriptions/applications. Yes, it was from a company that has problems with clarity of though, originality, and generally everything.

Most likely linking to a web site about a project you participated in of which you are proud would be more thorough.

gry
I saw a comment here once which makes lots of sense -- find a programming exercise you find interesting and show it as an example. You a) show interest in developing your skills b) show your style and c) don't have to worry about showing something which doesn't belong to you.
j_baker
I've never had anyone ask me to actually copy and paste a piece of code that I'm proud of. I have had people ask me to point them towards code samples on github that I'm proud of though.

If they're good employers, they're probably just looking for examples that you take pride in your work and that you can actually write code. Thus, my advice is to be honest. Even if the code isn't "sexy" or even that good. In fact, I've done well several times at this point of the application process simply by saying "This code sucks. But I'm proud of it anyway and here's why."