The real truth is: hiring is a crapshoot. For any position and any field. Software engineering is no different.
There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
Instead, third-party HR monoliths have moved in and snatched up (and more or less created) the 'market' for screening and filtering applicants. Larger companies sigh, throw up their hands, and say 'well how else can we deal with hundreds of applicants?'.
As if that 'funnel' of applicants contains what you think you want. As if it's just an exercise in reductionism, each applicant a data point to evaluate.
Given this, why not hire lightly and fire lightly?
Construction and trades takes that approach. It’s a mixed bag. I would say implicit job insecurity removes a lot of potentially good employees from the applicant pool. People who value stability and support families tend to be reliable, and some of them won’t work for someone who has a reputation for firing everyone as soon as things get slow or if they have an off day.
I think my industry (civil engineers) is a bit easier to hire for because credentialing weeds out people who are completely out of their depth, and lying about qualifications can get you in real trouble. Managers can assume you’re basically competent and can focus on hiring people with decent personality and a good reputation. Some of my software friends use brain-teasers to screen candidates, and it comes off as a bit silly to me.
I think my industry (civil engineers) is a bit easier to hire for because credentialing weeds out people who are completely out of their depth, and lying about qualifications can get you in real trouble. Managers can assume you’re basically competent and can focus on hiring people with decent personality and a good reputation. Some of my software friends use brain-teasers to screen candidates, and it comes off as a bit silly to me.
Pretty much the case for every non-Software Engineering discipline.
But then again, people in the tech field will vehemently defend the system - because it's one of the very, very few fields where you don't need a college degree, can go on and "grind leetcode" for months, and land a six-figure job.
And it is because of that, that tech companies are making their recruitment process bordering the absurd. They're simply deadly afraid to vet frauds, that have "gamed" the system.
So in short - tech companies would rather let 10 decent candidates slip by, if it means they can block 1 fraud.
I've been to many engineering interviews, outside tech, and it is not even remotely the same process.
Funny you should mention that. At my college (Cal Poly) I had fraternity brothers who were Civil Engineering majors. They would look up to me because I had a natural ease with computers. But in the end, I watched them sweat their way through classes that would have wasted me.
> Given this, why not hire lightly and fire lightly?
Because any company that adopts such an approach will never be able to recruit anybody who wants to work in a stable environment with a consistent set of smart people who aren't in constant fear that they will be fired the next day.
When you know you have a job for the next n years at least, you also tend to put more effort into efficient processes. When you have to wonder every other month if you will still be there a lot will be just quick and dirty ad hoc solutions.
It is still not easy to find good people, but the truth is: HR are not the best people to decide who is. If you have good people already and they don't try to build an empire, they will select good people. The danger there is only that they will select people that are too much like themselves or they will select the worse candidate because they fear about their own standing etc.
More accurately: such an environment requires paying a premium to compensate for the decreased job security. (As with any market, employees expect to be compensated for their higher risk with higher returns.)
Netflix, for example, and Amazon (to some extent) have gotten away with this model but the vast majority of companies are simply unwilling to pay top of market.
Additionally, in many markets there's no such thing as 'firing lightly'. Here in Scandinavia firing people requires a significant amount of work on the part of the manager and HR.
You should fire lightly early, and fire hard if late.
Where I live you have a month when starting were you can be fired with 2 weeks let-go period, after which it takes 3 months or more.
I think you should have an intensive monitoring/evaluation in the first month, and fire lightly if you think there is a mismatch. After you have determined an employee fits you, if they stop fitting you try to figure out why, help them to fit again (are they the kind who gets bored, needs new challenges?, do they have problems at home? If you found someone who fits I think it is more efficient to make them fit again then try to find someone else who fits). I believe this is the way to go even in areas where you do not have the rules about the dismissal period that you have here.
Yeah, exactly... depends a lot on who is doing the firing and why too.
I suppose if ALL companies did that then there might be some sort of fluid equilibrium state where most companies had some mix of mostly competent engineers who chose to work there for positive individual choice/reasons. But in a more winner-take-all world where the "best" need to hire the "best", because that means second tier companies get the rejects and therefore will fail to compete and the chosen few get success and riches? Set the bar incredibly high and forget fairness. (also an extreme for purpose of conversation, just on the other end of the spectrum)
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
I can say with confidence that certain resume features are incredibly strong predictors of interview performance (at least in the related measures, in the field and/or team I'm working in). I'm not HR, but your statement seems to also deny the possibility of this empirical observation.
> Given this, why not hire lightly and fire lightly?
Because it would be a complete dick move to have someone relocate (possibly involving change of country) and then fire them 2 weeks later? That's not even looking at the formal, bureaucratic or training overhead, or any of the other factors in this industry that make hiring and firing a bit more complicated than handing someone (and later taking away) a hardhat and a shovel.
> it would be a complete dick move to have someone relocate (possibly involving change of country) and then fire them 2 weeks later
This. I hold a slightly lower bar (meaning more willing to take a chance) on someone who is unemployed than if they're working now. Worst case if I take someone unemployed, hire them "light", and they don't work out is they're back where they already were, whereas if someone quits their job to come work here and gets fired, they're worse off than they were before.
Google basically admitted that GPA and where you went to school don't matter and do not correlate with job performance. And yet here we are still optimizing on the Ivy League. It'd be a safe wager that algorithm whiteboard interviews don't either except that they screen out folks who don't pass the interview. So because everyone has that baseline, that baseline is by definition meaningless. The other side of the coin is that performance management is also just as bad.
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire.
I don't have stats but anecdotally, hiring by personal reference seems by far the most effective way to hire.
> Given this, why not hire lightly and fire lightly?
Because it's a huge financial and organisational burden on the hirer and an even huger (sometimes existential if you live in the U.S. due to health insurance but that's a whole nother rant) burden on the hiree.
To add to this, as a senior employee, bringing someone junior up to speed to the point where they can make actual contributions is a big consumer of time typically. Less so for employees who come in at medium rank but even then there is a hand holding period as the new person gets used to the company culture.
In a sufficiently large company you could have a specialized onboarding team, but you’d need to be careful that the specialized team doesn’t get isolated from the technical culture and needs of the rest of the company
It shouldn't be. From my experience, the financial cost that comes from increasing the number of people you fire after a few weeks is less than what companies spend furiously guarding against making a bad hire.
I propose the Monte Carlo hiring process: heads means the applicant is hired without question, otherwise they get to go through the regular interview routine.
Isn't it? While machine intervention might be able to weed out the most obvious low-quality candidates, I don't think there's any strong evidence that most hiring processes actually select the strongest hires - just that they, out of the set of candidates that progress to the point of human intervention (i.e. interview), select a decent one.
The problem is that interviews don't scale well, and some kind of automatic culling of the field of candidates is necessary. Engineers, managers, etc all want to feel that whatever machine solution (keyword searching in resumes, applying AI to recorded video statements, HackerRanks) they select is better than random - but there's no incentive for them to check that that's true.
Obviously randomness + interviews is better than pure randomness, but ultimately hiring processes are still pretty random. If you need to weed out most of your candidates, you can't do much better than throwing most of their applications away - and companies end up doing just that, only they cargo cult an "automated process" that claims to do better.
Has random hiring often been tried? I've never heard of anyone doing it. Not sure random hiring would be optimal, but it would be interesting if there were some data, doubtful it exists, though.
Just because it's widely used doesn't mean it's good.
Source: they let me interview people at one of those fancy FAANGMO places (and I don't actually know what I'm doing). Interview success comes down to how lucky you get in the loop imo.
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire
This is a manifestly absurd claim. It is possible to improve the outcome of a hire, and almost everyone is using those kinds of processes. The firm I work for does an excellent job filtering people for skill and compatibility. The trick is that if you want to capture the top e.g. 10% of applicants, you're going to have to pay them several times more than the median applicant. Most companies are too cheap to attract distinguished talent.
>The real truth is: hiring is a crapshoot. For any position and any field. Software engineering is no different
I tried building spaceship and failed. Fiend of mine tried building a spaceship and failed too. However, I know of people who built a spaceship. So is building a spaceship a crapshot?
Reality is: 95% of HRs are incompetent. That's where randomness comes from. Take a random man from street and assign him for HR role after a brief training -- you'll achieve a similar performance to those 95% HRs.
Everybody's talking about hiring the engineer, but so fewer people talk about finding a good HR that would help you to solve a "simple" problem: how to find a good engineer with small experience and small salary that would not leave your company for the next few years and would become after several months just as good as 70-100$/hour engineer hired from top software company, while later most likely still gonna need some time to adapt to your product to become efficient.
Because hiring has costs, this requires substantial risk tolerance, and is more suitable to a bigger corporation that can bear them. It will also give you a reputation — though some companies seem to manage quite well even with an iffy reputation in this area (e.g. Netflix). You need a certain amount of prestige to pull that off, I think.
id also say it works out okay. its just long and tedious and it feels more painful than it should - but really its not all that bad in general.
I see very toxic people being rejected that think its because of their gender/color/whatever <= lots of complains but the process work
I get rejected sometimes because of misalignement from me, or from them <= feels bad man.. but the process works
I've never been hired to a place where I found that this was all a terrible idea, in 25 years. Theres been places better than others, theres been adjustments after hiring.
I've seen places hire people using simplified processes and the candidates were unsuccessful and unhappy after being hired <= process fail
I think a lot of us suspect that just choosing applicants randomly would probably have a very similar outcome to what we do now, but nobody wants to be the first to try it.
The above statement is really just validation that the current process sucks so much for everyone that it's conceivable to replace it with random choice. However, it's not actually true (for reasons explained in the blog) - as a hiring manager, I am confident you couldn't ship "Hello world" by hiring randomly.
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire.
Daniel Kahneman analyzed a bunch of data that lead him to concluded that the typical interview process did nothing to help select the best candidate. There's a chapter about it in Thinking Fast And Slow [1] and the advice he gives is summarized in this article [2]. I remember thinking after reading this book that it was just a matter of time until everyone everywhere would be denouncing interviews but here we are - old habits die hard.
What are you talking about? The article is nearly the exact opposite of what you claim. It says:
> A vast amount of research offers a promise: you are much more likely to find the best candidate if you use this procedure than if you do what people normally do in such situations, which is to go into the interview unprepared and to make choices by an overall intuitive judgment such as "I looked into his eyes and liked what I saw."
I've been seeing this sentiment a lot on LinkedIn, particularly with new developers entering the field. Leaving aside the whole argument about whether or not we should really be calling software developers engineers, a lot of these same people are advertising themselves as full-stack. I'm sorry, but you going through a 10-week bootcamp or even getting a 4 year CS degree does not make you full-stack.
It's comparable to how we laugh at recruiters when they ask for 5 years in a given language that has only been around for 2 years. You clearly don't know what you're talking about.
I always tell the folks I mentor through bootcamps they should figure out which area they like best, focus most of their efforts in that area, and then advertise themselves as a front-end developer or back-end developer or whatever, not full-stack. The upside down T approach. Show recruiters and hiring managers you at least know enough to know what you don't know.
And stop complaining on LinkedIn about how unfair it is that you don't have a million job opportunities pouring in or about all the applications you submitted and didn't hear back from - yes it's annoying, but if you advertise yourself as something you're not, you've likely already wasted someone else's time, so understand they probably don't want to waste anymore giving you an explanation for why you were passed over.
>I've been seeing this sentiment a lot on LinkedIn, particularly with new developers entering the field.
It honestly just amounts to "The most well compensating jobs with the most competition to attain them have a difficult application process, and that is unfair (to me) because of X, Y or Z". These posts are positively dripping in grandiose levels of entitlement.
If you can write a web page that submits a user form and a server that writes that data to a persistent database ... I'm failing to see which part of the "stack" is unfilled. This is what bootcamps teach.
Yes, bootcamps teach you the basics of each part of the stack. I would make the argument that you aren't proficient in any of these areas, so to advertise yourself as such is misleading. I file my own taxes, but I don't refer to myself as an accountant.
I've yet to meet a bootcamp grad that can efficiently architect a relational database, for example. I know plenty of Sr. level front-end developers who wouldn't think to call themselves full-stack even though they know how to submit a user form that persists to the database. Same with back-end developers who know HTML, CSS, and pick your flavor of JS framework.
If you've worked in the industry, you know things change too fast to stay up to speed on everything. It's not impossible, but it's unlikely and unrealistic to have that expectation of someone once they are employed.
You're missing the edge, which is very very broad.
Suppose your employer wants your web app to interface with an industrial PLC, or fetch data from a car's CAN bus, or talk to a vending machine (ironically the sort of machine that Java was originally designed for).
Most bootcamps don't teach enough fundamentals for someone to figure out how to write both client- and server-side code for those sorts of situations.
Or on the other end of the spectrum, could you write hypervisor code to manage the sort of mass-scale VM deployments behind most cloud providers? It would be very difficult to be an expert on the "full stack", if you think about it.
So...tl;dr, most of the application layer? Probably the physical layer too, any how many of us really work with the link layer?
Yup. People don't realize how many applicants literally can't even pass FizzBuzz, or some slightly more complicated variant. It is not just a meme. Dunning–Kruger.
I see this a lot on forums, blogs, Reddit, etc. but after having interviewed many candidates, I have yet to see someone that incompetent.
My company is not a hot Silicon Valley tech company either. It's a dull, boring, investment bank. I am generally not impressed at the quality level of most of the candidates we get when we hire. But still 100% of them are able to code more than well enough to pass FizzBuzz.
Now throw anything beyond the easiest of leetcode easy level questions at them and the majority will struggle. But that is still a level above Fizzbuzz and the like. And most come from backgrounds where the last job they were hired for did not leetcode them, but rather relied on language/framework trivia type interviews.
Eh, I think it's fine. If you're going in at entry level, your expertise won't be that deep, but full-stack just means open to joining a team that does front-end, back-end or both. The typical bootcamp grad can develop into a specialist or generalist as they go, given support and resources.
I think saying you are full-stack is misleading and it sets job-seekers up for failure. And I would argue it's not fine, since it's these same types of people whining about what terrible luck they are having (purely anecdotal of course).
A few ideas that I think would give these grads some better luck:
- Update your profile to say "Interested in joining a front-end or back-end team" or "tech generalist with a focus on X"
- Elaborate even further in your About section and let people know which of the two you are stronger in and what experience you have
- Swap out "full-stack" for "web developer"
Don't tell me you're something you're not. Under-promise, over deliver. Seeing full-stack on a resume sets my expectations for whoever I'm about to interview regardless of the number of years of experience.
I always understood full-stack as "willing to work on both server and client side". In opposition from people who work only on frontend or only on server.
Here's a radical idea (read to the end before you object). The inspiration is a blend of how open source projects recruit developers, and how the 20% Google side-projects used to work.
I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.
Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you.
How can we make this work: legal framework. California, if you are listening, pass a law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so.
1. This process is probably going to bias your hiring pool towards young and single people that are willing to either work weekends or use vacation time to go work on a part time job
2. Forcing a company to let an employee work for a competitor opens up a whole new can of worms. This seems game-able in the same way that the Washington DC revolving door is e.g. Uber hires a Tesla autopilot engineer at the cap of 5% of his salary, and after a few years of "contributions" which are totally not industrial espionage they bring him on full-time with an eleventy million dollar signing bonus.
My partner works for a big accounting firm and when a member of staff wants to leave their people-manager, will if they wish, actively help them find a secondment to another firm (not a competitor).
People sometimes want to leave a job and it's in everyones interest for that process to be smooth and pleasant. The leaver has a good final impression of the firm so they recomend it in the future to potential clients or employees, they get support in finding and trialing a new job, and the company to whihc they are seconded gets a low risk trial of a new memeber of staff.
It just seems so grown up compared to the ineffectual thrashing about of tech recruiting.
Hmm, legal framework, maybe... but maybe with some small tweaks the legal framework wouldn't need much changed...
If you become a contractor rather than a full time employee, the only thing you're missing is benefits/retirement probably, in addition to longer term commitments from an organization (maybe - these days there are no real guarantees).
If you can get benefits/retirement through some other kind of government program or join an independent group that forms together (I remember there was a YC company that was doing this) to pay for group benefits - then why not just go the contractor route?
This is relatively close to my dream hiring process, except I'd shortcut it. Instead of working 1 day a week because you're bored, just take a week off. Come work at my company for a week. If we like you, we'll hire you.
However, the legal issues sound like a nightmare. Additionally, in the US many people's benefits are tied to their job, so if they needed to, for example, take unpaid leave to do this "test drive" that would also cause complications.
Wouldn't most companies who are in the shoes of company A in this example, find some excuse to lay off the employee in question when the person applies for this arrangement?
Or do you mean the employee would do this in secret from company A? If so, like the other commenter said, that excludes anyone who can't put in weekend work time.
1000x this! Seems like win win for both sides. Kind of reminds me of universities that let you take a course or two to then allow you to continue in the degree program . For some reason I can’t think of any university that actually does that. Is it possible that hiring and university admission suffer the same affliction?
...as long as your employer doesn't think it competes with their business. If it does (even if it competes with a part of the business that has nothing to do with your work or that you don't even know about) things can get messy
This article is not talking about how broken Google-style algorithmic interviews are. It's encouraging Google-style algorithmic interviews by bringing them to the candidate as soon as possible. This is achieved by making candidates pay money for mock interviews with interviewers from tech companies.
This fundamental problem this article is describing is that recruiters are filtering out too many candidates by pedigree to ever have them end up in an algorithmic interview with a tech company.
How important is your pedigree in getting a (good) tech job? If you've worked as a SWE in some capacity, it seems like most companies (even top ones) consider you good enough to at least interview you.
My pedigree is average at best. I've worked my entire career at non-tech companies (banks, hedge funds) doing decidedly unsexy work. I'm still able to attract enough attention that FAANG and many other top tech company recruiters contact me first.
Interestingly enough, it's the top companies in my current sector (finance) that refuse to even have an internal recruiter casually speak with me. i.e. Citadel, Two Sigma, Jane Street, etc.
There's also stories I see occasionally on LinkedIn, etc. of people from completely non-technical backgrounds getting hired as SWEs at top tech companies. Taxi drivers, ex-felons, aestheticians, etc. getting hired as SWEs at FAANG and unicorns.
> How important is your pedigree in getting a (good) tech job?
Working at a well-known company can definitely help open doors. It proves that you’ve already completed their challenging interview process and it’s also assumed that you picked up some good engineering practices while working there.
However, pedigree alone won’t get you jobs at most places. You still have to go through the interview so they can see how you perform on a level playing field.
As much as online comments hate the coding challenge interview problems, they’re actually a great thing for people without impressive career pedigrees. It’s the only way you’re going to get to compete on a somewhat level playing field next to the kid who went to an Ivy League and landed all the right internships due to their parents’ connections.
Generally speaking, it’s the people who have jobs at well known companies who want to get rid of coding challenges and go back to hiring based on pedigree, mostly because it benefits them greatly and reduces their competition. In reality, anyone talented enough to work at top companies doesn’t have to study much for coding interviews. This idea that coding interviews are somehow filtering out brilliant engineers and selecting for less qualified people is largely a myth. The reality is that engineers just don’t like being challenged on the spot and would rather employers just trust their resume. That is, if they already have a good resume. The juniors love coding challenges because it’s a way to prove your skills without relying on pedigree or university or family connections.
Having been in the field for almost 15 years, it seems to me that hiring has always kind of been hit and miss and all these timed tech interviews don't really help much as they focus too much on just code or system design. But the majority of problems I have encountered have not been technically difficult. Once you create an application with a sound system design, all the other technical stuff isn't really a challenge.
Majority of the issues are caused by requirements not being communicated, captured, or implemented properly. That's something that's not really focused on tech interviews. I just want a diligent developer who can identify potential issues, do their research, and propose solutions rather than be able to design a system in 90 minutes, because that's never happening in real life. In fact, I'd not hire someone who can claim to do so.
The thing that companies fail to do is reconcile hiring decisions with performance reviews afterwards. They have a single hiring practice and they NEVER EVER change it, regardless of the quality of the eventual hires.
The missing feedback loop from performance review back to the hiring process means that the hiring process can't get fixed. Until companies start adding that process back in, hiring will never get better.
I think it's complicated by the fact that the better the company, they better they are at mentoring even "bad" hires. I.e., performance review isn't normalized across all companies. Google might think their hiring process is great because a lot of their hires do well in their performance review - but maybe that has more to do with the engineering culture and mentorship in the company, and less to do with their ability to pick future winners.
Perhaps though if one looks at the performance review weighted to a review date as soon after the hiring, and sort of tail off how much weight is given over the coming years it'd make sense.
I've just seen a lot of bad hires get better with time. And some good hires lose steam or become jaded and perform worse over time.
Thus, as messed up as it is, one of the keenest signals is tenacity in the end. And ironically tenacity in preparation for interviews (that Leetcode grind) is somewhat correlated with performance reviews in the long run and perhaps correlated with utility to the company.
That said, "decent" engineers in the long run that don't think outside the box but check their performance review boxes slowly bleed a company's ability to disrupt. I.e., performance reviews need to be expanded a bit to think about the health of the overall company and not just the employee performing their function.
As a large tech organization, I'd prefer a complex distribution of performances over an even distribution any day - because value to tech companies is still influenced by more black swan event type of innovation. But then I have a high "beta" (variation) in terms of what I'm looking for. Companies with more of a utility emphasis perhaps are better served by a hiring process that is "reliable" with a lot of false negatives.
A company's hiring practice should reflect the type of engineer they want to hire. If they want to hire engineers that can start contributing immediately, and they hire engineers that need mentoring, then the hiring process is broken.
If they widen their expectations, and hire people that they believe they can mentor into net contributors, then their hiring practices should reflect this.
There are many ways a company can make hiring more scientific, including A/B testing (ie. hiring people they normally wouldn't, have more data around how productive new hires are, etc) but I've never seen it over than "copy Google and we should be good."
I agree that in general, feedback loops are important. But you had better be absolutely sure that you're measuring the right thing, because once you put it in place, your hiring process will begin to optimize around it. So unless you can write down precisely what it means to be a good whatever, you probably shouldn't expect feedback to solve your hiring problems.
Yeah, I think this is a more concise version of the point I was trying to make. And that perhaps "performance reviews" should be one of a couple of signals as feedback to the hiring process. There's just so many variables in play (covid-19, etc.) one has to be super careful about recognizing the right signals / causation, etc. Ideally one needs experiments about which signals or feedback to use in determining if it's a good hire in addition to experiments about different hiring process changes.
An issue with this is that it's inherently one-sided: you get to see the performance of the people you hire, but you have no idea what happens with the people you reject.
Because of that, you inevitably get "weird" results like seeing that your best employees often did relatively poorly on interviews (Google did a study that produced exactly that result—their best employees often were those that failed 1 or 2 of their interviews).
But this is just selection bias: these are candidates that got hired! Which just means that they were so spectacular in some other respect that they were able to get an offer /despite/ poor interview performance. It tells you nothing actionable about your interview process.
Really you need to take an experimental approach where you randomly give offers to people who failed the interview, and see how they turn out.
I guarantee that companies (at least large companies) do reconcile hiring decisions with performance review data. Google, at least, has entire teams of analysts focused on exactly this sort of analysis.
Fundamentally, hiring is simply not an easy problem. There's a small cohort of candidates who can be reasonably confident will perform well in a job (mostly people who have performed a similar job at a competitor) that everyone competes over and a marge larger group of candidates whose possible performance is very hard to judge.
I'd like to see a "speed dating" concept implemented in tech hiring.
You, along with however many other candidates rotate around among different companies. You maybe work for each company up to 1 week. At the end you get your offers and decide among them.
I've ended up working for too many lemons because of lack of visibility into how well put together they really are. I want to know ahead of time whether they really have their ish together or if the interview bubble is just a facade.
We already have something kind of like speed dating for hiring: job fairs. Your idea is more like a one night stand. It would be cool if there were large scale career fairs that are hosted outside of colleges open to the general public, and then there was some sort of organized process where people could talk one on one for some period of time with representatives of the top X companies they choose. Probably will need a basic filter so there aren't tens of thousands of people per company, and spread the interviews out over several days. You always hear about networking, but outside of exclusive groups that already require money or status to be a part of, there aren't opportunities for people who need each other to meet up in an organized way and get things done.
I'm not anticipating you'll read this, but for anyone who happens to read this part of the thread, I don't think job fairs are even close to what I described above. They serve similar purposes, but in my case described above, an actual hire will occur or it won't. Job fairs, at least the ones I've been to are more like an advertising kiosk in a mall where no one you're talking to has any authority of any kind let alone deciding whether or not to hire you on the spot :)
Also, at a job fair you have no idea what the day to day life will be in your new position. In my scenario, once you are or aren't hired you will have already lived the life you will be living if you are hired.
I have a very simple hiring process. I describe the product, the work, the gaps. I ask them what their interests are. We find where the interests align with our gaps. If there is no alignment, we simply don't move forward. I tell them the compensation. They accept or reject.
Takes about 45 minutes. Pretty simple, the goal is to make sure that they want to do the work that we need done, and that they feel prepared to do so.
Readit News
There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
Instead, third-party HR monoliths have moved in and snatched up (and more or less created) the 'market' for screening and filtering applicants. Larger companies sigh, throw up their hands, and say 'well how else can we deal with hundreds of applicants?'.
As if that 'funnel' of applicants contains what you think you want. As if it's just an exercise in reductionism, each applicant a data point to evaluate.
Given this, why not hire lightly and fire lightly?
I think my industry (civil engineers) is a bit easier to hire for because credentialing weeds out people who are completely out of their depth, and lying about qualifications can get you in real trouble. Managers can assume you’re basically competent and can focus on hiring people with decent personality and a good reputation. Some of my software friends use brain-teasers to screen candidates, and it comes off as a bit silly to me.
Pretty much the case for every non-Software Engineering discipline.
But then again, people in the tech field will vehemently defend the system - because it's one of the very, very few fields where you don't need a college degree, can go on and "grind leetcode" for months, and land a six-figure job.
And it is because of that, that tech companies are making their recruitment process bordering the absurd. They're simply deadly afraid to vet frauds, that have "gamed" the system.
So in short - tech companies would rather let 10 decent candidates slip by, if it means they can block 1 fraud.
I've been to many engineering interviews, outside tech, and it is not even remotely the same process.
Because any company that adopts such an approach will never be able to recruit anybody who wants to work in a stable environment with a consistent set of smart people who aren't in constant fear that they will be fired the next day.
It is still not easy to find good people, but the truth is: HR are not the best people to decide who is. If you have good people already and they don't try to build an empire, they will select good people. The danger there is only that they will select people that are too much like themselves or they will select the worse candidate because they fear about their own standing etc.
Netflix, for example, and Amazon (to some extent) have gotten away with this model but the vast majority of companies are simply unwilling to pay top of market.
Where I live you have a month when starting were you can be fired with 2 weeks let-go period, after which it takes 3 months or more.
I think you should have an intensive monitoring/evaluation in the first month, and fire lightly if you think there is a mismatch. After you have determined an employee fits you, if they stop fitting you try to figure out why, help them to fit again (are they the kind who gets bored, needs new challenges?, do they have problems at home? If you found someone who fits I think it is more efficient to make them fit again then try to find someone else who fits). I believe this is the way to go even in areas where you do not have the rules about the dismissal period that you have here.
I suppose if ALL companies did that then there might be some sort of fluid equilibrium state where most companies had some mix of mostly competent engineers who chose to work there for positive individual choice/reasons. But in a more winner-take-all world where the "best" need to hire the "best", because that means second tier companies get the rejects and therefore will fail to compete and the chosen few get success and riches? Set the bar incredibly high and forget fairness. (also an extreme for purpose of conversation, just on the other end of the spectrum)
Deleted Comment
I can say with confidence that certain resume features are incredibly strong predictors of interview performance (at least in the related measures, in the field and/or team I'm working in). I'm not HR, but your statement seems to also deny the possibility of this empirical observation.
> Given this, why not hire lightly and fire lightly?
Because it would be a complete dick move to have someone relocate (possibly involving change of country) and then fire them 2 weeks later? That's not even looking at the formal, bureaucratic or training overhead, or any of the other factors in this industry that make hiring and firing a bit more complicated than handing someone (and later taking away) a hardhat and a shovel.
This. I hold a slightly lower bar (meaning more willing to take a chance) on someone who is unemployed than if they're working now. Worst case if I take someone unemployed, hire them "light", and they don't work out is they're back where they already were, whereas if someone quits their job to come work here and gets fired, they're worse off than they were before.
Deleted Comment
But what about actual job performance?
No, it's just the companies using it keep that data to themselves. Their hiring process is then a competitive advantage.
But I do know some companies who have a competitive advantage in the tech market, and their hiring is not great.
I don't have stats but anecdotally, hiring by personal reference seems by far the most effective way to hire.
> Given this, why not hire lightly and fire lightly?
Because it's a huge financial and organisational burden on the hirer and an even huger (sometimes existential if you live in the U.S. due to health insurance but that's a whole nother rant) burden on the hiree.
In a sufficiently large company you could have a specialized onboarding team, but you’d need to be careful that the specialized team doesn’t get isolated from the technical culture and needs of the rest of the company
It shouldn't be. From my experience, the financial cost that comes from increasing the number of people you fire after a few weeks is less than what companies spend furiously guarding against making a bad hire.
>and organisational burden on the hirer
There's no reason this needs to be the case.
Isn't it? While machine intervention might be able to weed out the most obvious low-quality candidates, I don't think there's any strong evidence that most hiring processes actually select the strongest hires - just that they, out of the set of candidates that progress to the point of human intervention (i.e. interview), select a decent one.
The problem is that interviews don't scale well, and some kind of automatic culling of the field of candidates is necessary. Engineers, managers, etc all want to feel that whatever machine solution (keyword searching in resumes, applying AI to recorded video statements, HackerRanks) they select is better than random - but there's no incentive for them to check that that's true.
Obviously randomness + interviews is better than pure randomness, but ultimately hiring processes are still pretty random. If you need to weed out most of your candidates, you can't do much better than throwing most of their applications away - and companies end up doing just that, only they cargo cult an "automated process" that claims to do better.
But every company in FAANGMO does use the same (or at least pretty similar) hiring process.
Source: they let me interview people at one of those fancy FAANGMO places (and I don't actually know what I'm doing). Interview success comes down to how lucky you get in the loop imo.
Hiring is doing just fine.
[1] Some Thoughts on Interviewing and Why We Do It https://jwongworks.com/blog/2018/07/24/some-thoughts-on-inte...
[2] Screening developers should be easy https://acjay.com/2019/05/16/hiring-developers-is-easy/
This is a manifestly absurd claim. It is possible to improve the outcome of a hire, and almost everyone is using those kinds of processes. The firm I work for does an excellent job filtering people for skill and compatibility. The trick is that if you want to capture the top e.g. 10% of applicants, you're going to have to pay them several times more than the median applicant. Most companies are too cheap to attract distinguished talent.
I tried building spaceship and failed. Fiend of mine tried building a spaceship and failed too. However, I know of people who built a spaceship. So is building a spaceship a crapshot?
Reality is: 95% of HRs are incompetent. That's where randomness comes from. Take a random man from street and assign him for HR role after a brief training -- you'll achieve a similar performance to those 95% HRs.
Everybody's talking about hiring the engineer, but so fewer people talk about finding a good HR that would help you to solve a "simple" problem: how to find a good engineer with small experience and small salary that would not leave your company for the next few years and would become after several months just as good as 70-100$/hour engineer hired from top software company, while later most likely still gonna need some time to adapt to your product to become efficient.
Deleted Comment
Hire people with multiple pages on a resume with a variety of experences is a good strategy increasing your odds.
I see very toxic people being rejected that think its because of their gender/color/whatever <= lots of complains but the process work
I get rejected sometimes because of misalignement from me, or from them <= feels bad man.. but the process works
I've never been hired to a place where I found that this was all a terrible idea, in 25 years. Theres been places better than others, theres been adjustments after hiring.
I've seen places hire people using simplified processes and the candidates were unsuccessful and unhappy after being hired <= process fail
Word of mouth recommendations, and yes everyone uses it.
Daniel Kahneman analyzed a bunch of data that lead him to concluded that the typical interview process did nothing to help select the best candidate. There's a chapter about it in Thinking Fast And Slow [1] and the advice he gives is summarized in this article [2]. I remember thinking after reading this book that it was just a matter of time until everyone everywhere would be denouncing interviews but here we are - old habits die hard.
[1] https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp...
[2] https://www.businessinsider.com/daniel-kahneman-on-hiring-de...
> A vast amount of research offers a promise: you are much more likely to find the best candidate if you use this procedure than if you do what people normally do in such situations, which is to go into the interview unprepared and to make choices by an overall intuitive judgment such as "I looked into his eyes and liked what I saw."
It's comparable to how we laugh at recruiters when they ask for 5 years in a given language that has only been around for 2 years. You clearly don't know what you're talking about.
I always tell the folks I mentor through bootcamps they should figure out which area they like best, focus most of their efforts in that area, and then advertise themselves as a front-end developer or back-end developer or whatever, not full-stack. The upside down T approach. Show recruiters and hiring managers you at least know enough to know what you don't know.
And stop complaining on LinkedIn about how unfair it is that you don't have a million job opportunities pouring in or about all the applications you submitted and didn't hear back from - yes it's annoying, but if you advertise yourself as something you're not, you've likely already wasted someone else's time, so understand they probably don't want to waste anymore giving you an explanation for why you were passed over.
It honestly just amounts to "The most well compensating jobs with the most competition to attain them have a difficult application process, and that is unfair (to me) because of X, Y or Z". These posts are positively dripping in grandiose levels of entitlement.
I've yet to meet a bootcamp grad that can efficiently architect a relational database, for example. I know plenty of Sr. level front-end developers who wouldn't think to call themselves full-stack even though they know how to submit a user form that persists to the database. Same with back-end developers who know HTML, CSS, and pick your flavor of JS framework.
If you've worked in the industry, you know things change too fast to stay up to speed on everything. It's not impossible, but it's unlikely and unrealistic to have that expectation of someone once they are employed.
Suppose your employer wants your web app to interface with an industrial PLC, or fetch data from a car's CAN bus, or talk to a vending machine (ironically the sort of machine that Java was originally designed for).
Most bootcamps don't teach enough fundamentals for someone to figure out how to write both client- and server-side code for those sorts of situations.
Or on the other end of the spectrum, could you write hypervisor code to manage the sort of mass-scale VM deployments behind most cloud providers? It would be very difficult to be an expert on the "full stack", if you think about it.
So...tl;dr, most of the application layer? Probably the physical layer too, any how many of us really work with the link layer?
My company is not a hot Silicon Valley tech company either. It's a dull, boring, investment bank. I am generally not impressed at the quality level of most of the candidates we get when we hire. But still 100% of them are able to code more than well enough to pass FizzBuzz.
Now throw anything beyond the easiest of leetcode easy level questions at them and the majority will struggle. But that is still a level above Fizzbuzz and the like. And most come from backgrounds where the last job they were hired for did not leetcode them, but rather relied on language/framework trivia type interviews.
A few ideas that I think would give these grads some better luck:
- Update your profile to say "Interested in joining a front-end or back-end team" or "tech generalist with a focus on X"
- Elaborate even further in your About section and let people know which of the two you are stronger in and what experience you have
- Swap out "full-stack" for "web developer"
Don't tell me you're something you're not. Under-promise, over deliver. Seeing full-stack on a resume sets my expectations for whoever I'm about to interview regardless of the number of years of experience.
edit: styling
I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.
Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you.
How can we make this work: legal framework. California, if you are listening, pass a law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so.
Would that work?
1. This process is probably going to bias your hiring pool towards young and single people that are willing to either work weekends or use vacation time to go work on a part time job
2. Forcing a company to let an employee work for a competitor opens up a whole new can of worms. This seems game-able in the same way that the Washington DC revolving door is e.g. Uber hires a Tesla autopilot engineer at the cap of 5% of his salary, and after a few years of "contributions" which are totally not industrial espionage they bring him on full-time with an eleventy million dollar signing bonus.
People sometimes want to leave a job and it's in everyones interest for that process to be smooth and pleasant. The leaver has a good final impression of the firm so they recomend it in the future to potential clients or employees, they get support in finding and trialing a new job, and the company to whihc they are seconded gets a low risk trial of a new memeber of staff.
It just seems so grown up compared to the ineffectual thrashing about of tech recruiting.
If you become a contractor rather than a full time employee, the only thing you're missing is benefits/retirement probably, in addition to longer term commitments from an organization (maybe - these days there are no real guarantees).
If you can get benefits/retirement through some other kind of government program or join an independent group that forms together (I remember there was a YC company that was doing this) to pay for group benefits - then why not just go the contractor route?
However, the legal issues sound like a nightmare. Additionally, in the US many people's benefits are tied to their job, so if they needed to, for example, take unpaid leave to do this "test drive" that would also cause complications.
Or do you mean the employee would do this in secret from company A? If so, like the other commenter said, that excludes anyone who can't put in weekend work time.
Obviously no one wants to hire a long term full-time salaried employee on those terms.
Dead Comment
This fundamental problem this article is describing is that recruiters are filtering out too many candidates by pedigree to ever have them end up in an algorithmic interview with a tech company.
My pedigree is average at best. I've worked my entire career at non-tech companies (banks, hedge funds) doing decidedly unsexy work. I'm still able to attract enough attention that FAANG and many other top tech company recruiters contact me first.
Interestingly enough, it's the top companies in my current sector (finance) that refuse to even have an internal recruiter casually speak with me. i.e. Citadel, Two Sigma, Jane Street, etc.
There's also stories I see occasionally on LinkedIn, etc. of people from completely non-technical backgrounds getting hired as SWEs at top tech companies. Taxi drivers, ex-felons, aestheticians, etc. getting hired as SWEs at FAANG and unicorns.
Working at a well-known company can definitely help open doors. It proves that you’ve already completed their challenging interview process and it’s also assumed that you picked up some good engineering practices while working there.
However, pedigree alone won’t get you jobs at most places. You still have to go through the interview so they can see how you perform on a level playing field.
As much as online comments hate the coding challenge interview problems, they’re actually a great thing for people without impressive career pedigrees. It’s the only way you’re going to get to compete on a somewhat level playing field next to the kid who went to an Ivy League and landed all the right internships due to their parents’ connections.
Generally speaking, it’s the people who have jobs at well known companies who want to get rid of coding challenges and go back to hiring based on pedigree, mostly because it benefits them greatly and reduces their competition. In reality, anyone talented enough to work at top companies doesn’t have to study much for coding interviews. This idea that coding interviews are somehow filtering out brilliant engineers and selecting for less qualified people is largely a myth. The reality is that engineers just don’t like being challenged on the spot and would rather employers just trust their resume. That is, if they already have a good resume. The juniors love coding challenges because it’s a way to prove your skills without relying on pedigree or university or family connections.
Majority of the issues are caused by requirements not being communicated, captured, or implemented properly. That's something that's not really focused on tech interviews. I just want a diligent developer who can identify potential issues, do their research, and propose solutions rather than be able to design a system in 90 minutes, because that's never happening in real life. In fact, I'd not hire someone who can claim to do so.
The missing feedback loop from performance review back to the hiring process means that the hiring process can't get fixed. Until companies start adding that process back in, hiring will never get better.
Perhaps though if one looks at the performance review weighted to a review date as soon after the hiring, and sort of tail off how much weight is given over the coming years it'd make sense.
I've just seen a lot of bad hires get better with time. And some good hires lose steam or become jaded and perform worse over time.
Thus, as messed up as it is, one of the keenest signals is tenacity in the end. And ironically tenacity in preparation for interviews (that Leetcode grind) is somewhat correlated with performance reviews in the long run and perhaps correlated with utility to the company.
That said, "decent" engineers in the long run that don't think outside the box but check their performance review boxes slowly bleed a company's ability to disrupt. I.e., performance reviews need to be expanded a bit to think about the health of the overall company and not just the employee performing their function.
As a large tech organization, I'd prefer a complex distribution of performances over an even distribution any day - because value to tech companies is still influenced by more black swan event type of innovation. But then I have a high "beta" (variation) in terms of what I'm looking for. Companies with more of a utility emphasis perhaps are better served by a hiring process that is "reliable" with a lot of false negatives.
If they widen their expectations, and hire people that they believe they can mentor into net contributors, then their hiring practices should reflect this.
There are many ways a company can make hiring more scientific, including A/B testing (ie. hiring people they normally wouldn't, have more data around how productive new hires are, etc) but I've never seen it over than "copy Google and we should be good."
Because of that, you inevitably get "weird" results like seeing that your best employees often did relatively poorly on interviews (Google did a study that produced exactly that result—their best employees often were those that failed 1 or 2 of their interviews).
But this is just selection bias: these are candidates that got hired! Which just means that they were so spectacular in some other respect that they were able to get an offer /despite/ poor interview performance. It tells you nothing actionable about your interview process.
Really you need to take an experimental approach where you randomly give offers to people who failed the interview, and see how they turn out.
Fundamentally, hiring is simply not an easy problem. There's a small cohort of candidates who can be reasonably confident will perform well in a job (mostly people who have performed a similar job at a competitor) that everyone competes over and a marge larger group of candidates whose possible performance is very hard to judge.
You, along with however many other candidates rotate around among different companies. You maybe work for each company up to 1 week. At the end you get your offers and decide among them.
I've ended up working for too many lemons because of lack of visibility into how well put together they really are. I want to know ahead of time whether they really have their ish together or if the interview bubble is just a facade.
Also, at a job fair you have no idea what the day to day life will be in your new position. In my scenario, once you are or aren't hired you will have already lived the life you will be living if you are hired.
Takes about 45 minutes. Pretty simple, the goal is to make sure that they want to do the work that we need done, and that they feel prepared to do so.
So far so good.
How do you get these candidates in the room? Does everyone who applies get an interview?
And how do you decide between candidates? If it’s as you described, it sounds like it’s “first come first serve”.
Yeah, first come first serve.