Live data from Hacker News

Why is recruiting developers so difficult?

polyfill.work

71–80 of 233 posts

Re: Why is recruiting developers so difficult?

#71
post #8

Personally, I've never found it difficult. Have 1-2 interviews with a take home or in person coding exercise or however they want to prove to me they can actually code. Pay high, have great benefits, high equity, treat your employees well, and fire those that don't perform up to expectations quickly. It's really not hard to spot talent. Don't make them jump through hoops. If they are talented and get along with your…

> fire those that don't perform up to expectations quickly

What's the compensation for that risk? "We'll fire you in six weeks if you don't work out, so please leave your current job where you're well established and have about a 0.5% chance of getting fired this year."

Something like guaranteed six months severance, or a $100K reporting to work bonus with no clawbacks.

At the C-level, these kinds of guarantees happen all the time.

Re: Why is recruiting developers so difficult?

#72
post #7
post #2

Because you make it a complete nightmare. I'd rather wait in line at the DMV all day than go through a typical 6hr tech interview. Hire me based on my resume and a phone call, give me a task, and if it's good enough keep me. Problem solved.

I agree in principle, but not in experience. I've interviewed a few people lately, Senior Eng somehow, who have impressive resumes. I ask basic coding tasks just to make sure they actually know the language claimed - just something like converting numbers to strings, and you'd be amazed how many people had no idea where to start.

My team once needed to hire someone from the outside. I posted a C++ job saying we expect people to know C++11 and to be comfortable working with a C++20 codebase

Literally more than half the applicants couldn't figure out how to update/install clang/gcc to compile our test. It wasn't timed or anything it was essentially change the lambda so it's by reference instead of by value (or the other way around idr) and send us back the one or two line change

Re: Why is recruiting developers so difficult?

#73
post #49
post #35

Earlier quoted context omitted.

Take homes are one of the single biggest turnoffs for experienced talent in interview processes. People don't want to do them. Especially good devs who can land a job anywhere. > Don't make them jump through hoops The take homes are the hoops.

That's why I try to make take homes fun. I like the elevator problem in Python. Try to make elevator software that passes the unit tests. Sounds simple, right? Wrong. Very hard. I don't really care how successful you are. I want to see how readable and maintainable your code is. Sometimes I just ask for example projects that I can read. But I do need to know you can, you know, actually do the job. I personally find i…

It's not about if the take homes are fun or not. Far too many companies have varied take home tests that can take an hour or a 40-hour work week only to be ghosted after submission. I don't partake in any asymmetric interview processes, and many places are happy to let me skip it. I'm happy to sit on a zoom call with one of your engineers for a couple of hours and do whatever they want me code in that time. I'm just not into doing it on my own time with no cost to the interviewer.

Re: Why is recruiting developers so difficult?

#74

I'm a developer and a recruiter. Here are some thing I know: many companies - maybe most companies - are very slow. I cannot tell you how many times I have sent a great candidate to an employer, to hear in 2 weeks that they would like to interview them, despite my pestering them the whole time for feedback. You know what they say then? "Oh well, who else have you got?". They don't care. the companies I work with who…

I'm in the finance industry and I often have had to push back on how fast companies want to move because I have like life happening. You can go from looking at a job posting to having an offer easily in under 5 days in this industry.

Re: Why is recruiting developers so difficult?

#75
post #54

Earlier quoted context omitted.

Good approach but can't imagine doing a take home unless it was paid.

If the person requests it, we pay for interview time as long as the hourly is reasonable. Not a problem. The real question I have for you is, how would you prefer to prove to me you can actually do the job? In person coding exercise? Isn't that more stressful?

How long do your take home exercises take?

I've always conducted interviews where I've given system design questions, and data modelling questions. Never found that coding exercises give good enough signal to justify the time investment on either side. If you want to catch someone in lie, i.e. they can't code at all, just give them something of fizzbuzz-level difficulty as a basic filter.

Re: Why is recruiting developers so difficult?

#76
post #6

1) Because recruiters don't understand the subject material. 2) Because companies are hilariously risk adverse. I have over a decade experience in a consultancy environments (faster paced and more rigorous than a lot of other jobs, sorry not sorry). My work was independently driven and I provided input to the projects I was on at the highest levels. I've set IT and SWE policy for and introduced leading products at mo…

When was the last time you interviewed, and how do you feel about remote work? I interviewed a lot the last couple years, from the Midwest, and had more remote opportunities than I could handle. I'm not interviewing with FAANG though; almost entirely private companies, seed to E.

