Why’s it so hard to find good programmers?

“In fact, one thing I have noticed is that the people who I consider to be good software developers barely ever apply for jobs at all.” 

Good point. The best developers I ever hired were (a) already working, (b) not looking, (c) referred, and (d) without a current resume. 

Therefore, the people who I consider to be good software developers probably don’t have a current resume. 

Therefore, the top 1% of good software developers probably don’t have a current resume. 

Therefore, if you have a pile of current resumes, it probably includes none of the top 1% of good software developers. 

Therefore, if you’re hiring from current resumes, your probably “not” hiring the top 1%. 

[The only thing worse than sloppy probability and statistics is sloppy logic. But that’s OK, because I’m not in the top 1% of either.] 

Why doesn’t anyone call me back?

1. There is no position. We’re just “feeling out” the marketplace. 

2. There is no position. This was a headhunter building his database. 

3. We were planning to promote from within, but HR made us post the position anyway. We didn’t read or respond to any of the resumes. 

4. We already had the perfect candidate, but HR made us post the position anyway. We didn’t read or respond to any of the resumes. 

5. We posted the position as required by HR, but when an executive saw it on the intranet, he made us hire his son/nephew/family friend. We didn’t read or respond to any of the resumes.

6. We were planning to hire someone, but by the time the resumes started arriving, the perfect candidate presented himself. We didn’t read or respond to any of the resumes. 

7. We were planning to hire someone, but the budget was cut. We didn’t read or respond to any of the resumes. 

8. We got 1,200 resumes in 2 days so HR ran them through a filter with almost no correlation to potential suitability for the job. Your resume didn’t get through the filter. Next time, add buzzwords from the ad.

9. Your resume made it through the HR filter, but we only had time to read 20% of them. Yours wasn’t pretty enough. 

10. Your resume didn’t stick out in a field of many that did stick out. You probably should have some kick-ass differentiator FRONT AND CENTER. 

11. We read many great resumes. Yours was substandard compared to many of them for one or more of many possible reasons. Have 5 friends proofread it and give you brutally honest feedback for next time. 

12. Your resume sucked but you don’t. Find 5 friends. See #10. 

13. You interviewed well, but someone else absolutely kicked ass. We loved him/her. Tough break for you, I guess. 

14. You didn’t interview well, but we can’t really put our finger on it and don’t have time to respond. Tough break. 

15. You interviewed well and are still under consideration. But we are waiting on corporate for 27 other things. You’ll probably find another job before we get back to you. 

16. You really do suck. (No you don’t. Chances are the process never got this far.) 

How can a company blow a job interview?

Top Ways for a Company to Blow a Job Interview 

1. Make me wait in the waiting room past our appointment time. My time is as valuable as yours. 

2. Make me meet with Human Resources first. My time is as valuable as yours. 

3. Make me fill out forms. This can be done in advance. 

4. Don’t shake my hand. (I have no idea why this happens, but it does.) 

5. Begin the conversation with anything other than, “Hello,” or “Nice to meet you.” Again, why would the first words of any interview be, “How would you handle mass emails?” 

6. Don’t give me your business card. As a job applicant, I’m just as important as any vendor or business associate. This is a good chance to demonstate it. 

7. Criticize my job history. Here is the reason I’ve had 9 jobs in the past 5 years: Because there were poorly run businesses, assholes, and mismatches. The reason I’m here is to try to fix all that. Move along. 

8. Expect me to have 10 years experience in every possible technology your entire enterprise uses. I will learn what I need. Promise. 

9. Ask me how many gas stations are in the United States, how many ping pong balls fit in a bus, or why manhole covers are round. Frankly, I don’t care. There, now you have the results for both your I.Q. test and your personality test. 

10. Don’t follow up. I know that I’m probably not the only person your interviewing and this may take some time. Extend me the same courtesy you would the window washers. Don’t make me email you every week. 

Why do a coding test on a white board?

“on a white board, no syntax errors, compilable” 

Huh? You’re worrying about whether or not what you write on a white board will compile? How do you know? Press a magic button to OCR what you’ve written, download it into some computer somewhere, and compile it? Sounds like you’re interviewing at firms with technology I didn’t know existed. 

Your interviewers have you code on a white board so that they can evaluate “you”, not your code. They want to see how you handle a problem, how you approach your work, how you think on your feet, how you deal with interaction, and how your intelligence and experience applies to their business. Anyone who worries about whether white board code actually compiles is missing the point. If they’re more interested in perfect syntax than embracing you and your potential contribution, then you don’t want to work for them anyway. 

