Ask HN: Finding tech talent is getting harder. It's not a Bay Area problem only
On top of building the product, finding product engineers is becoming one of the hardest things for a CTO to do in 2019, especially in tech hubs like NY and London due to higher demand and competition.
This problem is no longer exclusive to the Bay Area. Hiring is time-consuming and expensive, and many startups feel that they can’t compete with some of the top salaries and perks offered by deep-pocketed alternatives.
It makes sense to rely on your network to hire the initial few developers, but this approach is not sustainable in the long run.
Job boards are getting crowded. Recruiters are generally worse.
I've read a lot of stories about using recruitment platforms. Few are great, but many are unpleasant. The flaw with many recruitment companies is they don't reliably deliver enough good candidates to build trust.
Asking for profile A and getting profile B is a common frustration. For startups, this tends to be a deal-breaker because hiring the wrong candidate has a significant cost and impact on backlog and team.
Is it that most recruiters or on-demand marketplaces aren't highly technical? Is it that they also suffer from talent shortage?
Remote work has been getting a lot of love in recent years to bypass the talent war. Although it has come a long way, it's still hard to pull off, especially for companies that are trying to do both local and remote but are not remote-first (think infrastructure and payroll primarily).
With that being said. How do startups in hubs currently find great engineers quicker? What's an approach that you have been investing in recently to hire product hackers?
104 comments
[ 0.26 ms ] story [ 171 ms ] thread1. Don't limit your potential talent pool to the miserable and the unemployed. In theory, any developer who is currently employed might be interested in leaving their job to work for you. Perhaps you will offer them more money, or perhaps a better quality of (work) life. However, most developers won't bother to talk to you if they already have a job. Why is that? Simple, if they do talk to you, you're going to offer them a homework assignment. You're going to tell them that it shouldn't take more than an hour, but it will actually take two full days to do right. Giving someone a homework assignment isn't a way to woo them away from their current job. So you are left with a candidate pool that consists mostly of people who are desperate enough that they have to agree to jump through your hoops (i.e. unemployed, miserable in their current job, etc.)
2. Don't discard capable people. The average interview begins with a remote code challenge whereby the candidate, who is probably nervous, has to pair program a completely contrived problem with a complete stranger watching them over a webcam. There are tons of developers who are good at coding solutions to real world problems in real world situations but simply don't perform well in this type of situation. This type of scenario is not really assessing a candidate's skills. It's assessing their familiarity with specific contrived interview problems and their ability to perform under duress.
Of course, the points you raised are fair as well. Recruiters are not technical people, they are sales people. You will have to find a good recruiter. They are out there, you just have to find the right ones. But my point is, once you find the good recruiter(s) don't waste the human capital they can being to you by having a terrible interview process. Here is my advice. Once your recruiter has a handful of resumes you like, carve out half a days worth of 30-minute sessions to meet with them at the recruiter's office. Ask them about projects they've worked on. You'll find out much more about what they know and what they're like to work with than you would with the typical remote code challenge. One you narrow the pool down a bit bring them in for on-sites.
Best of luck!
For context, I’m working as an Associate Product Manager (so not quite a Product Engineer) but I had applied for a job at a Start-up company that I found extremely interesting. Had an initial interview but didn’t hear back from the company for about a month. I had also sent follow up e-mails about this.
When I eventually did hear back from them, they apologised for their delay but then spun me with a homework assignment that would have taken at least 2 days. Safe to say, I kindly declined.
So yeah, really focus on how you’re recruiting for talent.
Our on-site interviews are highly contextual and rooted in the real-world where candidates work directly in our codebase. They are reasonable in the things we ask candidates to do (re-factor something, review PRs, implement a small enhancement).
If someone can't code in one of our core languages, it's a tougher assessment since we would have to resort to hypothetical/whiteboard crap (which we hate). How do you assess someone then? We recently had a candidate do a take-home where they didn't do well, and it did save 5-6h of everyone's time and their effort of coming in and being subject to the pressure of the interview.
I'd love to hear counter-opinions on this.
Curious; can you say more about how you judge this? Isn't that sort of the point of the homework in the first place?
I once did an all day on-site pairing interview with Pivotal. The morning was Swift/iOS and afternoon was Java back-end. I didn't have experience in either except some Java desktop GUI from a while back. It was all fine, they wanted to see how I think, what code paths I think of, what tests I choose for coverage. The actual syntax of what's being written wasn't the main point. That translates quickly on the job from experience doing similar tasks in other environments. If on the other hand, you've never written a test, or discussed code with a colleague those are not as easy to pick up from somewhere else.
If you're looking for top talent it wouldn't be measured against any singular tech stack. I tend to take positions on stacks where I'm unfamiliar, and no I wouldn't complete homework. Employers are competing for the good candidates and should have a process of identifying them without hoops.
Hiring and having a welcoming but selective process is rough :)
1. Please be prepared to actually sell your position. Most recruiters simply explain what the business is and then tell you that their engineering team is really tech focused. It's totally generic. It's nothing the candidate hasn't already heard from their recruiter or read on the web site.
What's special about your product or company? What kind of benefits do you offer? What makes your tech team so great? Have you built some amazing open source library? Is the CTO an ex-Google guy?
2. Please be prepared to answer some basic questions that an engineer will have. For example, what is your tech stack. "We use JavaScript on the front end" is not an acceptable answer (unfortunately, It's one I've received several times). Tell me what frameworks you use. I know you're not an engineer, but you could ask one to write it down for you.
3. Please know what the technical assessment process is. "We have a technical assessment" is not an answer. Is it a take home assignment? A hacker rank test? A remote code pairing? If it's a take home assignment, how long does it take? Again, you are likely not the only company the candidate is interviewing with. The candidate needs to know how long the process will take and how much time he has to invest.
What do you propose instead to see whether one can do real world problems in real world situations?
Remember, we're talking about a screening process. Once they come onsite for the real deal you can throw all sorts of stuff at them.
We will hire anyone who sounds good, and fire them within a month if it turns out they're not up to our standards. Then, we will ensure we never get anyone who isn't already employed and anyone just looking for a paycheck or three.
If you heard that even 20% of people were fired within the first month, how likely would you be to take that job?
Note: It's usually called contract to hire. And it just takes the interview stress and pushes it out to 1-6 months.
I would prefer that 80% of people are fired in the first month.
I don't ask for coding problems and don't have a strict interview structure. Instead, I try to make a conversation about the candidate and tailor interview around their experience. I also try find similar problems they face that we have and talk about solutions that we apply which helps me see how flexible they are or do they outright reject different viewpoints.
Ultimately, the main goal is finding the people that I would like working with because it trumps pure technical skills in importance. It might not work well where some highly specific and rare skills are required, however it works in average enterprise environment.
The interviewer should be a pretty good conversationalist, though.
The outside recruiting firms I have tried to work with have just been misery by comparison. They either don't know enough about what's going on or clearly don't even understand the position they are offering and it takes like 3 or 4 back and forths to get the real job description and it doesn't even make sense. From the other side once my current role started resourcing from an outside firm the matches were worse and worse and I wonder if it just was because the rep on the other side couldn't talk about our actual company in any meaningful way.
Talent shortage means that employers can't find workers with the skills the claim they need at the price they want to pay.
Then you only ever have a sequence of rejections ending with a job offer. Of course you will feel terrible if this is your strategy.
Do a few more interviews and you'll find that sometimes you get two or three offers in a row.
Absent a large open-source repository or other public corpus of work, you generally have to rely on one or the other.
I'm unsure how this could happen with any sane vetting process.
I do believe the "technical" layer in a recruiter is the most important thing. Amarraja, how do you go about vetting your recruiter? Have you had any set of criteria to identify a solid talent acquisition partner?
This sticks out: the hiring process is really bad at making this judgement effectively. We face this problem at my company, most of our best and worst team members have been surprises.
An interview can result in a bad engineer being hired and later fired (a false positive). And an interview can disqualify someone who could have done that job well (a false negatives).
In order to keep the false positive rate low in the face of this noise, companies have to bias decision ever farther toward rejection. The result is a process that misses good engineers, still often preferences credentials over real skill, and often feels capricious and frustrating to the people involved. If everyone at your company had to re-interview for their current jobs, what percentage would pass? This is a scary question. The answer is almost certainly well under 100%. Candidates are harmed when they are rejected by companies they could have done great work for, and companies are harmed when they can't find the talent they need.
It seems that most (young) recruiters these days rely primarily on Linkedin as a sourcing tool. But that's not where the best talent is found.
The Hack to finding talent is to truly learn the recruiting process. That is to say, can you identify, assess, and ATTRACT decent people on your own?
Start by asking: Who would know know my ideal candidate?
ON this subject, Lou Adler is masterful > https://youtu.be/9KLR6rteoOU
This reminds me of a recent post that rings pretty true: "When hiring senior engineers, you’re not buying, you’re selling"
https://news.ycombinator.com/item?id=18955731
When people question why so many companies start or stay in the Bay Area, "density of talent" inevitably comes up as one of the reasons. I can't reconcile that assertion with this one here.
I'm not challenging you here, but it's common questions I hear that can complement your perspective...
Offer to teach the developer something.
"Java developers - want to learn Node and React?"
"Rails developers - want to learn Elixir?"
Get one senior person on staff who really knows the stack well and require that they pair program every day with a different member of the team.
Good developers are grateful for the opportunity to level up their skills, contribute, and still make a living.
Andres Camacho in SF has been VP of Engineering and CTO at several startups and is king of this strategy.
At least in the above scenario, it was Andres doing the work of initially getting someone up to speed and then pairing the coworkers on an appropriate level feature/bug. He'd stop by and check in to see where they were stuck and would genuinely try and solve the problem.
So, it has to be someone who is a great coder for that stack and enjoys teaching.
If it's done right, other members of the team become good teachers as well, so the initial burden of teaching is lightened.
Pay them well, and give them a regular chunk of (paid) time to work on something that furthers their growth / is intellectually stimulating / whatever.
Could be a great incentive, but not to me personally. I'm very invested in the JVM, and I'd rather have that investment used. Something like the following would make me jump ship instantly:
"Java developers - want to use Flink/Spark, some Scala/Clojure? How about 'very fast decision trees' learned online out of a Kafka bus?"
Hiring a good product owner would've meant retaining the team. Now you have to have to find six new developers.
A big aspect to this is that the equity lottery of startups is largely gone because companies going public is increasingly rare, companies stay private longer (which presents real problems for the liquidity of employee options) and there are just so many ways an employee can get screwed out of their equity value that as the time a startup is private increases the value of the equity inevitably approaches zero. Down rounds, liquidity preferences, that sort of thing.
Equity is a pretty terrible deal for employees. Great for VCs. Great for founders (mostly). Horrible for employees.
That sounds kind of extreme, but I think you are on to something. Facebook can generate more incremental revenue per unit developer than company X. It's not that company X is just being cheap offering less and the solution isn't as simple as "raise salaries".
This two-tier system of compensation isn't just a matter of non-FAANG companies being too stingy. Its a matter of economics and business models.
I'm still waiting for somebody to try offering humane working conditions (like, not in an open airplane hangar where you can hear everybody else's conversations echoing throughout the room) as a perk. Been waiting for a long time.
bullshit. we are looking for talent as hard as we can and we pay premium rates compared to market.
90% of the people that enters the door can't code a for loop. a lot of the candidates, especially those on the younger side, have terrible work ethics, like they find hard to work in a team or under direction and to follow instructions; they won't listen to anything and they'reso set into their own way of doing things they will dismantle working software even after being directed precisely to where and how to implement/fix stuff. and it doesn't stop in the work are either, we got one that tried watching cartoons off a pirate streaming site.
there's a huge shortage of people with brain, agency and will that can fill a 10x position, leaving company that don't do the umpteen iteration of the average vertical tiered enterprisey app short and longing for employees.
It's possible to find no developers in small cities and rural areas, where there are usually no developers and no companies. Having issues with work ethics is something else entirely though.
I live near London and get calls from recruiters on a regular basis telling me my CV is literally amazing and they have these awesome opportunities paying half of what I'm currently on.
Went for a coffee with a couple of them and they're telling me they have positions open for a year because neither the clients nor the staff will budge.
This is the contract market, and this includes both companies looking for experts with experience and just bums on seats in a team although, this is usually working for non-experts team leads.
I'm not whining, like I said, I have work. It's just interesting that the client side market hardcore trying to halt at £800 per day.
Or train!
It amazes me when places want PhD-level employees, but also insist on them having very specific experience. The one thing that a PhD indicates is the ability to quickly get oneself up to speed in an area.
It's flattering to hear from someone who is genuinely interested in hiring me - if you're interested in _me_, I might consider you even if I wasn't planning on leaving where I'm at.
Admittedly, it's time-consuming. But it's also "doing things that don't scale".
I think a lot of this is based on they myth of: A bad hire causes tons more damage than not hiring a good person.
I call BS. To me this is just weak management. It's actually not that difficult to fire someone. If you're in doubt, put an explicit probation period in the contract. I think being able to effectively fire is management 101 but looks like it's becoming a lost art. I'm not sure if this is because people are afraid of confrontation or they're just cargo culting the story they've heard about bad hires.
Easy in, easy out and you'll see your dev shortage problem start to solve itself.
I think it is true, but only if you don't identify it quickly and/or don't reassign or fire them as necessary. I'm a firm believer of a holistic and lightweight interview process followed by a trial period. The only way to really understand if someone will work well in the position is to let them give it a try.
It has little to do with confrontation, and a hell of a lot to do with potential legal issues. Maybe this fear is unfounded, but I doubt it.
If you are a small company, you might get away with it on pure luck. If you are a big company, you can average out the cost of "bad firings" with the rest, and see how expensive it is. I'm guessing it's a lot.
The salaries that are offered are a joke in London. The expenses are so huge there! Even if the salary is a bit higher than my current one, I would spend much more.
There are a lot of joke startups, some new cryptocurrency or blockchain startups... Nope, I'm not gonna join anything like that.
Also, I'm not a huge fan of big cities and London is too crowded (for me).
Allow remote and I'm sure you are gonna find someone.
there's a huge tech talent shortage in Prague, which has approximately 1000x higher quality of life than the bay area. You can make a high salary here and live extremely well. Bonus: no human feces on your front doorstep!
And as a developer in NYC, I'd say this is accurate, but simplifies the problem a bit too much.
Companies like their salary bands. Companies like to hire people at around the same compensation as current employees in the same role with around the same experience.
The problem is that demand has recently gone up and pay should go up with it, but companies are refusing to adjust their bands and greatly increase pay for their current employees across the board.
So, instead of addressing the pay issue head on, we're seeing a few really really bad practices:
- Lose candidates at the offer stage
- Giving pay increases to current employees only when they have other offers or explicitly ask for it- Giving regular title bumps to justify pay increases
If these points sound obvious, they're not. As a candidate, I have not seen a single company that follows them.And this post just addresses issues around compensation. I haven't even begun to touch on being honest around your interview process. But let me put a few questions out there as well:
- How many rounds do you have?
- What is your accept rate at each round? - For testing candidatesYou can also, as many companies default to, ration yourself by imposing very grueling hiring requirements (months of fly-in interviews and hours-long take-home assignments) and "competitive" (as determined by some non-market mechanism like an industry survey) pay. The result of the latter will be long hiring times for good-enough talent that is willing to work for whatever you've pre-determined to be fair.
It's really no different from looking for a car: you can have a known high-quality thing right now (buy new from a dealer/pay $$$ for top talent), or you can buy a lot of potential lemons for cheaper until one happens to last (grabbing random by-owner cars from Craigslist/hire-fast-fire-fast), or you can just wait things out until you find the perfect deal (trawl Craigslist a couple times a week until something jumps out as an incredible deal/pay "market" rates and have a long hiring process).
There are tradeoffs to be made, and you have to make them according to what you actually need and the resources you have. There's no physical law that says you're entitled to unlimited world-class talent at bargain rates to build your adtech startup.
Then been turned down as they are "going with other candidates", only to see the job reposted. This has happened on multiple occasions.
Maybe I wasn't the right person for the role. One specific role has now been up for 5 months. Which likely means the company is looking for an unrealistic set of requirements that no one can meet instead of training appropriately.
In my opinion, the person that will come in and solve all your problems without training does not exist. Make a decision and be okay with letting a new employee get familiar with your company and industry.
1- Gather information from candidates about how other companies are doing the same job or about their strategies
2- Go deeper into discussion with candidates who work for a competitor.
3- Look to be hiring for investors/competitors..etc
Find a random research university near you. It is chock-a-block full of people, most of whom are very smart and many of whom can code. Since everyone other than tenured profs has a precarious, low-paying job, this should be a fairly easy pool to recruit from.
Nevertheless, I, a staff scientist in a computational field, get messages from (maybe) 3-4 recruiters a year, all of whom are from huge companies. It would be good to hear from more places and it would great to hear from places that are willing to consider my actual experience (look at my code, hear about my data analysis) instead of asking me to dredge up half-remembered tricks from my undergrad data structures class.
I’ve had several jobs from startups to big companies and I have never been utilized at anything close to 100% of my potential.
Try getting rid of pointless meetings, distracting open offices, insane IT policies, and needlessly overcomplicated architectures. You may not even need to hire any more enigineers if the ones you have are more productive.
Everyone wants to hire the 10xer. The problem is that they're a) expensive, b) not always easy to work with, c) usually already employed.
If companies stopped focusing on getting the "best of the best" to produce results overnight, and instead spent energy in investing in young/less experienced candidates, things would be a lot easier for everyone. Of course, this means that companies need to come up with ways to retain talent so they don't "waste they time" on developing someones career to just have them poached.
I find it funny how posts like these alternate between "why can' I find a job?" and "why can't we hire anyone?". Obviously there's a disconnect somewhere. There is absolutely no shortage of talent, it's just mismanaged expectations (on both ends).