I am in the Midwest and have interviewed at a handful of places (including FAANG) over the last year and recently accepted an offer (non-FAANG).

Re: Why is recruiting developers so difficult?

#77
post #8

Personally, I've never found it difficult. Have 1-2 interviews with a take home or in person coding exercise or however they want to prove to me they can actually code. Pay high, have great benefits, high equity, treat your employees well, and fire those that don't perform up to expectations quickly. It's really not hard to spot talent. Don't make them jump through hoops. If they are talented and get along with your…

It's not hard to recruit good developers. It's hard to recruit good developers without paying premium. Pay $1 billion/month and you'll recruit anyone. This is ad absurdum, but you've got idea. If you can pay high, of course it's easy to hire talented developers.

I don't believe in paying good developers less than they are worth. I'm a CTO. I'm the developers evangelist inside my company. Their success is my success. Their happiness drives my KPIs. I'm not interested in saving a few bucks. I'm interested in getting the best talent I can. I have gone to the mat to fight for people's salary increases and asks many times and won. And it's always paid off (why I don't even have to ask permission for making high offers anymore). Good developers are usually worth significantly more than what they think they are and what they are happy to get paid.

Re: Why is recruiting developers so difficult?

#78
post #35
post #8

Personally, I've never found it difficult. Have 1-2 interviews with a take home or in person coding exercise or however they want to prove to me they can actually code. Pay high, have great benefits, high equity, treat your employees well, and fire those that don't perform up to expectations quickly. It's really not hard to spot talent. Don't make them jump through hoops. If they are talented and get along with your…

Take homes are one of the single biggest turnoffs for experienced talent in interview processes. People don't want to do them. Especially good devs who can land a job anywhere. > Don't make them jump through hoops The take homes are the hoops.

My experience is that, whether it be via interview, take-home, or whiteboard test, what employers are looking for, is $buzzwordDuJour.

I may be being generous. I am noticeably “older,” so it may have simply been bald-faced ageism, in my case. Maybe younger folks would have been given more latitude.

I remember getting a take-home, once, where they asked me to write an iOS app that leveraged a specific library. They did not provide a template. They simply sent me an email with a fairly vague spec (I'm fine with that). They also wanted me to use a specific $methodologyDuJour, that would have resulted in needlessly complex, underperformant, and buggy code.

At the time they gave it to me, I had a pretty serious personal family emergency, so I did the app, using the industry-standard method. I wrote a full-quality, localizable, documented app, in less than four hours. While my house was trying to burn down, so there was a bit of extra stress.

Oh, and also, I had never worked with the library they wanted me to use, so I had to learn the API.

So, I wrote a full native Swift iOS app, from scratch, learned a commercial API, integrated it, tested the app, documented it, and delivered an App Store ship-ready iOS app, with very high-Quality code, in about four hours, while under serious personal stress. I did let them know that I had had to deal with a "personal emergency," so the test was a bit "rushed."

They ghosted me hard after that. I was actually shocked at how discourteous they were, as everything before that, was great.

Re: Why is recruiting developers so difficult?

#79
It is also difficult, because software development skills are not easily checked and have a lot to do with creativity as well. Furthermore most people have no idea how developers work all day and what they do. Only developer-close roles have an idea. Companies are very picky as well, imposing lots of tests upon a candidate, which you wouldn't see for another kind of role.

Re: Why is recruiting developers so difficult?

#80
post #7

Earlier quoted context omitted.

I agree in principle, but not in experience. I've interviewed a few people lately, Senior Eng somehow, who have impressive resumes. I ask basic coding tasks just to make sure they actually know the language claimed - just something like converting numbers to strings, and you'd be amazed how many people had no idea where to start.

> just something like converting numbers to strings Isn't that the kind of thing that someone senior would typically look up? Do you think that whether or not they have that part of the language API stored in their working memory is a good predictor of their ability to do a good job as a senior eng?

We allow them to use Godoc, of course. That said

> Isn't that the kind of thing that someone senior would typically look up?

Not at all. There's at least two ways to do this very easily in Go(one line, no errors to worry about even), and I'd expect someone who claims to use it daily to know one of them offhand.

While I think languages are just tools, in our instance we're very clear we need people versed and ready to start.

I don't think people are dumb here, I think they just blatantly lie on their resumes.

Post reply on HN