The real truth is: hiring is a crapshoot. For any position and any field. Software engineering is <i>no</i> different.<p>There is <i>no</i> meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.<p>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?'.<p>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.<p>Given this, why not hire lightly and fire lightly?
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.<p>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.<p>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.<p>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.
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.<p>I work for company A, I'm starting to get slightly bored or interested in doing something else. <i>Without</i> 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.<p>Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you.<p>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.<p>Would that work?
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.<p>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.
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.<p>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.<p>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'd like to see a "speed dating" concept implemented in tech hiring.<p>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.<p>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.
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.<p>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.<p>So far so good.
We shouldn't ask why engineering hiring is broken. We should ask how an industry with broken hiring can succeed. Software engineering has such ludicrous margins that the labor market for software engineers can be ludicrous in equal proportion.<p>The result is that we can bully and cajole smart, capable people, then go on to make 6 figure salaries and makes billions of dollars in revenue.
I'd almost advocate maybe even providing less signaling, like a technical chat-roulette where you get put into a pool and both sides can just "NOPE" out at any time if the interaction isn't sparking joy. Only when you build a rapport talking about the kind of work and challenges does it allow you to say: okay, let's meet later in an attributable fashion for real.<p>Also, bonus points if it involves OTR/PFS so you can talk details without attribution and know that since you're in a "pool" if you got through to an identifiable, in-person interview you can pretend like it never happened, but the candidate and the engineer both at some point definitely interacted in a way that they both felt comfortable proceeding to that point.
Someone here pointed it out on another post a long time ago but the only explanation for the hazing ritual that has become modern hiring is that we have a glut of engineering talent.<p>I'm interested to see what the new trend of remote work will do to the current paradigm. I think the lot of us are about to find we're not much more than highly skilled mechanics.<p>Edit:<p>On reading all the comments that came after mine, I realize I'll have a decision to make Q1 2021 when my role at my current startup becomes financially unwise to maintain (slow growth on a popular product in a very niche industry). Im a co-founder but still it will make more financial sense to put the tech product in Maintenance Mode for awhile with some offshore contractors. All the hard work has been done save for riding out the slow Change The Industry adoption curve.<p>When this day comes I'll be back on the market myself and in considering all this I think Im going to target large F500 companies who's core business isn't tech or internet or whatever. Companies that rely on tech as a part of their larger non-tech business.<p>I know folks who are devs at AMZN and GOOG and I can't help but come away with the impression that save for the RSUs they wouldn't be there either. The pain around getting the offer may not be the worst part - the worst part may be after you accept and actually have to work there. Fairly simple logic might indicate that if the dating phase is this bad, the marriage can't be much better.
Is hiring broken, or is it a symptom of deeper organizational issues?<p>When I browse European startup offers and I interview for some of those positions, I get the feeling that their endless list of requirements has more to do with having high developer turnover and lack of funds to build a team, rather than their CTO's desire to hire a programming demigod.
> In any event, on interviewing.io, once you’ve built up your reputation by doing mock interviews (persistent, meaningful credentialing)<p>Credentials for doing well in interviews, maybe. I can respect the frankness in the following paragraph though:<p>> Of course, one of the limitations of our approach is that we’re getting performance data about engineers from the practice interviews they do on our platform. Any seasoned interviewer will tell you that the signal one gets from a technical interview isn’t the whole story.<p>And really that is another big topic that requires more research imo - interview performance vs job performance.
"If you’ve ever been on either end of the table, you’re probably mad at the state of hiring, too. Whether you have given it a lot of thought or whether you just feel it deep down, something about the whole process feels off."<p>This feels like a really big assumption. Is it true? Is there data to back this?<p>I've felt annoyed at individual interviewers, or a process at a given company but I've in general felt like I got more of a fair shake in the tech world than other industries I've worked in.
There's an old saying: "Don't ever take a fence down until you know the reason it was put up."<p>The phrase "hiring is broken" comes up dozens of times in HN searches. If something appears broken to you, but persists for a long time, it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.
Everybody talks about how hard it is to tell a good engineer from about one. I've been thinking about what exactly that means in terms of our day-to-day.<p>If 10% of the work you're doing this quarter is work that you are going to be doing next quarter, you'll need to be interviewed differently than if 90% of the work you're doing this quarter is work that you're going to be doing next quarter.<p>If the job is narrow and predictable enough, you can just assess somebody's ability to do the tasks you will ultimately need them to do. if the job is broad and unpredictable enough, you have to assess it by proxy. Like how due to the long tail of word usage [0], it's easier to just talk to somebody to see if they are fluent, rather than quizzing them on words.<p>I wonder if software engineering is in some weird anti-sweet spot, where our breadth of work isn't so broad that we really need many year degrees and licenses and boards, but isn't narrow enough that you can just assess somebody on the actual duties you want them to be performing.<p>Not to mention that different jobs in the field really do have different degrees of unpredictability/variety, so the breadth experienced in a few years at one shop would be completely different from the narrowness experienced in a few years at another, so a resume doesn't you tell as much as you'd hope.<p>[0] A full 50% of the words in <i>Tom Sawyer</i> only occur once, for example. It's why teaching languages can only go so far, and you really just get lots of experience using a language to become proficient.
My problems with hiring:<p>1. Resume forms. Just accept a resume. I don't have time to fill out your form that requires exact months.
2. Not hearing back. Its not hard to send a response. The ones I really hate are "we get so many responses so we'll only contact you if we like you!" come one
3. Bad recruiters. The ones who just email and call about being an automotive technician when I'm an infrastructure engineer.
I've been known to write egregiously long comments, emails, articles, but good good is this article overly long. I was really ready to blow it off when I realized -- the author is putting her money where her mouth is. She's built a very useful platform that helps connect real people with real job opportunities.<p>Okay. In that case, I can forgive the "cardinal sin" of bad writing. Here's the problem with hiring: organizations. Hiring practices reflect organizational ladders and career progressions. Where you see flaws in the latter, of course it will backpropagate into the former. The problem with a "platonic ideal" for how engineering hiring should work is that it requires a "platonic ideal" for how a company should work. And what is that?<p>How do you avoid politics as you scale up a company? Sure, engineering skills are fungibly valuable, that much is evidenced by the market. But engineering career output, and promotional success -- that part is very circumstantial and specific to the company. And I would argue hiring is part of that process -- hiring is getting promoted from candidate to employee. Every company does it differently. And the dynamics are not platonic but tribal. There's no way around that but to find the tribe you want to be a part of and accept it's a little irrational.<p>I remember wishing and hoping when I was younger for a platonic ideal for engineering hiring and engineering organizations that never came. I grew to understand that the warfield of political economy that the business existed inside of (including and especially non-technical and executive personnel) had so much of a major impact on what engineering even means that to conceive of its retraction or engineering in isolation was a little naive and unrealistic. Is it cynical for me to say that? Is it bad for me to say that?
> Or wonder why we think we can succeed where so many others have failed. But, before you do, think on this. I’ve spent the last five years of my life dedicated to bringing this vision of hiring to fruition because I believe, in my heart of hearts, that this is the only way hiring can be both efficient and fair.<p>When your best argument is "trust me I know" usually this doesnt mean any good
Hiring is just one of many things that the big G has made worse for the tech field. I wish people would stop idolizing them and see the negative influence they have had on our profession.
> Breaking character for a moment, a friend of mine recently got this recruiting email from Google, who has elevated gaslighting to an art form: somehow the fact that it takes two months to get through their process has become a selling point.<p>The quoted email in no way supports this statement.
Recruiters are often a necessary evil - they act as a filter to find the "smart people" and for smart people to find the good roles.<p>1. Finding a good recruiter is as hard or harder than finding a good employee - only do it if you expect to be recruiting for multiple roles over a period.<p>2. Think a lot about what you're looking for in an engineer, how you'll evaluate candidates, what experience will be shows for the talents you need and then how to articulate that to the recruiter. When they send CVs/resumes make sure you give feedback on what are the bad and good qualities.<p>3. When recruiting I've nearly always gone via recruiters that have gotten me roles or have worked with in the past (or atleast through them to someone else in their organisation).
Hiring is broken period, not jut for engineers.<p>I could whine on about this topic for days, I ran an IT Division that supported HR for a very large company, and we built a slick streamlined system that worked great, in spite of what HR wanted. The two things that drive me crazy when applying for a job<p>1) keyword matching metrics, UGH!! It's not an effective filter. If you really want to filter candidates have a job specific requirements questionnaire. As a hiring manager I'd much rather create <i>my</i> filter questionnaire.<p>2)Using the resume submission process to complete the employment application form <DUMBEST IDEA EVER>, it can be a two step process, REALLY IT CAN BE A TWO STEP PROCESS!<p>NOBODY READS THE EMPLOYMENT APPLICATION FORM, it has nothing to do with screening candidates. If you want to interview a candidate THEN have them complete the employment form.
This is a pretty good breakdown of the dynamics of software engineering hiring, even if I don't follow to her conclusions.<p>It seems like "abstraction" is a recurring theme. The hiring manager is abstracted from the job description by the recruiter. Whether by institutional affiliation or passing a quiz, candidates are abstracted into punch cards that can be fed through the system.<p>Furthermore there's a seemingly overwhelming institutional bias for companies to congratulate themselves on making the right hire, and for their employees for being the right hires, that the whole thing becomes kind of circular.
TLDR<p>Interviewing.io is different from other recruiting startups because verified candidates get to directly book time slots with engineers at companies. Candidates get verified by taking multiple mock interviews (more data points).<p>Other competitors, such as Triplebyte, still have a recruiter in between interview and company. Even after you get verified and have good performance on the Triplebyte quiz and interview, there is still a recruiter who acts as a gatekeeper. That recruiter can prevent you from speaking to companies even if your interview performance was 99% percentile.
> I could try some job boards to see which companies are out there. But what would I filter on? I know a lot of programming languages but am not set on having to work in a specific one. How can I tell if I’ll hit it off with the team? I’m applying via a job board to a position I know next to nothing about — will anyone even respond?<p>Man I really can't stand job boards. I feel like the only way to make a good job board would have to aggressively vet companies posting jobs, which ofc would lead to it being very barren.
I'm convinced that there is no generalized "right" way to do hiring - for engineers or otherwise. Considering "engineers" as a monolith is silly and the diversity of engineers makes any attempt to generalize fail.<p>Different types of people fit into different cultures and work styles.<p>If there's anything at all that I would generalize on, it would be: "Be candid about your work culture if hiring and don't try to work some place that doesn't fit your style if applying."
If there's anyone that I'd listen to talk about this, it's Aline. She's a shining example of something I think patio11 once wrote: dogged learning about one topic is bound to produce value sooner or later. You just need to spend enough time learning where the pain points are, and build something that solves them.<p>She's been turning this crank for years, and I believe her when she cites interviewing.io having a 40% successful place rate.
Why did the title change (on HN)? It now no longer matches the original article ("I’ve been an engineer and a recruiter. Hiring is broken. Here’s why… and what it should be like instead.") - contrary to HN guidelines[0]<p>[0]: <a href="https://news.ycombinator.com/newsguidelines.html" rel="nofollow">https://news.ycombinator.com/newsguidelines.html</a>
How come when I login to my interviewing.io account I don't see Twitter but it's shown in the screenshot? Is that an accurate representation? I do see the other companies from the screenshot but with fewer jobs.
> Breaking character for a moment, a friend of mine recently got this recruiting email from Google, who has elevated gaslighting to an art form<p>God I love Aline's stuff.
This is a really long article. The author should consider putting a TLDR at the top. Manged to read only half of it and still didn't get the point.
anecdata here:<p>I once was asked to explain the difference between 2 functions in a standard library that I don't think I had ever used.<p>That was the only question I was asked. They completely wrote me off as soon as I couldn't answer the question.<p>If they had just asked me to write an entire app from scratch (not counting frameworks) I could've done that for them no problem :)
> They wisely rejected pedigree as a viable means of credentialing and adopted the admirable mission of democratizing access to opportunity in software engineering.<p>You know that college admissions are just as "democratic" as somebody's online testing process, right? As in, anybody can take the test and if they pass, they get admitted? Like... they're exactly the same concept?
God I am so sick of hearing "hiring is broken". Not that I necessarily disagree, but this is the first sentence of every single recruiting startup pitch. (And spoiler alert- none of them have fixed it) It comes off tongue in cheek to me now.