Why Hiring is So Hard in Tech

Talent Shortage

Recruiting Costs

Other ways to attract direct referrals:

  • Maintain a company tech blog
  • Encourage employees to speak at events
  • Encourage employees to be active at meetups
  • Set aside time every week to contribute to the open source community

The Compensation Race


It’s easy for your competition to poach your best talent.


This problem is easy to spot on many coder resumes: Quick jumps from one job to the next with ever-more-impressive company names and job titles.

Interviewing

  • Puzzles and riddles
  • Whiteboard code tests
  • Big O notation quizzes
  • Detailed quizzes about the mystery corners of the language

These work great (in order of value):

  • Pair program with candidate on an actual issue from your ticket queue (let the candidate drive)
  • Code samples / OSS contributions
  • PAID Sample project assignment (err on the side of paying fairly — say $100+/hour for estimated completion time — if the problem should require 2 hours to complete, offer $200)
  • Review past work / portfolio
  • Read candidate blog, publications, watch candidate talks
  • Ask candidate for input on a real problem you’re currently working on
  • Ask specific questions about software problems and solutions from candidate’s resume

Startups are miserable at interviewing candidates. To assess skills, founders rely on their existing engineers, but most engineers are terrible at interviewing candidates.

Instead of assessing a candidate’s abilities, engineers often pick stock puzzles (puzzle performance has zero correlation with job performance), whiteboard coding demonstrations (nobody codes on a whiteboard on the job), or CS101 algorithm tests (experienced devs forgot the useless crap they learned in CS101 years ago so they could remember all the algorithms and design patterns they actually use in real-life).

None of those strategies work. They only make the interviewer feel superior, while the candidate struggles because none of those skills get practiced on the job. If a candidate aces those interviews, beware: They’re either fresh out of school with little job experienced, or they spent their time studying for coding interviews instead of actually coding and learning the real skills that are needed to write real apps.

I kid you not, there are books dedicated to acing these useless interviews, and mediocre coders who lack proven skills buy them so they’ll get hired in spite of their lack of visible coding talent.


Want to land a job at a company that sucks at hiring?


How do you identify good coders?

  • Look at their portfolio and accomplishments
  • Look at their GitHub profile
  • Look at their StackOverflow profile
  • Glance at their resume (distant last place)

Resume Assessment

Great candidates highlight accomplishments & products they built. Mediocre candidates list a bunch of skill buzzwords with no supporting evidence.

Great candidates:

  • Show, don’t tell
  • Stress accomplishments & products over buzzwords
  • Link to GitHub profile URL for sample code
  • Link to portfolios or apps they contributed to
  • Link to StackOverflow profile URL
  • Link to Conference talks, blogs, or publications
  • Designers link to Behance or Dribbble profiles

See a pattern here? The best resumes are really a one paragraph summary of accomplishments and a collection of links offering proof.

Job history is still important, but like the link collection, descriptions of those jobs should offer evidence to support the summary of accomplishments.

Poor candidates:

Note: These are just red flags. You shouldn’t dismiss a potential candidate over this stuff. Some people are great developers, but terrible resume writers.

  • Stress skill buzzwords over accomplishments and evidence
  • No portfolio URL, blog links, or links to products they contributed to
  • Don’t provide details of accomplishments and problems solved in previous jobs

While we’re at it, most companies are also terrible at evaluating employee developer performance, but that’s another story.



Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), host of the documentary film-in-production, “Programming Literacy”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.

He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.

JavaScript Scene

JavaScript, software leadership, software development, and related technologies.

Eric Elliott

Written by

Make some magic. #JavaScript

JavaScript Scene

JavaScript, software leadership, software development, and related technologies.