Skills to Pay The Bills…

…part of an occasional series of articles on recruiting, interviewing, being interviewed, and “getting the gig”…

Several weeks back I ran across a candidate whose resume really had me excited. My company had a couple unexpected departures from our engineering group, and one in particular was really difficult. We had a very skilled (very very very skilled) JavaScript engineer on our team (let’s call him “Jason”)and he was poached by another company. I was (and still am) in deep mourning for the loss of Jason. But stuff happens and as a result we were on a search for a replacement and the candidate looked awesome. He had deep experience with JavaScript, had led teams on big projects, had an interesting background, etc.

So we brought him in for an interview. I was pressed for time and didn’t do a drill-down on his programming skills. I focused instead on his ability to lead teams and mentor less-experienced engineers, and got a readout on some of the projects he had led, the things he was working on now, and all that. I was feeling pretty positive about the candidate and as things were wrapping up I asked “So on your current and past projects — do you write code every day?” The candidate assured me that he, in fact, did write code every day. Given that the position he was interviewing for was largely a coding job, I just wanted to be sure.

I handed him off to the rest of the interview loop, certain that I’d be sending him home with a hand-shake offer (pending reference checking, final salary negotiations, etc.). But as the engineers on the interview loop came out of their meetings with the candidate they were all universally very concerned. Things like “not sure he’s that skilled” and “not sure he understands algorithms” were said.

Jason, who was leaving , lives and works remotely and was still part of the team at this point. He had talked to the candidate very briefly prior to the interview and was positive about him. Since the team was so concerned we quickly arranged for Jason to be on the interview loop remotely.

Jason knows what’s up with everything in the JavaScript space. He tracks everything, reads everything, and is a crazy skilled developer. He was alerted to do a skills checkup, so he got out JSFiddle and worked through practical programming exercises. He asked questions from a long list (which he later shared with me).

Jason was last on the interview loop, and as we showed the candidate out it was obvious things had not gone well. The candidate left clearly upset, looking grim. So I got on HipChat to follow up:

Me: well?
JaSon: so horrible
Me: wtf
JaSon: it was awful, i seriously don’t think he’s programmed in JS before

WTF indeed. I rechecked everything: JS skills on resume? Yes. “Writes code every day?” Yes. Jason’s questions super hard and unreasonable? No. So again, WTF?

So basically was the candidate was lying? That’s harsh. Eager and aggressive recruiter cooked the resume a bit too hard? Possibly. Did the candidate have an overly optimistic view of his skills compared to market expectations? Yeah that sounds better. Perhaps the candidate never had to do something really difficult with JavaScript in his previous gig. It’s hard, though, to understand why somebody would hype up a skill they lack or have never “put to the test” and then get killed in an interview setting.

If you’re out there interviewing don’t be that guy. Here are some things to keep in mind:

  1. Don’t lie or mislead on your resume (duh). That seems like trite advice but people do it. All. The. Time.
  2. Don’t over-sell your skills. You’re not a badass unless somebody who doesn’t work for you tells you that you’re a badass.
  3. If you’re represented by an agency make sure to review how they’ve structured your resume or profile. If they’ve got it wrong make sure to correct them and don’t let inaccurate or misleading paper go out to potential employers.
  4. If you think you have crazy skill in a certain area go find out. Get to MeetUps and talk to people and measure yourself. Go onto Stack Overflow, answer questions, and see how the up-voting goes. If you can’t answer the questions or you’re not seeing the votes then you have some clear areas to work on.
  5. If you’re interviewing for a job where a singular skill is listed and valued by your potential employee above others, then expect to be tested and evaluated. You might be asked to write code on the spot, you might be asked to whiteboard something. You might have to JSFiddle.
  6. You might be asked to deliver a take-home project: some small coding project that might take 3–4 hours to produce. Be ready (and willing) to do that. Also, if you want the gig don’t suggest that you get paid to do a coding exercise for, “oh I dunno…how about $500”. Yeah, that happened.
  7. If (6) happens please don’t Google for the solution and cut/paste it. That’s just embarrassing. People do this, believe it or not, and not unsurprisingly most employers check for this sort of thing. College professors are doing the same thing for student homework now too.
  8. If you’ve got it, don’t hesitate to show off. Post your work (your own stuff, not your current or past employer’s) in a public github repo. If you don’t want to share code, the set up a blog and write about how to do cool stuff. This is not easy — in fact I’m guilty of a bit of a hypocrite here insofar as I’ve not set up a public github repo for myself. Blogging also takes a surprisingly large amount of time to do well —nevertheless, if you enjoy writing you should definitely try it.

Interviewing is time consuming and expensive for everybody. If you’re the candidate you need to take time away from your current gig, get yourself downtown and back again, and all that. You’re burning a vacation/sick/PTO day and anywhere from $20 -$100 in expenses to get to and from an interview in a major market city close to where you live.

And consider the potential employer(s). They are going to schedule probably 4–6 hours spread across several employees. That’e easily $500 — $1,000 in fully-loaded cost…and that doesn’t consider lost productivity as employees take time away from coding, architecting, and problem-solving to meet with you.

If you haven’t got the skills to pay the bills don’t waste your time or that of potential employers. Be ruthlessly honest with yourself and you’re much more likely to get a good result. And that will make everybody happier in the long run — especially you.

Show your support

Clapping shows how much you appreciated Christopher Gillett’s story.