I think you’re making this too hard on yourself. Memorize nothing. Just be yourself. Programming is like riding a bike; once it’s part of your DNA, you don’t have to worry about it. Just relax, trust your inner programmer, and let this become a self-solving problem; some jerks may reject you, but the right fit will come when someone sees who you really are.

How to Write a Cover Letter

1. Write like you speak, as if told over coffee or beer. 

2. Informal, but not too casual. 

3. Right to the point; the first sentence is your summary. 

4. No bullshit, you’ll go straight to the garbage. 

5. If it sounds like bullshit, it is. 

6. Short. One minute good. Thirty seconds better. 

7. Tightly targeted! It’s about them as much as you.

8. Perfict speling and grammer. 

9. Highlight what’s important to them. (Do your homework.) 

10. Enthusiastic without sounding phony. 

11. Have friends read it. Get feedback. 

12. Does it sound like a good quick description of you? 

13. Have at least one differentiator. What makes you so special? 

14. Strong finish with a call to action.

Should I send a Thank You note?

“…it is 100% necessary to send an email…” 

I take it a step further. I always send a hand written Thank You Note by snail mail. Always. I have never failed to do this. 

Why? Because if someone has spent an hour of their time (I don’t care if it’s on company time) to potentially change my life, the least I could do is take 5 minutes to share a sincere Thank You. I always take the time to hand write it, I always make it personal, and I am always sincere. (If you’re going to be even 1% phony, don’t bother, people will see right through it). 

There are some nice byproducts. It demonstrates professional courtesy. It demonstrates good communication skills. It demonstrates good customer service. It gets you remembered. Every time. 

But I don’t do it for these reasons. I do it because it’s the right thing to do. It is never “annoying” or a “detriment”. Almost everyone I have ever sent a hand written note has told me that they really appreciated opening it and reading it. 

Sometimes I even take it a step further. Several times, I have asked public speakers what their favorite restaurant is, and then sent a gift card in the Thank You note. I really want them to understand what a difference their contribution has made in at least one attendee’s life. The gift card is a nice idea because I know they will use it and enjoy it, and maybe even think of me that night. I would never send a gift to an interviewer - that’s not the same thing.

What will you do for a prospective employer?

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

Should I show my code to an interviewer?

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

I don’t want to take a coding test

As a hiring manager, I look for someone who “gets things done”. No surprise that this takes many things: knowledge, skill, smarts, creativity, experience, team work, and maybe most important: attitude. You have just self-identified your bad attitude. If you think this is “draconian and insulting”, just wait until your knee deep in digital crap with customers barking at you all day long. 

“I cannot vouch for it’s efficacy as I’ve never used it when hiring people.” 

I can. Nothing works better. Period. If I have 30 to 60 minutes to find out how well you’ll perform, I’ll have you code and teach me what you’ve done. I don’t care what you’ve done before, your state of mind, or even if your code ever runs or compiles. If you’re any good at all, I’ll find out. If you’re a poser, I’ll find that out, too. And if you don’t want to play along, then either you’re a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road. 

I’m not trying to insult you, just give an honest answer to your (very good) question.

Should I go into management?

As a former developer turned manager turned developer again, a few suggestions: 

1. “Never” lose your developer mindset. Personally, I have great difficulty respecting a non-technical manager of technicians. I bet I’m not the only one. 

2. Manage things. Get good at project management. Very good. A good plan, agreed upon, well built and administered, will always be your friend. Something for everyone to fall back on when things get hairy. 

3. Don’t “manage” people, lead them. Preferably by example. 

4. “Everyone” has problems. Now that you understand that, don’t let people’s problems interfere with their work or nothing will ever get done. 

5. Learn the difference between issues and details. Focus on the issues. Don’t waste too much time on the 

details. And get your team to do the same.

6. When all else fails, communicate. When all else goes well, still communicate. Never underestimate the power of communication. You’d be surprised how much slack others will cut you if you’re simply open and honest with them. 

7. Treat everyone else the way you’d like to be treated. (This goes for everyone, not just managers.) 

8. Listen at least as much as you talk. (This also goes for everyone, not just managers.) 

9. Get stuff done. And have fun doing it. 

10. Lighten up. You’ll be fine.