Why is recruiting developers so difficult?
polyfill.work
polyfill.work
I don't think HR and software recruiting has really caught up to the reality that many developers by their mid-30's are sitting on a million+ in assets and good ones can rake in 200K+ easy. Further we usually find equilibrium with our roles wherever we are even if we have gripes with how things are because most devs are pragmatic people that realize everything is awful everywhere and perfection is unattainable.
Offer me more money, more PTO (fuck your unlimited time off garbage), lunch and club budgets etc and I'll be more interested. Four day work week? Yea, that will get my attention.
Oh and there's the other problem that your company is probably not competitive with Microsoft + FAANG and the handful of unicorns in the compensation arena. Either you're private and have no stock to offer, or your stock is flat-lined, or you don't hand enough of it out. Nor is your product interesting enough to work on.
Changing jobs is a pain in the ass. Most of us have stable jobs, good report with our coworkers and managers, deliver stuff on time, and get paid well... You're going to have to compensate me better than +10% on whatever I am currently making to get me to switch jobs.
L7 salaries are 300k base and around 400k equity in the US, so hiring experienced/accomplished developers is intensely difficult for companies outside of the top tier with high margins or startups with potential exits.
Sorry, but this isn’t “living out the rest of my days with” money, this is a top 5-1% pay range you’ve just suggested. I don’t necessarily disagree with your point but anyone who needs a $500K salary clearly is not financially independent
Mind you, I'm not including housing. Housing in Vancouver in Toronto require I make more than $200k/yr which further solidifies the fact that Vancouver and Toronto are owned by the wealthy elite. I am not the wealthy elite.
Our social healthcare has us covered in old age. I can live off $30k-40k/yr once retired. That's a 4% withdrawal rate off a 7% globally diversified ETF of $1m.
This is similar to why London real estate is off the charts expensive for the people who live there... this still happens in the US, but it seems like a smaller deal relative to the size of the economy and banking regulations around things like proving source of income are a tad stricter.
The silver lining here is remote work. Both Vancouver and Toronto are in dire need of a physical brain drain. Allow remote workers to work from across Canada. The demand for in-city workers will lower and home prices will fall
Or were you the one that made all that money and the only one who could do it?
The article is about how hard it is to recruit developers, so presumably they are in fact at least a little bit special because they know software.
Of course not. But the market says otherwise. My partner literally saves people's lives on a daily basis and is lucky if she can earn a 1/4 of what I can. I console myself that at least my taxes pay for her salary.
[1] https://www.levels.fyi/comp.html?track=Software%20Engineer&s...
I'm yet to see one or hear from a friend who works in one. I admit there might exist one somewhere, but by and large, they don't. Unlimited PTO = culture of overworking, at least for me. And small companies with unlimited PTO, 3-5 engineer teams (and some other staff, obviously) seem to be the worst offenders. The bigger the company, the higher the chance unlimited PTO might actually work.
That being said, I'd love if someone can teach me how to tell them apart.
1. Some people take more and some people take less, and that's fine. Not everyone has the same life circumstances.
2. If you set an allotment, you should track it. Why waste time counting calendar days against a PTO budget if nobody cares? If you start tracking towards a limit that people don't actually care about, then you create opportunities for people to be treated unfairly, or you demonstrate that your organizations rules aren't actually worth following.
A few months into the pandemic, my manager sent me a message saying that he was worried I wasn’t taking enough PTO, and suggested I do a 3- or 4-day weekend in the next couple of weeks, even if I wasn’t going anywhere. This happened to a few other coworkers, too.
It can be a trap, but it isn’t always. And this isn’t some little startup - 15k employees.
As an anecdote, I've worked at a startup with unlimited PTO where the culture was that most folks were working 45-55 hour weeks regularly, but everyone took vacation whenever they felt they needed it. I averaged ~5 weeks of vacation per year taken during my tenure there. That was probably about par for the course with that team. As long as you're performing well while you are working, give enough advanced notice, and willing to be somewhat flexible (eg don't take 2 weeks vacation right before a big deadline with 2 days notice) - it can work out quite well for all parties.
I'd rather work at an unlimited PTO company with reasonable people than one with a generous allowance where people are always scheming to use it as a weapon.
If the workplace culture isn't such that it is clear what abuse of the policy is, then yeah, it's not going to work out. Expectations have to be clear.
What !!!
Edit: I did return to tone down my reaction but I would be interested in any (evidence based) research on the pay scales in and out of SV. I understand it is only the very top tech (FAANG) that pay so highly and mostly though share options.
It's not like that in Europe I am afraid.
But even so, if that's your position by 35, well done you.
$200k (TC) is not that high in London for an engineer with 10 years experience
I would be surprised to see someone whose job is coding getting that.
There may be crypto paying silly amounts or lucky start ups.
Either that or I need to brush up my CV
See how easy it is to just lie on the internet? :P
200k USD -> 160K GBP is the point
look for developers working at trading firms
It's not SV, it's the US. 200k is easily achievable for a senior engineer anywhere in the US with the rise in wfh.
But what percent of software engineering jobs are in the US? It's not really a bubble if it's the majority of software positions.
Reminds me of Dijkstra's "On the fact that the Atlantic Ocean has two sides" followed by Alan Kay's rebuttal "On the fact that most software is written on one side of the Atlantic Ocean."
Sure developers in the EU get paid less, developers in Mobile Alabama working locally also probably get paid less, but most developers aren't in these areas.
I also know plenty of EU citizens working for US companies making 200k+ remotely, so it's not like these positions are closed off from people residing in the EU.
Even Dijkstra eventually ended up at UT Austin.
There is no reality where most engineers expect to be paid 200K+. I really don't understand technical people perpetuating this idea when you can find data pretty much anywhere that indicates otherwise. There is just no reason to inflate this number.
I also made that much last year by working remotely for a Canadian company via a.team.
I know more examples of people working for Facebook in Germany and remotely for an Israeli company making over €300k.
Also if they are calling themselves modern and don't offer 100% home office, scrap that.
Same applies if there is any mention of code golf, or me being great at things that aren't even part of my CV.
Naturally when unemployed, one doesn't get to be as picky, but thankfully that hasn't been the case.
Also, tailor your job listings to tell them what they get out of the job. Don't list what you need. You're just culling potential applicants. Most talented developers can adapt to a new language or dev environment quickly. You don't need someone who already knows X, Y, Z and 20 other things. Attract people to your company, don't make a list of needs. Get them excited to work for you. And put your high salary range in the listing.
Every time I do this, I'm inundated with resumes from top quality applicants and can pick and choose the best fit. I've hired over 100 developers this way, almost all of which worked out great.
People just go about the whole process wrong. Make the job and company attractive to work for and talent will come to you.
> fire those that don't perform up to expectations quickly.
This attitude is why I haven't been recruited. I have 10 years at big tech and companies expect me to jump ship with the threat of getting fired if I don't immediately live up to expectations (even if I'm confident that I will, but I'll never know how high your expectations are until it's too late). Add on wild take home assignments on top of my full time job and (typically) less pay than big tech.
It's simply not worth the trouble.
Most companies pile work upon their best performers. I'm the opposite. I reward our best performers by giving them back their time. Expectations differ some depending upon compensation, but really as long as you get your reasonable expectations done, I'm happy, you're happy, management is happy. It's never been an issue.
Citation/sources wanted. That was my expectation with a 'salary' job; being paid to get the work done. Work is done under 40hr, congrats go home! Work takes longer than 40hr, oh well. In my experience though, in _every single_ company punishes efficiency and hard work, with more work. You're done in 20h? CONGRATS, you get Bob's work now too! Make sure to get his and your work done! Leaving early is absolutely not heard of.
If you read Drive by Daniel Pink, you'll learn that the things that unlock higher performance are Mastery, Autonomy, and Purpose. That's what we strive to give to our employees, including autonomy over their own time and how they get their work done.
If I ever feel like writing a book (fat chance), I'll try to spread the gospel.
Quality expectations make a lot of sense, but “on time” is famously hard in software. How do you decide whether the developer was slow or the deadline was unrealistic? And similarly, how do you protect developers from feeling that they have to throw out work-life balance to hit deadlines/sprints that turn out to be unrealistic?
I also try to fire fast and every single time the issue is that they do not actually have the skills they listed on their resume.
That's why the coding test and that's why you need to fire fast.
I have all kinds of patience for good people that need ramp up time.
Plenty of companies assign people badly and then act all surprised that they don't have a Plug Compatible Interchangeable Engineer. https://kidneybone.com/c2/wiki/PlugCompatibleInterchangeable...
Yep. My latest hire started a few weeks ago and I had a back log of pretty simple tasks that were well within their wheelhouse and a dedicated mentor to help bring them up to speed.
I've been on the receiving end of gruelling "sink or swim" initiations that were called "onboarding"
There's no wiggle room on a take-home. The code you write either does the thing or it doesn't. If you don't remember the exact way to do something in an in-person interview, you can express your general understanding to the interviewer and probably get some/all the credit of actually knowing it.
Sure, depends how much you want the job and what your general approach is. If it's a competitive job then you want to optimize for the interviews. Last time I interviewed, the potential impact on my income and net worth over the next decade was significant, so I took it pretty seriously.
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?
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.
We don't give out dumb, tedious quizzes or anything. These are actual projects written to be fun. We don't get many/any complaints.
We also give out the coding test very late in the interview cycle. I'd say we hire 80% of the people we give tests to. We already have a pretty good idea you'll be a good fit by that point. So we're not wasting your time.
Personally I'd probably do some sort of FizzBuzz/LC easy type low filter and then a fast (i.e. no compiled langs) take home in an area adjacent to the job description paid at said job's rate with a time expectation so you don't end up getting billed 20hrs for a Node RESTful API.
We usually give various challenges as take homes which people find fun and engaging, projects that I myself have spent hours or even days trying to solve in my spare time. We want them to be fun. We rarely get complaints.
We're happy to accomodate if you'd rather do it in person or over zoom. It's really up to the applicant.
Guess I'm prob the odd one out here -- unless the job was incredible (like pair programming with J Carmack) I wouldn't be able to commit to any meaningful unpaid take home as I can spend that time programming for profit rather than solving challenges for a company that may or may not work out.
For a coding eval like that to be useful beyond jr level it'd need to be decently complex which usually takes a while to develop. Maybe an open ended (upfront no expectation of completion) kinda "see how far you can get in 1hr on this complex thing" could be a fair middle ground as laying some good groundwork is a pretty solid insight into their coding process.
We ask you to see how far you can get in an hour and then review your code. We're looking for how you approach the problem and if you can write readable, maintainable code. You can learn a lot from how someone approaches this. We've seen dozens of different approaches, and in fact learned a lot ourselves from the different answers. Some are incredibly impressive. Some are just a bunch of if statements that lead nowhere. It's a great way of separating wheat from chaff quickly.
edit: The flask API was an interview I took, not one I gave. I considered it a very poor take home since it was ridiculously simple and didn't prove any actual skill, but as I said, less than 40% of their applicants were able to pass even such a simple question. They had very poor screening processes. It was also step 2 in their interview process right after a screening call and they spammed it to hundreds of people while our coding exercise is our final step after we've screened you past several people and had several hours to get to know you and are already pretty sure you're a good fit.
Many of us have a real life, and enough offers to chose from.
Quite frankly, relying upon such things is a sure-fire way to make sure some bad developers get through the cracks.
Sorry.
We pay top 1% of market. We work to have a low stress environment. We put life before work instead of work before life. We prioritize having the best benefits on the market, including platinum health care with $0 employee contribution and full mental health coverage for therapy and medication not covered through insurance. We don't overload our top performers by giving them more work when they overperform but instead let them take the extra time off. We give everyone when they join a private office and an unlimited budget to buy tech and decorate it to their heart's desire. We don't have required hours in the office or even require that people come to the office at all. Most people do though since they enjoy their nicely decorated private offices with multiple high end monitors and tricked out desktops.
Which part of that makes us a terrible employer? That we ask people for an hour of their time to do a coding exercise? Is that how your judge if an employer is good or bad?
I see you went back through a lot of responses and edited them. Why is that?
Ouch. I knew I saw red flags in your original post. This seals the deal.
All of these are policies I've worked hard to implement to create the absolute best environment in the world for my engineers to thrive. I've had to fight for them since they aren't cheap. It hurts me when someone says taking an hour out of their week to do a coding interview isn't worth it when I've taken dozens to hundreds out of mine to make their job as easy and enjoyable when they get accepted into our culture. It's insulting to me to say that asking for an hour of your time is not worth everything above and much more that I've strived for to make our company a fantastic place to work at.
So, like I said, what red flags did you see exactly?
1. Mentioning firing in the very first post when talking about hiring.
2. Take home interview tests, showing you don't value your potential employee's time.
3. And this is an interesting one: accusing someone of having a poor work ethic when you don't know them and they didn't show any sign of it. This is a big red flag because it points to you equating disagreements with performance, which makes #1 even more of a red flag.
Maybe you just haven't hired or worked with someone who can't code yet.
It's not the liars that are being filtered out (they're easy to detect), but its those who genuinely believe they are good developers.
I've at least gotten rid of l33tcode, 8 hour technical interviews, whiteboard BS, in-person high-pressure timed coding exercises, brain teasers, etc.. All the worst stuff. I thought that was good enough. Apparently asking for an hour of someone's time to get a great job is too much these days.
This is what a ton of candidates end up doing, knowing that others are going to as well. Especially when the take home test could be sent to a massive number of people.
Spend a few hours with me and watch me code. Show you care. I'm not rejecting the idea of spending time coding for an interview.
2. If employees don't think an hour of their time is worth it to work for us, then they are clearly not a fit. Those people obviously don't value working for us. We have the easiest, fastest, most painless interview process of any company I have ever worked at, by design. We don't do whiteboard questions, we don't do 8 hour multi-person tech review days, we don't ask odd l33tcode questions or brain teasers, we don't make you wait weeks to hear back from us, we never ghost anyone, and we usually give a decision within 72 hours. Asking an hour to prove you can code seems perfectly reasonable given most companies ask for significantly more of your time. Every employer I've worked at before took up 2-5x as much time interviewing as we do. If that hour is what is preventing you from working for us, go work somewhere else as it tells me a lot about you and how much you'll value working for us.
3. I apologize for that. It was uncalled for.
They had a take home. Ridiculously simple. Build a 4 endpoint CRUD API for bear sightings. Took about 20 minutes in Python Flask. Sent it in, immediately moved to the next round which was two weeks away.
You know what I did in those two weeks? I rebuilt the same API in Node, Typescript, Rust, Go, C++, Ruby, Django, Sanic, and I think a few more.
Then I deployed it on App Engine, Lambda, EC2, Google VM, Kubernetes, Elastic Beanstalk, ECS, and my local home dual Xeon server. (while keeping the compute size of all of the cloud offerings as equal as possible)
Then I benchmarked them all. Turns out how you deployed it made little difference but the language made a huge difference. Sanic came in 2nd place while Rust was far and away the winner.
Then I wrote a 10 page report including my methods, code, charts, and tables showing the results.
Two weeks later when I arrived at my onsite interview, I was scheduled to meet with 8 people for 8 hours to talk BS l33tcode questions. You know what I did? Explained what I had spent my time doing. They loved it.
I got a very nice offer that day and worked there for 3 years.
Sometimes the amount of effort you show a company how much you want to work there is what can land you the job.
I didn't ask to be paid for that time and I was employed elsewhere. I did this in the evenings and weekends during what would otherwise be social media downtime.....and it was fun. I explored new technologies, learned several new languages, and expanded my abilities as a developer. I don't regret that time investment one bit.
And you're saying you can't take one hour to do a take home?
That DOES tell me a lot about you.
edit: To be clear, this didn't take away from any of my other activities. I still ate out, spent time with friends, went out, etc.. This just took away from useless social media time and turned it into something productive. I also had a lot of fun not only exploring everything but also knowing I'd have a lock on a well compensated position and be in control of my interviews instead of their potentially being disinterested in just another candidate. It was time very well spent. I don't nearly expect this kind of investment from any of our applicants but if someone demonstrated they wanted to work for me that much you'd bet I'd hire them.
edit 2: I was also told later that numerous applicants struggled with this take home assignment despite it being literal CS 101 level stuff. That's why getting a sense of it someone can code is so important.
When you commit your time and set actual deadlines (such as 1 hour), they don't think they need to write a multi-elevator system with floor input outside the elevator and account for load and time of day or write it in 8 languages and write a 10 page report on the whole thing. They just spend an hour with me and we go through the problem and see how far we get.
You could be spamming that question out to hundreds applicants for all I know. Show you care and spend the time with me. I get several interview requests per day, I'm not wasting my time unless I think a company respects me. I'm in a nice position where I don't need to show I can be exploited by doing a ton of unpaid overtime work.
We're also willing to do zoom pair programming, in person coding exercises, etc.. We let our candidates decide. They overwhelmingly decide take homes. Not sure why you specifically are so against it but that has not been our experience. We want a pleasant experience for our interviewers and frequently bend over backwards for talented individuals to accommodate however they'd like to demonstrate their skills. We don't expect a lot of work (almost never more than an hour), just enough to show your abilities, with our focus being on problem solving and writing maintainable code. We just want to know you can perform up to what your resume says you can since so many resumes are works of fiction.
We also only give coding exercises as the final step in our interviewing process. We do not "spam" it out as we recognize it's asking for a time investment. About 80% pass and get an offer. We do not abuse people's time and respect that it's definitely asking for them to commit to doing a little bit of work.
Again, you seem to be making a lot of assumptions that are potentially true of other companies that do not respect people's time but do not apply to us.
I have never been let down by this rule, either as a candidate or an interviewer. In my experience coding exercises as part of an interview process are a big red flag to me indicating the company is trying to compensate for lack of in-house talent with process or they are trying to replace someone with a certain hard-to-find skillset because they have an immediate fire they are trying to put out. Neither situation is a good one to get into.
Edit: FYI. The OP changed their initial reply from the condescending combative response to that below.
Have you taken any courses or worked with professionals to help you with this?
Just 10 minutes of coding (or attempting to), tells you they can't code. A little longer can tell you roughly how good they are.
Experienced developers who can code have had the misfortune of working with people who couldn't pass this, and may appreciate that the members of their new team can.
Where do you fit?
This is a good process: https://www.youtube.com/watch?v=cfyWvJdsDRI
With our salaries, we have yet to have anyone turn us down when we get to that stage of the interview, but maybe someday it'll happen.
Almost everyone picks take home. Like, over 95%. I'm not sure why people here are complaining about it except that the accounts that are were made 2021+ so maybe it's a generational thing.
> Don't make them jump through hoops
The take homes are the hoops.
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 in person coding significantly more stressful than take homes. So what would you suggest? How do I test someone's ability to code?
Otherwise, I'll do something simple, on a shared screen in the language of their choice.
It shouldn't be hours and hours and, ideally, it's a win/win.
The shared coding screen is definitely the most common method. And the one I've found most folk prefer. There won't ever be a one size fits all solution, but ideally your interview methods are equitable across all candidates, and ones that the majority of candidates are comfortable going through. Disparate processes hurts the former.
It might not actually be their project.
> but ideally your interview methods are equitable across all candidates
My candidates are not competing with each other, the tests do not need to be "equitable" between candidates, just fair for that candidate.
One problem, for instance, with github projects is that it's a fairly privileged position to be able to have significant side projects. So it's not fair to expect a candidate to have a github presence and you would be eliminating people without a lot spare time (single parents is the go to example).
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.
They maybe didn't like that I used classic MVC for the app, because it is ... less than optimal ... to use other patterns, when writing a UIKit app. Of course, it's also possible that they finally brought in a tech manager, who figured out I was old, so...
But I regularly write full apps in record time. My GH repos are full of test harnesses that I toss together in no time at all. Pretty much every test harness is one that many folks would be proud to submit to the App Store. I’ve had over 20 published native apps, over the last ten years (mostly deprecated, these days), so I’m used to regularly shipping (and maintaining) native iOS apps.
I'd suggest that someone that can chock together an app like that, in just a few hours, while under a serious amount of external stress, could be someone worth following up on. BTW: The library was MapBox. I'd never worked with it before. I enjoyed the opportunity to learn about it, as I may use it in the future (offline maps, and it's a pretty decent dependency).
But that was about three years ago, and I'm actually really glad that I got chased out of the rat race. It just took me a while to appreciate it.
We can see the opposite in Amazon where they successfully built a reputation as a terrible place to work with low pay relative to its peers, and now struggle to attract talents.
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.
What's the assurance for the person you are recruiting?
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 succeed in recruiting people get the entire process wrapped up within 2 to 3 days, from the moment the resume arrives in their email server, to signature on paper, candidate off the job market. When companies lament "Oh it's so hard to find people!", that's who they are competing with - a 3 day turnaround.
many companies don't even know what makes a great developer - can't define a great developer
many companies have abysmal processes for assessing people
many companies value the wrong things in potential people
many companies pay less than market rates
don't get me started on coding tests.
but ALL companies think that none of the above apply to them. all companies think they are awesome at recruiting and that they run the very best recruiting process possible.
so is it hard to recruit developers? Well yes - but not because there aren't great developers available.
will a new software tool fix it? no.
This. I wish your comment would go to the top.
I interviewed at over 25 places through the past year. Here are my observations:
More than half the time the employer knew the work that needed to be performed in the near immediate but had absolutely no idea what they wanted in a developer.
Nobody can define senior. At some places they were expecting a senior developer who could do anything. At other places it was a trend chaser who plays with dozens of tools. At other places it was a framework user placing text on a screen.
Algorithms are where interviewers go when they don’t really want to talk to people. This is a danger zone because the candidate can fail any number of reason, most especially code style and vanity. Worse, many of these algorithms are completely outside of any real world concern better solved with a well formed data structure.
Unfounded assumptions are the standard. Most people writing software professionally have never done anything else professionally, which is a tragic silo. When you’re a hammer everything is a nail tunnel vision mentality is the expectation. In this case the goal, if want to be hired, is to fall into the middle of the bell curve. Don’t be awesome.
Consider that the big tech companies could agree on some kind of standardized test to replace much of the worst of the interviews—but haven't.
Consider that they often make you leetcode even if you've already passed their interviews before, even if you've passed a couple other leetcode-style companies' interviews before, and so on.
Recall that several of the top-paying tech companies got busted illegally colluding to keep salaries down once already.
Conclusion: making developers more reluctant to switch jobs is one of the main purposes of FAANG-type interview processes, and is likely a core part of their current salary-suppression scheme.
"which doesn’t necessarily get me any closer to hiring someone good"
Everyone wants to hire only the best developers. The more developers in the pool of candidates the more picky we become. Everyone has 2 years of Java in the candidate pool? We only want the best.. you need to have 3 years. If everyone had 5 years you need to have 7 years to be considered the best. Meanwhile any average developer in the candidate pool would work out fine.
Trying to find the perfect candidate vs the average candidate is the self imposed struggle employers give themselves. The need to hire the best gets harder the bigger the pool for all.
One way that works well is for companies to try using techniques of college recruiting, because the level of commitment has parallels: a one-time high-stakes multi-year decision, that involves many new people, new schedules, and new learning.
The getting-to-know-you approach leads directly to teams making smarter choices overall, such as publishing interesting sections of their own codebase, writing about challenging areas of their own workflows, and so forth.
When the teams directly show people the real work and the real organization, then the recruiting experience can become more like a college campus tour-- the developer gains a better understanding of what's involved, and where the learning and growth opportunities are, and why it's worthwhile to apply.
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 more than one company.
The CircleCI chart from yesterday was interesting. I was doing principal work under every column except maybe one. I've plenty of stuff to talk about to put any doubts to rest. But... no bites. In my case I suspect the issue is/was, as related to me years ago by some other HN poster, that I was in the Midwest and people are biased against Midwesterners for reasons more than just relocation costs.
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 wasn't hyper focused on FAANG. I did actually get a FAANG interview, didn't go anywhere. I mostly just don't get interviews.
It's just a hard problem period.
1. FizzBuzz, quick and easy for anyone who can actually code. Honestly #2 is about as good, but this is quicker, so I put it first.
2. A code review - this is something most jobs will actually entail. Coming at some bit of code or a PR cold is something you'll do on the job. Spotting problems is something you will really need to do. It's not quite coding, but I'm going to google half the things I need to do, tweak someone else's working code and move on. To quote my favorite manager, "I love lazy programmers, they're the best!"
3. Pair programming to improve some already or nearly working code. This isn't too bad lets you feel out if you can work with the other person too. Writing whole algorithms from scratch is something that I'd google first anyway, so testing on that is silly.
3. Take home coding challenge - Awful and wildly burdensome. Can be a big time expenditure as they're often not trivial.
4. Live coding in a browser - Awful! Nobody actually works like this. So you're not testing for reality at all really. And having someone watch over your shoulder as you code can bring even the best and the brightest down to "can't write an if statement". Wild amounts of false negatives.
5. Outsourced, proctored, coding exercise. I halt the process at these now. Ridiculous practice.
Using #3-5 is a major red flag to me about the company. They don't know how to hire and/or have industrialized the process so how good can my team be? They already see developers as cogs.
"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."[1]
"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."[2]
[1] https://news.ycombinator.com/item?id=32404256 [2] https://news.ycombinator.com/item?id=32403899
- Refusing to tell me salary range, I stop speaking to them - Them not contacting me after my questions (salary range, vacation days, if I'm expected to do front end, etc) - Them stop contacting me when I say I am not interested in working with technology X Y and Z (usually java and mongodb, sometimes I'll ask if they use PHP then say I rather not touch it, I don't outright say I will never work with it) - They have a non technical person interview me who gets lost and think I'm bad at communicating when I can't see their face and have no idea what part I lost them - They have a technical person interview me who can't accept when I disagree with them
#2 Not giving what the salary range is
#3 Not giving what the total comp range is
#4 Not including benefits and/or not including real benefits.
#5 Not understanding how experience and skills overlap and transfer. Rejecting someone with 10 years of Java experience because you need "Go" experience. Or rejecting someone with 10 years of JavaScript and 5 years of React because they need "Angular"
#6 Ridiculous interview processes. 2-3hr take-home assignment followed by 6 hours of "virtual onsite" interviews are becoming the norm and it's ridiculous.
What gets acceptance? Be transparent, competitive, upfront, honest, lightweight, and READY TO HIRE.
Most of us would not have such a rational aversion to recruiters if there weren't hundreds of them spamming you with bullshit non-offers "Hey, we just saw you switched jobs this year, maybe wanna switch again before you have settled in?" (not making this up, I've had "hey, how's your 6 month probationary period [as is common] been, are you happy where you are now?"
Even writing "NO I DO NOT WANT A NEW JOB" will help avoid them pestering you. Oh, and if only this was a few (lone) people or a few bad apples in the agencies. No.
I also got contacted by recruiter B of company X while we were actively working with their colleague C to recruit people for our company. We were, until that day.
There are also a handful of them, no matter how often I politely reply "go away, I am not interested, never contact me again", after months at most they come back. The platforms make their money from the recruiters, not from the free users, so reporting them also doesn't work.
It's a bit like saying "not all MLM scheme salespeople are bad", well - 90% are.
I wish I was using hyperbole, but I am not. It's not a real problem, so don't mistake my halfhearted rant as some sort of crusade, but the reality is that after 20 years I only know a small handful of recruiters who are decent and not just opportunistic scumbags, and that sucks.
I have been working in the development area since 1999. Starting with Delphi, today I work with Ruby and Python. I've worked with Java and Lisp. And many other areas like security and DevOps. I worked in large companies and startups.
And after 22 years, I can say... the recruitment process is a shit show at ALL companies. It gets humiliating. Some examples:
1. A company offered me an offer after just one interview, ... 1/3 of my current salary. WTF?
2. In another case, in the technical test I emailed, in Rails, the reviewer said "You didn't create a validator and you didn't test 100% of the code" Of course I did the validator... I was offered a new test, but I thought it was a bad sign, so I stopped the process and thanked for the opportunity.
3. In another company, I did "a lot of unit tests" 4. My boss doesn't hire a very good candidate because he uses Visual Studio for the online interview, and it was a sin for him to use an MS IDE.
5. For a specific job, my boss only hired women with deformities (no hand or foot, limp, etc.), as this type of woman does not suffer sexual harassment (of course it is not true).
6. I already took a graphology test for a job!
7. "You called Model.find_by_name, we don't use it here, you need to call Model.find_by name: value"
Some people say "it's normal" about these crazy processes and defend it. They suffer from Stockholm syndrome.
Every time I get an offer on Linkedin, I don't politely accept it as I don't want to go through any crazy process again. And I didn't even mention the work environments...
They do not want to give you a chance to adapt your skills to the position. They will not give you feedback. They will not work with you to clear-up what might be minor misunderstandings. They really do not want to hire anyone.
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'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.
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?
> 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.
By doing that you are wasting a potentially good developper because they didn't happen to remember some languages exact syntax.
It's also just straight up insulting. If someone worked for x years in a related role... do you just assume that they were a fraud at that job, and they just leeched of that companies money?!
And no the question isn't 'convert a number to a string', it's a small function tasked with doing something along those lines.
I don't get why you feel that's insulting. If I were applying for a job speaking French, was asked to translate a simple sentence, and couldn't...I wouldn't expect to be hired. I don't see this much differently.
> And of all the languages I use for daily work I could not 100% tell you what that function is exactly called.
And see, that would be fine. In this example, if one would say 'oh it's in strconv let me look that up' or 'oh can I look up the string formatting symbols' this would be perfectly acceptable, to me.
Writing things like string(i) or i + "x", not so much.
Just hire a few people part time and the one(s) that can deliver offer full time roles.
It's more like hiring for a podiatrist, the candidate claiming to be a podiatrist for 5 years, then not being able to answer what to do for a sprained ankle... because they can just google it.
Also would you really ask a doctor such a (as I already said) insultingly trivial question during an interview?
Yeah, I'd probably google that in any language I've written, including ones I've worked in in the last couple weeks. Even if I thought I knew what to do, and even if I tried it and it seemed to do the right thing, I'd google it (or use in-IDE docs, or similar) because I wouldn't trust that I was entirely correct.
... however, narrow the question and give me some resources ("the input will be a positive, unsigned 32-bit integer; the string should be ascii and use digits, not words, to represent the number; do insert commas every third digit [and we're working exclusively in English, so commas are all we need and you can ignore system locale preferences—one of many subtle ways one might screw this up]; here's a printout of an ascii table for reference") and I can probably do something like what's requested, without the aid of Google. As long as you don't expect the syntax to be completely perfect.
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
For starters, the acronym means "Human RESOURCES" ie, square one, or is about resource extraction, like any mining operation, about exploiting that resource for maximum value at minimum cost, and externalize costs where ever possible.
Alernatively, when actually creative people need assistants, they INSPIRE collaborations, using only the value of their idea.
There's more money in the former than the latter, but as Henry Ford said, "you can make money or you can make sense, the two are mutually exclusive."
Well yeah. C++ developers with 15+ years experience don't want anything to do with go (for good reasons) and you probably can't afford them anyway.
> For example, if I want to hire someone ...
It's just a contrived example to demonstrate the (mostly) poor matching I see at the point of attracting developers.