3 ms·

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 y

by edw519 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
    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 16y ago
    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 16y ago
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 16y ago
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 16y ago
  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 16y ago
Interesting points, thanks. You'd be surprised at what high-profile company I've encountered this.

by edw519 16y ago

_corbett 16y ago

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 16y ago
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 16y ago
  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 16y ago
  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 16y ago
  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 16y ago

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 16y ago

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 16y ago
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 16y ago

Interesting points, thanks. You'd be surprised at what high-profile company I've encountered this.