Number 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.
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.
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.
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.
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?
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…
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.
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.
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.
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.
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.
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.
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.
> 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.
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?
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
> 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.
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.
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 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?
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.
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.
>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.
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.
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 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.
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.
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.
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]
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
#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.
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.
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
> 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?
> 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.
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.
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?
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.
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.