

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

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].<p>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.<p>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.<p>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?<p>[1]: http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code
======
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.

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

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

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

------
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!

~~~
RiderOfGiraffes
Given that problem is NP-Hard I'd be interested to see your code.

~~~
relix
It's an implementation of the Bron-Kerbosch algorithm [1].

[1]: <http://en.wikipedia.org/wiki/Bron%E2%80%93Kerbosch_algorithm>

~~~
RiderOfGiraffes
That link didn't work for me, this one does:

<http://en.wikipedia.org/wiki/Bron-Kerbosch_algorithm>

Thanks.

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

------
SimHacker
Give them something that will make their eyes burn!
<http://www.donhopkins.com/home/code/display.c.txt>

~~~
relix
The skull and bones really sets the atmosphere.

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

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

------
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?

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

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

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

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

