Why is recruiting developers so difficult?
polyfill.workNumber one reason: You're not offering me enough good reasons to leave my current job.
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.
>>> many developers by their mid-30's are sitting on a million+ in assets and good ones can rake in 200K+ easy.
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.
GP definitely lives in a SV/US bubble. Here in Europe I know devs in high CoL areas having less than a thousand Euros left at the end of the month. Having millions in assets is fantasy for us unless you won some crypto/stock gambles.
Can attest to sv here. "Senior" (ie 2-4 years of experience at fangs or similar sizes) can make TC of around 200-250 including liquid (and quarterly vesting public RSUs) and 10% bonus on a 150ish base.
> SV/US bubble
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.
Median total compensation for a senior software engineer in the US is $138K on glassdoor, and I'd wager even that is a bit inflated.
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.
Glassdoor notoriously undershoots and is off by quite a bit. I’d not use that as a resource at all.
I was talking about the millions in assets part. And 200k for EU citizens is definitely not easily achievable. The median is far far below that.
perfectly doable in London
How exactly?
works for a company that pays its engineers reasonably well?
$200k (TC) is not that high in London for an engineer with 10 years experience
So that's 160k pa total. I'm in London myself
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
I'm in London and I'm on 400k/year.
See how easy it is to just lie on the internet? :P
I was not saying I was on 160k - i would be happy to announce that if true however :/)
200k USD -> 160K GBP is the point
Yeah I know you weren't, I mean just take it with a grain of salt when everyone on the internet seems to be earning 200k in London
all of this is pretty easily verified on somewhere like glassdoor
look for developers working at trading firms
I'm based in Amsterdam and agree with him. There are a few local companies offering that much, including some who post pay ranges on this site.
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.
Don't write off a company just because they have an unlimited PTO policy. Check out the culture first, some actually respect it. Especially in smaller companies, it's sometimes just easier to judge people based on their output rather than the number of days their butt is behind a keyboard.
I worked for a defense contractor that had a truly unlimited vacation policy as long as you were getting your work done. We actually would get formally reprimanded and put on a PIP for not using enough vacation. All benefits started day 1 including 4 months new parental leave (fully paid; STD following birth did not count against the 4 months), unlimited vacation (no questions asked and auto-approved for the first 30 days per year), unlimited sick leave (up to 5-days per incident after which you'd transition to STD up through 12 weeks then LTD at 100%, then 70% of pay until better or moved onto SSDI exceeding the benefit respectively), unlimited jury duty leave at 100% pay (one guy that I knew there spent 4 months on a jury for a complex civil trial), dedicated paid time off to vote in every election (local, state, or federal), and a whole heck of a lot more. Had I not gotten a much better offer from a HFT firm that fully offset the decrease in benefits, I probably would never have left the company because of how amazing the benefits were. I had taken 4 weeks off for my wedding + honeymoon before I quit and my manager was talking to me about how I should still schedule another 3-4 weeks off that fiscal year for vacations at other times.
I'm gonna need the name of this contractor. Hell i'd switch tech stacks for these kinds of benefits. Do they offer Remote? I make about 118k in NJ as an Angular+Python dev and what keeps me from leaving is the "unofficial" remote they offer me + the extremely relaxed working environment(no stress whatsoever). I'm not doing anything cutting edge but at my age (34 still living at home while saving money) I just don't feel like I want to be in any competitive environment anymore. Only worry I have is that I will be SOL once this dries up. I guess I gotta get on those "personal" projects/leetcode practice that I don't really feel like doing.
It was Harris Corporation but I heard the benefits got worse after the merger with L3.
Yuck. Everyone I have known who worked for L3 was a jerk who loved the smell of their own farts. They picked up all of the nastiest colleagues I had in engineering school. I have a very bad impression of this company. Don't they make the 1990s style "secure" phones that the government relies on?
> some actually respect it
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.
I used to work at Workday, who has an “unlimited PTO” policy, and they were fantastic about it.
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.
That's a positive thing to hear and thanks for sharing! What I'm worried is, if 90% of unlimited PTO policies are complete shams (number taken from my informed RNG), how do you tell them apart? You can't afford to start at 10 companies and remain in the 1 that has a good policy... On words, they are all about work-life-balance (they don't tell you the balance is 90% work). And I'm not talking about being ridiculously lazy, I'm talking about employers openly setting expectations that you work at least 5x10-11h as a software engineer and demanding that.
It works as long as you have a culture where people don't abuse it. It's not workable if people think it's acceptable to disappear with some critical information only in their head and screw their coworkers. Document stuff. Set deadlines in advance, and expect people to meet them. Have a team that collaborates and is considerate to their peers. If people do this, nobody is counting how many days they're out.
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.
Therein lies the problem… Define “abuse it.”? If there is such a thing than PTO should be limited to that ;) Dont say it is unlimited and then say that actually is limited…
I did define it... in the rest of my comment.
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.
I think the best way to define what abuse is, is give explicit numbers. Even something like "25 days/year free use PTO, 20 more days to be discussed with your manager" or whatever. I came up with that policy right now, I haven't seen it anywhere, but point is - setting expectations beforehand is much better than just saying "unlimited". For some, unlimited means "20 days if you're lucky", for others it's "up to 40 days we don't bat an eye, if your output is good otherwise". "Unlimited" doesn't convey that. I want to know before I start working. Please convey it.
In the interview process, ask questions like "How many days off did you take last year?" or "How many days off in a year does an average team member take?". If the answer is <= 15, or they bristle at the very mention of the question, there's your answer!
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.
The tech company I currently work for has unlimited PTO. I've never had an issue, even once, when I said I'm going to take XYZ days off and have gotten pushback. It probably happens but I haven't seen it.
You never mention if you took 15-20-25 days per year or let's say 40. I'd say that if you're taking up to 25 days per year, then there's no point in unlimited PTO - that's such a standard number that it's better to just put it there. If you took more than 30, then I'd love to hear specific numbers. Saying that you took 30-40 days in a year and didn't get pushback means a lot more in terms of a good "unlimited PTO policy", assuming you remain otherwise very productive.
I take a "standard" amount of PTO but it still makes sense to have unlimited PTO because:
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.
Yeah, I do have to say every company I've worked for with "unlimited PTO" really means "no PTO and if you take any you will be shamed for it and possibly fired."
The only place I've heard of that went to unlimited that sounded serious about it was a non-profit (non-tech) where the execs said: we going to unlimited PTO, but we are going to enforce PTO minimums if you don't take PTO (you will be taking time off each year, either you will schedule it or the company will). They combined the move with creating some company-wide long weekends that augment already long weekends (eg. add a Friday or Tuesday to the July 4th holiday to make it a 4-day closure).
This comment is intesting. I've experienced unlimited PTO in a couple of big companies and it was amazing. There was never any push back on taking 'reasonable' time off (1-2 weeks at a time) and being able to take off without counting hours was fantastic
Correct. I’ve had unlimited PTO at a few jobs. All of them I’ve taken 5+ weeks off outside of company holidays every year. This is usually better than the 20 days standard you get from some FAANG.
I was at a company with such a policy and I was fired for taking too much time off due to a family emergency.
I don’t do unlimited PTO unless there’s a mandatory minimum time off.
Fully agree, nowadays I just don't bother replying any longer, if they aren't at very least at the same level as what I am having salary + benefits.
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.
By my mid-30s and having started programming at 9 and professionally at 14, 200k is chump change for a salary. That's what they really haven't caught up to.
This is only true for US salaries (and sometimes specifically within Bay Area/Seattle/New York markets)... pretty much everywhere else, salaries are a lot lower.
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.
Definitely only true for US and certain geographical areas, including the one I'm in. All I'm really saying is top-tier, experienced talent in top paying geographies make significantly more than $200k.
I dunno, I think this might be a bias of your social circle. Looking at the latest levels.fyi submissions[1], the majority are for <$200k/yr.
[1] https://www.levels.fyi/comp.html?track=Software%20Engineer&s...
200k is not chump change for every other profession. Get off your high horse. You're not special because you know software.
> You're not special because you know software.
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.
Money really doesn't much once you've hit financial independence. I can live out the rest of my days with $1m invested. $200K-$500k annual salary, hell, even $100k, is enough at that point.
“I can live out the rest of my days with ... $200K-$500k annual salary”
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
I'm from Canada. I make ~$100k/yr at the moment. It's considered a top 10% salary. I am content. Top 1% here is ~$200k/yr. It's a lot of money, but not a lot of money is needed frankly for the average Canadian. I don't think I'll ever reach $200k/yr+, so the $100k/yr I'm at I'm thankful for.
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.
The problem with housing in Toronto and Vancouver is that like many other commonwealth countries, Canada isn't particularly strict about shady foreign money entering the country and driving up asset prices (in fact, it seems they welcome it).
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.
There was a ban on foreign investors last year for two full years, but it's mainly a scapegoat. The real problem is realtor facing, with shadow bidding, cheap access to large mortgages, over zealous campaigning of the "Canadian/American dream", and my personal favorite: total lack of rail infrastructure. The GTA does it better than Vancouver, with it's Go Train system et al, but Vancouver is totally cramped with its encircling USA border and mountainous regions. On top of that, with what available land there is, homeowners and city workers petition to prevent construction of new homes. It's NIMBYism at it's finest, allowing homeowners to gladly rake in yearly appreciations at 10-30% while Vancouverites with "generational" down payments of 200-300k out-shadow-bid each other for East Van / Surrey / Coquitlam sloppy seconds.
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
In the bay area, a $500k annual salary is really not that much in the grand scheme of thngs.
It's literally an elite salary. It makes no sense to imply you're living a frugal, simple life if you need an elite salary to do it.
It's all relative to cost of living (including taxes) and asset prices... even in relative terms though, it is possible to save a lot in the Bay Area if you're not consuming at the high end or have your eyes set on real estate.
I mean, if you're living in an area with COL high enough to eat through $500k, you are splurging on location, which isn't really any less infrugal than it would be to splurge on travel or imported luxury goods.
I wasn't the one who said I was living a frugal life.
You hopped in to defend the point, but go ahead and take your exit then
I think the point he is making is in context of software engineer, which matters. When you have several option to get paid twice, 200k does seem like chump change (in Bay Area at-least). It is all relative. Don't think I'm special or deserve the pay I get, but given I've options no way I'd settle for less for same work.
I wrote banking software that took a company's valuation from $400 million to $6 billion when it went public. That's not a special ability?
There's probably a bunch of other people could have writeen it just as well or better and it wouldn't have made a difference to the valuation of the company anyway.
You can throw up what-ifs and counterfactuals all day long - gsibble was the one who wrote the software.
That's actually quite an insulting thing to say.
But probably true nonetheless.
I'm not going to write a trieste on why my abilities were unique and let me write this software beyond to say I had worked in that specific industry for a long while, but there were not many people that could have pulled it off. When I left, they had to replace me with significantly more people at a significantly higher cost and it cost their growth and stock price quite a bit.
The problem is everyone else who worked for the company could claim the same nexus to adding $5.6bn of value to the company.
Or were you the one that made all that money and the only one who could do it?
> You're not special because you 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.
Umm + 100 to this. It surprises me how much recruiters (from all size companies) want you to leave your current role for a role that is worse in pay or growth opportunities or wlb or perks (usually all of the above) for the chance to "make future impact". What does impact even mean and why I care about it if I am not making more money or learning more or being challenged or growing or leveled up? I gotta really learn how to be shameless from these recruiters!!!
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 team, make a quick and generous offer. It'll pay off in spades.
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.
> Have 1-2 interviews with a take home.
> 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.
I've never poached someone without giving them a significant raise for one thing. I'm always clear about my expectations which are pretty simple - your time belongs to you. We pay you a high salary and expect you to get your assigned work done. As long as you get it done on time, you can fuck off and enjoy all of the excess time you have. If you do all of your two week sprint work in 20 minutes, you can enjoy the next two weeks off.
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.
> If you do all of your two week sprint work in 20 minutes, you can enjoy the next two weeks off.
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.
Yes, I/we do things significantly different than any other company I've worked for. Working fully remote makes it easier since you don't see people getting up from their desks or not coming into work. Our developers have no set hours, can work any hours they want, and are only expected to get the work assigned to them during a sprint done, no more, no less. I brought this style of work to our workplace and it's been a massive success. Everyone is extremely happy and productivity is through the roof. Makes for very loyal and hard working employees.
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.
I’m curious how you handle overly optimistic estimates with this approach?
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?
Good question. We generally overestimate to make sure people are given lots of time to complete a task. We also are not strict on deadlines. Didn’t make it this sprint but put forth your best effort in 40 hours a week? No worries at all. Good job. We’ll finish it in the next sprint. We never expect anyone to sacrifice work/life balance to further the company, a luxury of hiring only the best developers who keep my managers happy working reasonable hours. A lot of it is my managing their expectations as well. So far it’s working well.
Great to hear, glad that's working for you and the employees. Sounds great. Thanks for the book Req; I'm not in a position at a company to implement such teachings, I'm just an IC. Autonomy is certainly a big driver of job happiness for me though, I get it.
Thanks! We're constantly refining it. Employee satisfaction is a huge priority for me as we only hire top talent. Happy employees are productive employees. And productive employees make my bosses happy which makes our sales go up which makes the value of my equity go up. Everything is just better this way.
If I ever feel like writing a book (fat chance), I'll try to spread the gospel.
> threat of getting fired if I don't immediately live up to expectations
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.
You need to have a very very clear idea of what the new hire will be doing when they start.
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...
> You need to have a very very clear idea of what the new hire will be doing when they start.
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"
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.
For people with side/brochure projects, my "take home" tests are always "add these simple features to your git hub project xxx". Often it gets done the same day.
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.
Not being facetious here - if they have notable github projects, why do you want a new feature versus viewing or talking through something they've already developed in one of them? Why is the novelty important?
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.
> if they have notable github projects, why do you want a new feature
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).
Is this commonly done? I haven't seen this before. If I had an interviewer do this for me, I would be very impressed.
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 in person coding significantly more stressful than take homes. So what would you suggest? How do I test someone's ability to code?
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.
So if I asked you to do to a 1-2 hour coding task, you'd only do it if I were on a zoom call with you while you did it?
Yup! The interviewer can see my thought process. I can also evaluate my peers and ask questions about the work. The interviewer can also see how easy or cumbersome it is to set up the environment and code in the allotted time. Win-win.
If I was hiring a junior, perhaps that would have some use.
It's not about what's useful to you. Not everything has to be about you. It's acknowledgement that the interviewee's time is worth something (approximately about as much as dev time) and that you're willing to pay for it.
Yes. Put in the time with me to show you're serious. Otherwise you could mass spam candidates, most of which you don't actually care about.
That's fine. We're happy to let you do that if that's how you'd prefer to show us you can code.
If you need experienced developers to show you they can code you are only going to get amateurs.
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.
Ghosting after take home tests are extremely common. Usually the longer the test the more likely you are to be ghosted.
It was also pretty damn stupid. That was one of the motivators for me to stop bothering to look. I didn't need the work, and I was looking for work that interested me (this was a hardware company that made a system that interested me).
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.
Maybe a better way to phrase it is, "make the hoops count".
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.
You lost me at "with a take home". I'm not interested in your silly games.
Ok. What would you suggest instead? I need to know you can, you know, actually code.
Talk to the candidate. If you (and the candidate) cannot communicate well enough in 30 minutes to discover that then either (a) you don't know enough to work well with a really good developer or (b) the developer doesn't know enough to work with you or (c) both are true.
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.
Trust me when I say I've talked to plenty of candidates who I thought were great only to learn they couldn't actually code fizzbuzz. Talking to candidates doesn't work.
You want programmers to do tricks and silly initiation dances which is your whole problem. If you actually asked real questions about their experience then you’d get a good grounding. I might do silly problems for a high profile employer but that’s likely not you. In which case if I tell you to stop wasting my time and walk out of your attempted initiation ritual then you won’t like it.
No worries.
Your tone speaks dividends about how you view programmers. Often when you ask why something is hard then you’re the problem, not them.
Edit: FYI. The OP changed their initial reply from the condescending combative response to that below.
You might not be good at judging candidates. A good cto uses their gut and experience. An inexperienced or someone who doesn't have the gut uses tricks. Where do you fit?
Have you taken any courses or worked with professionals to help you with this?
There are people who genuinely believe they are good at their job, when they're not. They're not bullshitting and the conversation is genuine.
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?
There are ways of discovering if somebody can code without making them do fizzbuzz.
This is a good process: https://www.youtube.com/watch?v=cfyWvJdsDRI
My favorite because of how realistic it is, is have me/the candidate do a code review. It's a real world thing that will be a part of most jobs that doesn't require artificial nonsense like coding in a browser, memorizable hacker rank crap, or some throw away time wasting coding challenge. As for if I can code, I have seven public github repos, 3 of which are previous take home challenges of varying degrees of absurdity.
I said this elsewhere but reviewing previous projects or doing a code review does help somewhat, but it leaves out my ability to see your actual coding skill re: speed. I need to get a sense of that in order to feel comfortable hiring you. The only way I can do that is if you do some live coding one way or another. How you do it at our company is entirely up to you.
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.
Ask about project work, and real technical questions.
Many of us have a real life, and enough offers to chose from.
Sorry, but neither of those things show me that you know how to code. I don't know how long it took you to write your projects so you may be very slow and a terrible coder. Technical questions you may have prepped from a book. I need to see active coding, either live, in person, over zoom, or time boxed in a take home. We'll even compensate you for your time. But I need to see you actually working and review your work. Sorry.
Quite frankly, relying upon such things is a sure-fire way to make sure some bad developers get through the cracks.
No need to be sorry, I wouldn't apply to your company, and you would be lucky to even get a reply from me if contacting me on the typical social networks for developers.
Sorry.
No worries. Sounds like we wouldn't want you anyways if you have such poor work ethic.
> Sounds like we wouldn't want you anyways if you have such poor work ethic.
Ouch. I knew I saw red flags in your original post. This seals the deal.
What red flags did you see? That we pay top of market? That we work to have a low stress environment? That we put life before work instead of work before life? That 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? That we don't overload our top performers by giving them more work when they overperform but instead let them take the extra time off? Which of those is a red flag? Everyone at our company is very happy. Apparently some people don't like coding exercises. That's fine. We require people to demonstrate they can code. Everyone at the company has to go through that. We'll miss out on some candidates because of that, but I'd much rather miss a few candidates than have some false positives. I'm sorry that ruffles some feathers. We honestly strive to have the best work environment possible for engineers based upon my many years of being abused, overworked, and having to go through absolutely horrible, long, miserable interview processes. We do 1-2 interviews and ask you to code a little. I don't think that's unreasonable, especially considering all of the benefits on the other side.
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?
Those are a lot of words that could be empty. It's easy for me to see the red flags:
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.
1. Hire slow, fire fast is an incredible common and accepted form of hiring (https://hbr.org/2014/03/hire-slow-fire-fast). I thought we were discussing hiring here? My post was not meant to attract employees but to share my thoughts as an employer. You sound like someone who has not done much hiring/firing.
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.
To me, its the outright refusal to spend an hour doing something you claim to be adept at, because you've failed to understand the other person's problem despite it being explained multiple times.
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.
That's my thought too. I don't think this person has done much hiring so they don't understand the problem set. I haven't solved how to tell if someone can code without some kind of coding exercise. If I could, I wouldn't do it.
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.
Take home tests are never just an hour. They're open ended traps designed to find out who is willing to put in unpaid overtime. The OP themselves admitted to expanding the scope of a take home test they were given by around 10x because they felt it would give them an edge.
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.
I'm happy to sit down with you and watch you code if you'd prefer that. Most of our candidates prefer take homes. We're willing to work with our candidates to let them show their skills however they please. I'm not 100% for take homes, it's just the preference we've seen. And we never give take homes that are actual work, god forbid.
Like I said in my other post, your unwillingness to invest any time into getting hired tells me a lot about you. Let me tell you a story about how I got hired for a job I really wanted.
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.
So do you have applicants write a 4 endpoint API with flask, or do you have them implement an elevator system which you describe as very hard? I've actually given that question in an hour long interview. But guess what? They get to stop at an hour, instead of guessing how much work they need to do to move on. You and I know that someone could probably make a career working on that system.
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.
I think you're making a lot of assumptions about how we conduct our interviews that are way off the mark. First off, my description above was about my going through an interview process, not about how we conduct our interviews (the 4 endpoint API). The elevator system we ask people to see how far they can get in an hour so we can see their problem solving abilities and readable code abilities. That's it.
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.
Care to list your company so others can avoid a place that calls someone out for work ethic when the cto doesn't get his way?
There are plenty of fish in the sea....
Tell us who you are and what your company is. You truly sound like a terrible employer based on your shocking responses. You came here to ask for feedback and then when you got it you didn't like it. You are clearly the issue of why you can't hire developers. I'd wish you good luck but I won't.
We're a terrible employer? Let me tell you what kind of employer we are.
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 could have missed it since I’m reading on my phone before my morning coffee, but you don’t appear to have stated where you work. I’m curious where it is since if you would employ someone remote from overseas you sound like a great “no bullshit” employer/company!
Thank you. I don't advertise where I work on HN since I enjoy the ability to comment freely although we hire on all the standard job websites, including overseas.
My former employer has the best benefits package is the business but it doesn't mean I'd want to work there again. Any employer is made up by the people you will work with not fringe benefits. If you are one of those people then I wouldn't want to work there. I don't care about the wallpaper.
I see you went back through a lot of responses and edited them. Why is that?
We have a great group of people who all get along and are both great ICs and team members.
Wrong comment level, but I stand by your comment. :)
Paid take home assignments are the best in my experience.
If someone asks for it, we pay for their time. And we offer to get a sense of how they can code however they want. Take home, virtual pair coding, in-officce pair coding or coding exercises, whatever you want. We just need to see you code in a timeboxed way so we can see how you solve problems and see the results to make sure you write readable, maintainable code.
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.
I know that code and that’s what the resume says.
> 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.
Honestly, we've never encountered this problem. I've never poached someone that didn't work out. Usually, if I poach, I have to pay a premium so I'm fairly sure they can do the job.
That's the hiring side of the issue.
What's the assurance for the person you are recruiting?
We usually hire people unhappy in their current position and make an appealing offer. The chance that switching jobs may not work out is a chance all employees at all companies take. We don't do anything specific to protect against that like 99% of employers.
Great advice.
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.
I've heard horror stories. No amount of pay could get me to work there.
Everyone else thinks that their way of hiring is the best too.
Ok, tell me yours.
Good approach but can't imagine doing a take home unless it was paid.
I've never been asked to do a take home interview assignment, but I actually have the opposite attitude. I would much rather spend a few hours putting together that I feel good about than spend 10x the time cramming interview prep.
I prefer a take home over some LC as you can learn a lot more by seeing somebody's repo, tests, code, etc. than their rote ver of reversing a linked list ...but LC is cheap, a take home that respects the developer's time isn't.
Or, you know, you don't cram for the interview and just do as well as you can and let them evaluate on that. If you give me a meaningless take-home assignment, I have to actually write working code for it that looks good. If there's a trivial problem in an in-person interview, I can often "blah blah blah" through the more rote parts unless they really ask for details.
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.
> Or, you know, you don't cram for the interview and just do as well as you can and let them evaluate on that.
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.
Oh sure, but then as the interviewer, your take-home is also likely to be gamed by someone cramming for that too. Motivated people can always do too much work for a project. Whether it's a live coding thing, a take home exam, or a whiteboard problem, none of them really give a solution where someone isn't going to spend 100 hours prepping.
I did one that was time limited (2 hours, automatically timed and enforced). The exercise wasn't hard, but it did have some tedious quirks which meant I wasted quite a bit of time. But I thought "fine, I can jump through this 2 hour hoop". After I submitted it, it turned out there were some previously undisclosed extra steps where I had to record videos doing the kind of things i'd expect to do in an actual interview (talk through my solution, and talk about a project I'm proud of). I immediately lost interest.
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.
Depends upon how much proof I think I need to see. Both min/max are an hour but you can spend as long as you'd like on some. We take fun problems (github challenge projects I've spent days on just for fun) and give them as tests. We ask you just to spend as much time as you want to give us a sense that you can actually code and give us a sense of your coding style. We're mostly looking that you can 1) actually solve problems 2) write legible code 3) write maintainable code.
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.
No issue with take home approach, I think it's incredibly valuable if done in a manner that respects everybody's 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 very infrequently get asked to reimburse for time but we do limit how much when we do.
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.
I can appreciate that and obviously what you're doing is working out for you :)
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.
That's fine and up to you. Our interview process is extremely streamlined and requires 1/2 - 1/5 the time of most engineering interview processes. We do require someone to show they are capable of doing the work. How would you prefer to do that so I can take your feedback into account?
That really is the $1m question huh, wish I knew tbh. Even ignoring the unpaid work aspect the other Catch-22 is sure, you might filter a few "only good on paper" candidates but if you're hiring "top talent" what is a 5min Flask API going to prove?
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.
Indeed. That's why our most common coding challenge is this: https://github.com/mshang/python-elevator-challenge
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.
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 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.
>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.
This. I wish your comment would go to the top.
We move extremely fast on good applicants. We've gone from resume to interview to take home to offer in 24 hours. More companies need to be able to do that.
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.
Please start on coding tests. I'm interested to read your opinion on that.
Bias.
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.
Whenever I think about changing jobs, I think about the interview process and just keep putting it off.
Consider that FAANG-style interviews are pretty expensive to conduct.
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.
Interesting. I'd quibble with the degree of certainty in the last paragraph, but this is an interesting take with some concrete observations behind it.
In my very recent experience (specifically in the UK for roles to do with Ruby), the shirtage of developers mean it's way less painful than it used to be, cos companies are marketing themselves on their ease of interview process. I went from sending out CVs to getting a good offer in a week, and that offer was from a 1-stage, 1-hour interview process. Don't get me wrong, I basically spent that entire week on the phone to recruiters, but still, massive improvement on the last time I was in the market.
Tell the candidates what you want: I want someone who has 15 years of c++ experience transitioning into a go lang role. Rather than I want someone with 10 years of golang which will land you candidates with 2-5 years.
"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.
The #1 area to improve IMHO is enabling people to get to know the company and team in depth ahead of time.
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.
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 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.
Maybe this is cynical, but in my experience, companies are hyper-averse to expenditure, not to risk. They will thoroughly (though often ineffectively) analyze developers intended for medium- or high-salary brackets, but they are happy to also pay a third of the price for barely questioned offshore developers who are indeed very risky to whatever product they will be touching.
Well. The expenditure is a form of risk. Having a lot of cash outflow is something they want to prevent. So yes and no I think.
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).
Very recently. Totally fine with it, but I don't want to take a massive paycut for remote work. I haven't had to turn down offers for that reason but have heard people talking about it.
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.
Quite often it’s because you want someone with very high qualification (engineering, spoken langage in my country, experience…) to develop a crud app. All the while without good compensation, requesting them to be in an open office 5 days per week, and with dubious low end Dell that you insist on managing yourself. Of course you’ll then speak about family (to be understood as « you will not see yours anymore, slave ») or offering subpar pizza.
Finding good talent isn't specific to developers.
It's just a hard problem period.
One thing is for sure, Polyfill is going to do a terrible job addressing the problem.
Seriously.
I think the tech screens are the worst part, they're often so artificial and unlike the actual job that they result in a lot of false negatives. Here's how I rank the methods I've seen recently from best to worst:
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.
Everyone in this thread who thinks there is an easy / obvious answer to this question should realize how silly that belief is just from reading the other comments here:
"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
Some things that happened to me when I went for interview
- 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
#1 Money talks; bullshit walks.
#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.
I suppose LinkedIn has a feature where you can mark yourself als "open to job offers", I know XING does (yes, it's still alot bigger in Germany, don't ask). If non checking that box would help, no problem.
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.
It's because software is both a highly technical and creative endeavor. There are few people who can do it, and even fewer who can do it well. As hard as software development may be, managing it is even harder. This is always where the problem is. We need technical leadership courses to train management teams on how not to shoot themselves in the foot. Recruiting is only a small part of this large problem.
It is not so difficult. People make it difficult.
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...
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.
Companies only seem to move forward if you are doing exactly what they are doing exactly the same way they are doing it.
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.
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
Doesnt sound like you disagree. That falls under the "give me a task" part.
Yeah not sure if it was edited or my brain completely skipped it, but I totally didn't see that when starting my reply - sorry.
> 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.
That skill has nothing specifically to do with Go. Most languages have some "ParseInt" function or so. And of all the languages I use for daily work I could not 100% tell you what that function is exactly called.
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?!
Converting ints to strings isn't a 'skill'. It's a simple task to see if they are well versed enough in Go to get started.
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.
It's insulting because you automatically assume the candidate is a fraud. What if the candidate asked to see your financial bookkeeping to make sure that you always pay salary on time? Would that be cool with you? They just want to make sure that your company isn't a fraud and does actually pay their staff... right?
If you were applying to be a doctor would the interviewer giving you an orange and a dull knife and asking you to cutout a seed without spilling any juice on the table be helpful as a hiring filter? Because that is what you are doing.
Just hire a few people part time and the one(s) that can deliver offer full time roles.
This analogy doesn't hold water.
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.
It's more like asking them to list all the chemical components of some pain meds that they might prescribe for a sprained ankle.
Also would you really ask a doctor such a (as I already said) insultingly trivial question during an interview?
Over 15 years in the industry, shitloads of code shipped in a dozen plus languages, repeatedly taken an idea all the way to being a functioning product, usually get great feedback from peers and managers, often taken point on architectural matters, et c., et c.
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.
Honestly while I would agree for a lot of obscure methods, I can't imagine a senior engineer not knowing how to convert an integer to a string.
You are testing if they have how to convert a number to string in working memory. Is that really helpful.. in real life they would look it up refresh themselves. You just filtered people who can look up answers and learn things. Aren't those skills more inline with what most positions need?
Converting a simple type to a string is pretty basic, though. How else would you display things to the user?
Put simply: HR.
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."
> For example, if I want to hire someone with 10+ years of experience who’s going to work on a complicated go api, I’ll get resumes from candidates who have <2 years of experience, but have written some go. I won't necessarily see the developer with 15+ years of C++ experience who would probably be a much better fit.
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.
I am the author of this blog post and also a C++ developer with more than 15 years of experience, who hires people like myself, and writes go when it makes sense.
> 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.
Curiously enough, it's for the same reason writing bug free software is difficult: we do not know what we are doing. Thus, it's rather to hard find someone good at we-do-not-know-what.
Seems like a lot of people in the comments are getting recruiting and hiring confused.