The "provisional employment" idea sounds good at first, until you think about how it would actually work in practice. You have 100 applicants for 1 position. Which one do you provisionally hire?
Ah of course, we have to do a traditional interview loop to evaluate 10 candidates before we can pick one. So you do the traditional interview loop, and then you have 6 months of provisional employment.
You haven't replaced anything, you've just added another level of hassle for everyone.
It's an obstacle when hiring people who are currently enjoying stable employment. Probably fine for juniors, but not for experienced people with families and whatnot.
I think you've just lowered the risk of a bad hire for the company, which might allow them to "take a chance" on candidates they might otherwise pass on.
I gave the feedback at one Google interview that they should send Google employees through to see how many get hired. Good to see they basically tried that.
The conclusion at the end that bringing someone on board is the ideal method is true I'm sure, but even that runs into the issue that employee evaluation is an even worse situation than the interview process.
You can openly see some managers panic when they realize they have no idea what their employees have been doing for the last 6-12 months when they're asked to provide feedback.
1) The worst interview I ever had (BY FAR) was at Google--disrespectful people, no respect for time, I could go on and on. And I went back to try again to get that money showered on me. Worth it in the long run.
2) Their new system for "performance management" is a hoax. Just like at all other places, it "documents" what you should do so they can fire you more easily with unspoken rules and all sorts of arbitrary causes as well. A friend literally hit EVERY pre-agreed target and still got pushed out for "not delivering".
I once failed all my goals agreed upon a year ago but got promoted anyways, because priorities had shifted and the director above me just really, really wanted me to continue building his reputation. (not at google)
They told me it was all about pseudocode and how I think in advance, then on the actual interview they were being annoying about variable names and spaces after comma, while I was supposed to come up with some clever optimisation that boiled down to: "do you know this obscure theorem already? Cool you pass"
> I gave the feedback at one Google interview that they should send Google employees through to see how many get hired. Good to see they basically tried that.
They did, but not with the intention of doing anything about the problem.
This is a question of reliability, the conceptual 'correlation' of a measurement instrument with itself when measuring the same thing.
Reliability is one of two major concepts in psychometrics, the other being validity, the conceptual correlation between a measurement instrument and that part of reality that you're hoping to measure.
The question behind validity is "I want to know X; if I measure Y, how helpful will that be?". And the question behind reliability is "if I measure Z, how accurate will that measurement be?"
Yegge calls out both concepts explicitly, though not by name, in this essay:
>> The outcomes from interviewing are statistically terrible. Google did wave upon wave of analysis over the years, and all the results were incredibly depressing.
>> [reliability] To name just a few off the top of my head: interviewers barely agreed with each other. Put the same candidate in front of two of our sharpest people and you’d routinely get a confident “strong hire” from one and a flat “no” from the other.
>> [validity, though the 'problem' here is strongly confounded by a restriction of range issue] And once people were actually on the job, their interview scores told you next to nothing about how they’d do
>> [reliability] Hell, some of our star performers failed their Google interviews four or five times, finally got in after 2+ years...
>> [validity] ...and then outshone everyone else.
The discussion of how interviewing outcomes are statistically terrible would benefit from naming the ways in which they're statistically terrible. Knowing the problem you have is an important step toward solving it.
(And as a side note, the last I heard from Google, you're not allowed to interview more often than once a year. Interviewing five times in two years would seem to violate that policy.)
It is a basic theorem that the validity of any instrument is bounded above by the square root of the reliability. It isn't possible for an unreliable instrument to be tightly correlated to reality, because it is, by definition, not tightly correlated with anything. That's what it means to be unreliable.
Thus, any company that wanted its hiring process to be good would necessarily be extremely concerned with making that process accurate; you need to come to the same decision when you assess the same person. This is something that interviews cannot achieve except at extreme cost. You'd need far more than five interviews to get a reliable assessment from them, despite the claim in this essay that "any more than four interviews and you're just playin' with your food". Of course, the Google interviews aren't supposed to be reliable anyway, so in that sense the claim is probably accurate.
The prescription Yegge offers is valid. Multi-month work assessments will give you a strong, reliable, and valid signal. They're also very expensive.
Another thing the essay completely glosses over is that this problem has been recognized for a long time, and we already know how to do assessments that are reliable, valid, and cheap to perform. They're called standardized tests.
At least historically, Google prioritized not hiring bad candidates over hiring good candidates. So it was neither a priority for interviews to be consistent (for good candidates) or for employees to be able to consistently pass interviews.
The tests that carry the particular branding "IQ" (Wechsler / Raven's / etc.) suffer from some problems in this regard - not very many questions exist and there are very large coaching effects. Hiring from a test that measures IQ is a very good idea (and there is a test that's commonly used for hiring purposes, the Wonderlic, though the ceiling of the Wonderlic isn't that high); hiring from "an IQ test" is a bit less good.
The concept of "IQ" can be toxic in contemporary American politics, so there are many more tests that "happen" to test IQ than there are tests that advertise themselves as testing IQ.
The gold standard in hiring qualification is work-sample testing. It works fine. You do not need to "make hiring a profit center" or "provisionally hire" or do internships. Work samples done correctly demand less time from candidates than interviews and scale better than interviews. They are standardizable and iterable.
What I feel like I'm reading here is someone who has been poisoned by FAANG hiring practices --- and they are terrible --- and has missed most of the work that's been done (outside of Google's admirable work in debunking their own processes).
I appreciate the "kitchen confidential" here, but with respect to Yegge, I think he's been working at the Olive Garden this whole time. Go stage at Gramercy Tavern! They're working at a different scale, yes, but you'll at least get a different perspective on the "gold standard".
I'm a little bit more on the fence with the work sample interviews having designed them and also interviewed through them. I've also done my fair share of "traditional" tech interviews, all at startups, never FAANG.
As an interviewer, I much prefer the signals generated through a work-sample interview. I'm much more confident in the hiring recommendation than I get from a 1 hour zoom session. However, if I look at teams that were built through the work-sample and zoom interviews, I'm not sure the outcomes were that noticeably better.
As an interviewee, I think I understand the frustration being on the other side has. With an in-person interview, I often have a good sense that I bombed the interview or something to improve on or replay in my head, less surprising outcomes. On the work samples it's harder to know whether you're making mistakes, or are being out-competed by someone putting in 4 times the effort to polish the solution beyond what their regular work product would be. Although I had one really good outcome where the work-sample interview really flagged the internal dysfunction of a company.
And then with both interview processes, I still think there is a really big unknown on what the false no-hire rate is, how much effort is getting wasted rejecting candidates that would actually fit the team.
So having to choose a process as an interviewer, I'm with you and would always choose a work-sample interview. On whether it should be considered the "gold standard", I'm much more hesitant, I think there are some limitations that are still hard to control for.
I do wish Starfighter/Stockfighter model had gained more traction, would've been interesting to see a recruiting company specialize in this and then seeding the interview results to multiple companies model work out.
The problem with work-sample testing (which is commonly administered as a take-home problem for the developer candidate to solve) is two-fold:
a) it discriminates against people who cannot spare 4+ hours of focused time on evenings/weekends to work on the problem. People with multiple jobs, single parents, etc.
b) in the age of AI it is no longer a reliable measure of someone's skill, for obvious reasons
Unlike Yegge, I haven't worked at FAANG, but the companies I have worked at all followed the same hiring practices and suffered from the same problems as he describes.
Provisional employment (or, if that's not possible, then well-paid internships) solve all of those issues. The candidate gets 3-6 months of stable employment, you as the employer get a large number of work-sample tests, and you can see how they use AI and how much.
I think a very real problem is that these take home problems are often way more than 4 hours. And to that they often add the traditional 4-6 hour interview loop.
Provisional employment doesn’t work for most cases, though. It might attract people who have no job and it might attract people who have so much saved that they are okay with potentially being let go after 90
days. But I imagine the vast majority of the potential employment pool are not willing to quit their current job to accept a “maybe” job from another company.
Adding take-home problems to a traditional 4-6 hour interview loop is odious.
But the "way more than 4 hours" thing smuggles in a premise: that every candidate should be able to finish the challenge in the allotted time. But candidates with greater aptitude or conversance with the problem domain will complete work sample tests faster than candidates without, and selecting for those candidates is the point of hiring qualification.
This is theoretically true but it’s also rife with misaligned priorities. The people putting together these take home assignments have little incentive to ensure that they can be completed by a competent engineer in the allotted time. The engineers completing these assignments are definitely incentivized to underreport how long they spent on the assignment.
With AI coding this is also largely useless. These “build this thing in 4 hours” assignments come with a literal prepared prompt so that they can be churned out in 10 minutes.
We don't ask or check how long candidates take. You're a professional, we give you a challenge, you can decide (up front, 30 minutes in, whatever) whether you're likely to be able to finish in the budgeted time. Maybe you can't because you've got a lunch date and don't have the contiguous block, and want to do it in chunks. Fine by us.
Again, the underlying smuggled premise here is that candidates have to finish the work sample. No they don't. In fact, that's a strong sign it's not an effective work sample. A test that everybody passes isn't a real test; it's just a hazing ritual.
Just anecdotally, I can confirm that this method works great - it screened me out by showing me exactly what day to day work was like at your company, and that I was not nearly nerdy enough about specifically containerization to want to do it all day.
So you saved yourself/the team several possible hours of interviewing, and me quite a few hours - I think it took me about 10 to 15 minutes to see what you wanted in an engineer and that I was not it, and a total of 1 email which felt quite automated (whether it was or not) so there was a very low social cost as well.
You are assuming the assignment is reasonable and the candidate is lacking if they cannot complete in the expected time. And for all I know that’s entirely true for you. What I know is that I’ve seen assignments from others where the assignment scope was unreasonable for the allotted time. And for those teams, the filter becomes not so much “is this person capable” but “is this person willing to put up with our shit”, and the teams likely don’t even realize that’s what they’ve done (because they also “don't ask or check how long candidates take”).
> Again, the underlying smuggled premise here is that candidates have to finish the work sample. No they don't. In fact, that's a strong sign it's not an effective work sample. A test that everybody passes isn't a real test; it's just a hazing ritual.
Now this is an interesting take. Usually when people talk about these take home assignments, they talk about assessing the quality of the work. How good is the design? How is the coding? Is it efficient/elegant/whatever?
Here you take a much different approach, saying that the completion itself is the filter. If one person completes your assignment in the allotted 2 hours and another needs 12 but never tells you that, do you not care about that discrepancy?
We do assess all of those things. Again: you're a professional. We give you a work sample test. You look at it, and use your best professional judgement to decide if it is (a) reasonable and (b) doable in the budgeted time given your capabilities. If either is untrue, you don't do the work sample.
I'm having a real hard time seeing how this isn't strictly better than an interview, which, as the article (and basically everything written in the last year about interviews) points out, is basically a random function.
A standard interview loop kills an entire work day, and is preceded by phone interviews that eat several hours. Properly budgeted work samples are strictly better from the candidate's time perspective, not to mention that you can do them from your couch rather than under flourescent lights in a confeence room.
The AI thing is an interesting problem, but a solvable one. We continue to hire resume-blind.
The question is whether companies would tolerate their own process if their employees did that recruiting process at a different company. They obviously do to some extent via plausible deniability; I have a 1 hour "doctors" appointment this afternoon, or I'm taking leave on Monday. Using it as cover to attend an interview.
Would this company permit an employee taking 3 months unpaid leave to provisional hire somewhere else and have free choice whether they stay or go at the end of it.
I feel like you could get around the AI bit by asking about components and what they do, rationale for decisions, etc. If someone can't speak to it, it should be a clear tell.
We hire entirely based on work sample testing, and there's a lot of stuff you can do to make it work in with AI-equipped candidates; I'm not prepared to write it up at the moment, but you start by recognizing that everybody is going to be using AI and designing the tests accordingly, and by relying on unassisted interactive challenges as a component of the process.
>> A standard interview loop kills an entire work day, and is preceded by phone interviews that eat several hours. Properly budgeted work samples are strictly better from the candidate's time perspective, not to mention that you can do them from your couch rather than under flourescent lights in a confeence room.
Yes, standard interview loops also discriminate, and the more time they take, the more discriminatory they are. Any on-site requirements compound the issues.
Like Yegge says: provisional employment/internships solve all of these issues. You get the best of all worlds: stable employment for the candidate where they get paid a regular wage and aren't under a stressful interview setting, and lots and lots of work samples for you, the employer. It's not perfect. For example, it can be difficult to entrust the provisional employee/intern with anything impactful if you don't know whether they'll be employed at the end. But it is significantly better than the alternatives in most contexts.
Provisional employment does not work. It requires candidates to leave their jobs before they know whether they have a secure job with your firm. I concede that provisional hires are higher-signal than work sample testing (or rather: that they're the platonic ideal of work sample testing), but the entire problem of hiring qualification is to make decisions in the context of a candidate doing a job search.
>> Provisional employment does not work. It requires candidates to leave their jobs before they know whether they have a secure job with your firm.
It works. I’ve seen it in two different places.
At the second one, the fundamental realization I came to was that it is virtually no different than “regular” employment, where the new employee can get fired for not meeting expectations within an arbitrary time period after being hired. This can be months, or even weeks. From the perspective of the candidate, regular employment and provisional employment have roughly the same level of risk: in both cases they take a job where they might be let go at some point. The benefit of provisional employment is that they know how long they will be evaluated for and against whom. It turns out a lot of candidates do in fact like the all-cards-on-the-table approach and enjoy being given the opportunity to prove themselves on the job.
Everything will "work" in the sense of you'll eventually get somebody in the job. To me, it's self-evident that a process that disqualifies everybody unwilling to work for weeks speculatively isn't actually working, at a minimum because it DQs most (probably all) competitive candidates. But yes, your mileage may vary.
I couldn't find the text of this joke, attributed to Dirac. I'll paraphrase.
A man walks into a pet store. There's a parrot for $100, it says this parrot speaks perfect English . The one next to it is $1,000, and says, This parrot speaks 12 languages fluently.
Then there's a bedraggled looking, droopy, parrot, and its label simply says One Million Dollars.
Does it sing opera and has successfully run for President? the man asks with a sneer.
This parrot, says the store owner, _thinks_.
That's what this entire post is about - how to evaluate people with a series of attributes, score, correlate, blah blah blah.
Hire them, see if they think. If they don't, fire them. It's cheaper than this credential/signal rigmarole, most of which is about CYA legal b+llsh1t. Yes, it's a simplistic strategy and it doesn't work for Shoogle, Banthropic, Goober, whatever. You know what, boo f*cking hoo. You're a trillion dollar company, suck it up. You have a zombie horde at your doors and you're just upset the "true gems" are hard for you to spot amongst the slavering masses. You're going to heartlessly lay them off anyway in a few years. You SHOULD feel this pain and anguish of having to sort through them, constantly regretting all your choices. That's the only way to have balance in the Universe.
There’s an old Malcom Gladwell podcast episode, I think the show was Revisionist History, where he says he’s an interview nihilist. As long as the person seems reasonably capable, and can probably do a bit of what you need, hire them. Interviews are so hard to get right that what you’re saying ends up being most effective.
Unfortunately from an organizational perspective, a bad hire could cause so much damage through incompetence let alone malice, that making no hire the default unless they're a perfect cinnamon roll of a fit, is actually a good strategy.
> a bad hire could cause so much damage through incompetence let alone malice
The fact that an organization cannot deal with such a case is a bigger problem in the first place. Eliminating incompetence and malice is among the basic skills of an organization.
Everyone is annoyed when Google or whatever has a gruelling high bar to get in, but nobody bats a lid when say Jane Street does it. Both wildly successful.
Because Jane Street is unabashed about greed, and yet they do not let that greed lead them into attempting to pollute and derive us of our attention every day.
The industry should get down from its egocentric ivory tower and start hiring like other industries. You are not special, tech. Just have a sort of bar exam you have to take every x amount of years. The actual interview should just be an in-person behavioral one, with your future boss. Period. Don't get enough signal from that? Sorry, that's life, taking risks. Imagine trying to open a business without taking risks, and only kickstart it once you are a 100% sure it will work. No other industry is as delusional. Here is a reality pill: what you are asking, a 100% safe investment, is impossible, as any economist will tell you. "Campfire", give me a break, grown up adults with families don't have time for that Silicon Valley wankery, and you have no evidence that the results will be as good and unbiased as you think they'll be...thanks for bringing attention to the subject though, and in passsing also confirming how garbage the Google (and FAANG, in general) hiring process really is.
Just one more thing: the industry should really put a bit more weight on measuring people's potential and the concept of long-term growing and learning on the job. Just saying. You know, like every other industry on this planet.
Very well thought and written. Provisional employee or intern. Or having the candidate to come and do real work for a couple of days. The challenge imo is the big company culture vs startups. Do the things move at the pace in big companies where the teams have the ability to evaluate? Startups are a different beast however.
The paradox that strikes me is that "hiring is broken" yet these companies are beyond successful. So there's still yet another layer of something in between observing that employees are capable / incapable, and the company successful / unsuccessful.
Seconded, stop the theatrics and gatekeeping and let's keep a growth mindset while training / retraining those who 'pass the buck' overtime. At least everyone can get skills and talented outliers will find themselves with more structure and collectively we'll produce better outcomes for more engineers at multiple levels of experience.
> Another reason is that on the supply side, nobody wants to sign up to do a bunch of free work just to be rejected. If you just put up work, the candidates incur all the risk, meaning they walk away with nothing if you don’t hire them.
It's true, but prepping for a typical senior+ onsite loop in big tech still requires weeks of grinding leetcode, re-learning the latest system interview questions and the system interview answer framework, refreshing and rehearsing STAR stories, studying the company and its unique quirks that you're expected to know to pass the culture filter, remembering how to do all of this speedrun-style since you only get 40ish minutes per session, etc.
While that knowledge is more reusable across onsites, it's likely even more work than doing real or pretend-work for the company for a couple of days.
> When candidates get to walk away with something of lasting value that they can keep forever
I'm curious why them getting rejected from the position, even with the work sample they can carry away with them, wouldn't be still interpreted as a negative from future employers. "The other co passed on them, am I the fool for thinking they're good?" type of herd mentality which is often unavoidable.
Won't that "work sample guest book" be treated as the list of all companies that rejected you, a net negative for your personal brand you're projecting?
> (Me paraphrasing what Steve was implying) Take-homes are impacted by AI one-shotting them for candidates
I've been pleasantly surprised by how much you can glean from having the candidate upload their conversation log with the coding agent for whatever take-home you give them.
I was going to scoff at the amount of interview prep you said is required but then I remembered I read the book written by the founders of my current company before the interview.
His idea has some merit but will require the old system to completely crash out before anything new will be considered and I'm not sure if it will crash or just keep limping along. If it really does crash out hopefully we will see multiple new strategies emerge as there are many possible options once the current one is off the table.
As yegge mentioned, there might be more appetite for trying out this idea now because there are many engineers who are currently unemployed. Offering them short co-op could be beneficial to both the engineer and prospective employer
I don't understand how a failing stamp for a campfire is good for the interviewee. It signals that they weren't good enough to get hired. Why would they want to parade that around?
I had the same thought. "I didn't get hired at X! I didn't get hired at Y!" It's like how people write ex-Google, ex-Amazon in their headlines but worse: failed-OpenAI, couldn't-get-in-to-Anthropic. Let's all get around the campfire and sing kumbaya
A lot in here about Google, which hilariously has done a bunch of studies that concluded it's hiring process is awful (is sure is!) and the takeaway is that candidate evaluation is impossible, not that Google in particular does it badly.
The current interview process isn’t meant to get the best talent, its intention is to give managers on visas an easy way to bring in other visa workers (via sharing questions and scaling difficulty for no-visa applicants)
> One day, the recruiters gave us a special round of packets to review. In these special packets, we were able to read the interviewer notes and candidate responses. All personal details were stripped out, and we were told it was a “calibration exercise.” We had to do our regular voting job with these special packets, and see how it went. I think we may have assumed they were from another site, since cross-site calibration was common.
Our group did our job, and voted not to hire about 2/3 of the packets. This was about par for the course.
But surprise surprise, this time, those were our own packets from when we had all interviewed at Google. The recruiters had tricked us into reviewing our own interview packets, and we had voted not to hire most of our own group.
For that brief moment, we all had a glimpse into how utterly broken our process was. The people-team had rubbed our noses in it.
Or maybe the company changed in the 10 years or so since everyone in that room was hired and the employee needed 10 years ago is not the same as the ones needed now?
The most talent dense place I've worked had a dead simple process - two one hour chats, one with your potential manager/team and one with the CTO or CEO. If things didn't work out, well you got sent away, probably happened twice per month. There was a particular meeting the CTO/CEO used and if you saw someone meeting with them there on a Friday afternoon, you would not see that person on Monday.
The place was not big - never got much beyond 100 engineers, but produced dozens of founders, VPs, GMs etc at well known companies, as well as engineers with very notable OS projects and lots of high-placed engineering in FAANG companies.
I think interview is part of tech life where I feel very, very bitter at.
Warning, sad boi rant ahead.
I was from a programming bootcamp. I entered the tech because I was the only person in my bigger family members who have the skills/education/chance to earn a big salary. I still remember, I paid $12k back then, and it was me and my mom's only savings. I started tech in my 30s, and mostly worked physical labor work before that.
I was the weakest at that cohort, but I studied really, really hard, until the bootcamp noticed my progress and hired me, albeit at a very low salary. That was my first programming job.
I eventually learned about big tech, and liked the fact that they didn't care about credentials, whether I came from a good university or not, unlike the YC combinator startups who mostly cared about credentials. I learned that they pay really well, and I did, read Steve's blog, "Get that job at Google". It motivated me to study DS&A, and also to get CompSci degree.
Overtime, I lost count, how many interviews I have failed at big tech. I gained more experience, I became older, but I kept studying, and studying, and studying, but I keep failing. I also wasn't sure which area to study, so I ended up studying for everything, from frontend to backend. It was a lot, really, a lot of things to study, from leetcode to JS specific to DOM to backend system design to frontend system design, to behavioral, and frontend interviews back then was still a crapshoot, some companies ask for deep JS/DOM questions, some companies just ask for leetcode questions.
But I kept failing.
I think I'm pretty good, or at least, that's what I thought. I learned quickly, I have no problems for clearing mid level leetcode questions in under 20 mins. Overtime, the bar gets really hard and it became hard level leetcode questions in under 20 mins.
But what made me really bitter over all of these interviews, was that I saw my friends, people I knew, from programming bootcamp, from my CompSci degree, got a job at big tech. I knew, or at least, what's what I thought, that they had less skills than me in programming and in DS&A. But they got into big tech. Some of them were minorities, and during that time, diversity hiring was a thing, and maybe that's why they got in, I thought to myself.
Sometimes I asked them what the interview questions were, and to my surprise, it was easier than my questions. Idk why.
Sometimes I wonder if my luck in interviewing is really bad. I tried everything I could. I bought courses and devour those materials. It's been years and years and years and years. It did wear down on me. I want to cry, which I did sometimes due to keep failing big tech interviews. But it won't do me anything, I can only keep my head down and keep trying.
I ended up making pretty good money in this field, and able to help my family members. I did work with some of those big tech engineers. I realized that those big tech engineers were just average, and I don't think I am less capable than them. That made it sucked even more, because I don't understand why I kept failing, and why the people I know are succeeding.
I do some freelance now, but will finish some of my contract. The job market is scary, and one of my contract will finish soon. I am having hard time getting even recruiters to contact me, maybe because I don't have big tech credentials.
I also did mostly fullstack/frontend leaning lately so I ended up studying frontend interviews. But frontend job market is kinda dying lately, since most companies don't really respect frontend and don't think its worth it anymore. These days, I don't even know what to study anymore, so I need to study everything again, with the addition of all the AI stuffs.
I can't help but to think, and always think even today, especially during this tough economic times, what if I was able to get the big tech job. My family would be proud of me. I would have better companies in my resume, and could stand out more in the job market. I could've done some cool highly scalable projects that I can boast of in my resume. I could've joined some good team, mentored by good engineers. I would have more savings than now.
These days it doesn't matter anymore. The big tech salary era already closed. Things are way way more competitive than before. With my average background, I don't stand even a chance at being asked to interview.
Life is really a mystery. Things that you really need or want, you don't get it no matter how hard you try. But it is wasted away on those who got it.
I usually don't post comments, but seeing this post, I just needed to vent.
Honestly, it was probably just your age. Being in your 30s, an entry-level coding job at Google or other big tech company just isn't going to happen. Those companies all have a lot of ageism especially in the coding ranks.
Steve Yegge is one of my very favorite authors I love his work. But lots of things to say here.
FIRST - is that before you get to campfire anyone, you have to have done some sort of interview process to boil it down to the one person to do the campfire - so how does that work eh?
SECOND - campfire is deeply invasive to the candidate's life and time.
THIRD - you have to pretty damn sure someone is a hire before doing a campfire. You CANNOT do campfire as an evaluation step, after which there are more interviews.
FOURTH - this is effectively just a really really long version of the take home work test which is absolute bullshit.
FIFTH - there's STILL no science to the campfire. Don't give anyone a fucking test if you don't actually know how to scientifically evaluate the results. And campfire does NOT result in a scientific outcome, it still results in an arbitrary opinion.
SIXTH - any company that wants me to do a campfire - to commit days or even weeks of work as part of them trying to decide to offer me a job - can fuck off. Sorry, the party got spoiled by all the other companies who asked me to do something as part of the interview process and then either ghosted me or gave me some bullshit outcome like "they didn't like your work".
I can tell you how to recruit people and it does not require campfire.
You TALK to people about software development - you engage them in extended conversation about what they have done, what they know, what their interests are, what they have built, what projects they worked on, what went right, what went wrong. You look for people who have BUILT STUFF - this was true before AI and is 100X more true now - anyone who has not built anything today is not worth employing and anyone who has built something must be able to talk about it in depth. This interview processes worked before AI and it works after AI. And finally, you accept the limitations of recruiting which is that people are people and you won't find out how well someone performs until they have been on the job six months - live with it.
Sorry Steve - I love your work but I'd never work for any company that wanted me to do a stupid campfire because they don't know how to actually work out if I can do the job or not.
why not? to expensive? candidates don't have the time? i'd love to do that because it also gives me insights into the company. how they work, etc...
I can tell you how to recruit people
why is interviewing broken then?
You TALK to people about software development
didn't we try that and find out that the sweet-talkers master this and are able to fool everyone? or didn't we find that this leaves out good people who don't do well when questioned like that?
btw: my personal preference for a tech interview is 1 hour of pair programming. (not just live coding)
I think you're largely right - but there are some challenges.
Talking requires that the interviewer be competent and care. Which seems like a low bar, but it easily degrades. When an engineer is burned out, or is interviewing for a project they have less stake in, or has business requirements forcing them to hire someone fast, the bar lowers. Those engineers now are the gatekeepers, and they let in even weaker engineers.
Even worse, any utility from this is predicated on the founder making good hiring decisions. If they don't understand how to hire a competent engineer and make them care about the company, then it's dead from the start. And a lot of founders or execs in general are awful at this.
Companies that maintain an excellent work culture such that engineers deeply care about the team and have stake in any project they conduct interviews for will do well with this model. I hope we see it used by them.
This sandwich is huge but the bread layers (top and bottom) are moldy, love the empathetic writing style though. Agree on your TALK paragraph - mostly - as well. Make sure to consider juniors in that lumping too though, we can't have systemic failure over time. AI-outcomes are not guaranteed.
It’s interesting, this guy has a Wikipedia page but no achievements on it. It seems like his whole career has just been moving around and bullshitting about how great he is. I kind of expected to actually see an achievement on there, like inventing a programming language or developing something important.
The "provisional employment" idea sounds good at first, until you think about how it would actually work in practice. You have 100 applicants for 1 position. Which one do you provisionally hire?
Ah of course, we have to do a traditional interview loop to evaluate 10 candidates before we can pick one. So you do the traditional interview loop, and then you have 6 months of provisional employment.
You haven't replaced anything, you've just added another level of hassle for everyone.
It's an obstacle when hiring people who are currently enjoying stable employment. Probably fine for juniors, but not for experienced people with families and whatnot.
That is directly addressed in the article.
I think you've just lowered the risk of a bad hire for the company, which might allow them to "take a chance" on candidates they might otherwise pass on.
I gave the feedback at one Google interview that they should send Google employees through to see how many get hired. Good to see they basically tried that.
The conclusion at the end that bringing someone on board is the ideal method is true I'm sure, but even that runs into the issue that employee evaluation is an even worse situation than the interview process.
You can openly see some managers panic when they realize they have no idea what their employees have been doing for the last 6-12 months when they're asked to provide feedback.
2 anecdotes ...
1) The worst interview I ever had (BY FAR) was at Google--disrespectful people, no respect for time, I could go on and on. And I went back to try again to get that money showered on me. Worth it in the long run.
2) Their new system for "performance management" is a hoax. Just like at all other places, it "documents" what you should do so they can fire you more easily with unspoken rules and all sorts of arbitrary causes as well. A friend literally hit EVERY pre-agreed target and still got pushed out for "not delivering".
I once failed all my goals agreed upon a year ago but got promoted anyways, because priorities had shifted and the director above me just really, really wanted me to continue building his reputation. (not at google)
Oh I've had a terrible interview at Google too!
They told me it was all about pseudocode and how I think in advance, then on the actual interview they were being annoying about variable names and spaces after comma, while I was supposed to come up with some clever optimisation that boiled down to: "do you know this obscure theorem already? Cool you pass"
Which theorem?
> I gave the feedback at one Google interview that they should send Google employees through to see how many get hired. Good to see they basically tried that.
They did, but not with the intention of doing anything about the problem.
This is a question of reliability, the conceptual 'correlation' of a measurement instrument with itself when measuring the same thing.
Reliability is one of two major concepts in psychometrics, the other being validity, the conceptual correlation between a measurement instrument and that part of reality that you're hoping to measure.
The question behind validity is "I want to know X; if I measure Y, how helpful will that be?". And the question behind reliability is "if I measure Z, how accurate will that measurement be?"
https://en.wikipedia.org/wiki/Reliability_(statistics)
https://en.wikipedia.org/wiki/Construct_validity
Yegge calls out both concepts explicitly, though not by name, in this essay:
>> The outcomes from interviewing are statistically terrible. Google did wave upon wave of analysis over the years, and all the results were incredibly depressing.
>> [reliability] To name just a few off the top of my head: interviewers barely agreed with each other. Put the same candidate in front of two of our sharpest people and you’d routinely get a confident “strong hire” from one and a flat “no” from the other.
>> [validity, though the 'problem' here is strongly confounded by a restriction of range issue] And once people were actually on the job, their interview scores told you next to nothing about how they’d do
>> [reliability] Hell, some of our star performers failed their Google interviews four or five times, finally got in after 2+ years...
>> [validity] ...and then outshone everyone else.
The discussion of how interviewing outcomes are statistically terrible would benefit from naming the ways in which they're statistically terrible. Knowing the problem you have is an important step toward solving it.
(And as a side note, the last I heard from Google, you're not allowed to interview more often than once a year. Interviewing five times in two years would seem to violate that policy.)
It is a basic theorem that the validity of any instrument is bounded above by the square root of the reliability. It isn't possible for an unreliable instrument to be tightly correlated to reality, because it is, by definition, not tightly correlated with anything. That's what it means to be unreliable.
Thus, any company that wanted its hiring process to be good would necessarily be extremely concerned with making that process accurate; you need to come to the same decision when you assess the same person. This is something that interviews cannot achieve except at extreme cost. You'd need far more than five interviews to get a reliable assessment from them, despite the claim in this essay that "any more than four interviews and you're just playin' with your food". Of course, the Google interviews aren't supposed to be reliable anyway, so in that sense the claim is probably accurate.
The prescription Yegge offers is valid. Multi-month work assessments will give you a strong, reliable, and valid signal. They're also very expensive.
Another thing the essay completely glosses over is that this problem has been recognized for a long time, and we already know how to do assessments that are reliable, valid, and cheap to perform. They're called standardized tests.
At least historically, Google prioritized not hiring bad candidates over hiring good candidates. So it was neither a priority for interviews to be consistent (for good candidates) or for employees to be able to consistently pass interviews.
Serious question, tell me what you think of using IQ tests to hire SWEs? Should we just do that instead?
The tests that carry the particular branding "IQ" (Wechsler / Raven's / etc.) suffer from some problems in this regard - not very many questions exist and there are very large coaching effects. Hiring from a test that measures IQ is a very good idea (and there is a test that's commonly used for hiring purposes, the Wonderlic, though the ceiling of the Wonderlic isn't that high); hiring from "an IQ test" is a bit less good.
The concept of "IQ" can be toxic in contemporary American politics, so there are many more tests that "happen" to test IQ than there are tests that advertise themselves as testing IQ.
He said standardized test, not standard general cognitive test.
The gold standard in hiring qualification is work-sample testing. It works fine. You do not need to "make hiring a profit center" or "provisionally hire" or do internships. Work samples done correctly demand less time from candidates than interviews and scale better than interviews. They are standardizable and iterable.
What I feel like I'm reading here is someone who has been poisoned by FAANG hiring practices --- and they are terrible --- and has missed most of the work that's been done (outside of Google's admirable work in debunking their own processes).
I appreciate the "kitchen confidential" here, but with respect to Yegge, I think he's been working at the Olive Garden this whole time. Go stage at Gramercy Tavern! They're working at a different scale, yes, but you'll at least get a different perspective on the "gold standard".
I'm a little bit more on the fence with the work sample interviews having designed them and also interviewed through them. I've also done my fair share of "traditional" tech interviews, all at startups, never FAANG.
As an interviewer, I much prefer the signals generated through a work-sample interview. I'm much more confident in the hiring recommendation than I get from a 1 hour zoom session. However, if I look at teams that were built through the work-sample and zoom interviews, I'm not sure the outcomes were that noticeably better.
As an interviewee, I think I understand the frustration being on the other side has. With an in-person interview, I often have a good sense that I bombed the interview or something to improve on or replay in my head, less surprising outcomes. On the work samples it's harder to know whether you're making mistakes, or are being out-competed by someone putting in 4 times the effort to polish the solution beyond what their regular work product would be. Although I had one really good outcome where the work-sample interview really flagged the internal dysfunction of a company.
And then with both interview processes, I still think there is a really big unknown on what the false no-hire rate is, how much effort is getting wasted rejecting candidates that would actually fit the team.
So having to choose a process as an interviewer, I'm with you and would always choose a work-sample interview. On whether it should be considered the "gold standard", I'm much more hesitant, I think there are some limitations that are still hard to control for.
I do wish Starfighter/Stockfighter model had gained more traction, would've been interesting to see a recruiting company specialize in this and then seeding the interview results to multiple companies model work out.
The problem with work-sample testing (which is commonly administered as a take-home problem for the developer candidate to solve) is two-fold:
a) it discriminates against people who cannot spare 4+ hours of focused time on evenings/weekends to work on the problem. People with multiple jobs, single parents, etc.
b) in the age of AI it is no longer a reliable measure of someone's skill, for obvious reasons
Unlike Yegge, I haven't worked at FAANG, but the companies I have worked at all followed the same hiring practices and suffered from the same problems as he describes.
Provisional employment (or, if that's not possible, then well-paid internships) solve all of those issues. The candidate gets 3-6 months of stable employment, you as the employer get a large number of work-sample tests, and you can see how they use AI and how much.
I think a very real problem is that these take home problems are often way more than 4 hours. And to that they often add the traditional 4-6 hour interview loop.
Provisional employment doesn’t work for most cases, though. It might attract people who have no job and it might attract people who have so much saved that they are okay with potentially being let go after 90 days. But I imagine the vast majority of the potential employment pool are not willing to quit their current job to accept a “maybe” job from another company.
Adding take-home problems to a traditional 4-6 hour interview loop is odious.
But the "way more than 4 hours" thing smuggles in a premise: that every candidate should be able to finish the challenge in the allotted time. But candidates with greater aptitude or conversance with the problem domain will complete work sample tests faster than candidates without, and selecting for those candidates is the point of hiring qualification.
This is theoretically true but it’s also rife with misaligned priorities. The people putting together these take home assignments have little incentive to ensure that they can be completed by a competent engineer in the allotted time. The engineers completing these assignments are definitely incentivized to underreport how long they spent on the assignment.
With AI coding this is also largely useless. These “build this thing in 4 hours” assignments come with a literal prepared prompt so that they can be churned out in 10 minutes.
We don't ask or check how long candidates take. You're a professional, we give you a challenge, you can decide (up front, 30 minutes in, whatever) whether you're likely to be able to finish in the budgeted time. Maybe you can't because you've got a lunch date and don't have the contiguous block, and want to do it in chunks. Fine by us.
Again, the underlying smuggled premise here is that candidates have to finish the work sample. No they don't. In fact, that's a strong sign it's not an effective work sample. A test that everybody passes isn't a real test; it's just a hazing ritual.
Just anecdotally, I can confirm that this method works great - it screened me out by showing me exactly what day to day work was like at your company, and that I was not nearly nerdy enough about specifically containerization to want to do it all day.
So you saved yourself/the team several possible hours of interviewing, and me quite a few hours - I think it took me about 10 to 15 minutes to see what you wanted in an engineer and that I was not it, and a total of 1 email which felt quite automated (whether it was or not) so there was a very low social cost as well.
You are assuming the assignment is reasonable and the candidate is lacking if they cannot complete in the expected time. And for all I know that’s entirely true for you. What I know is that I’ve seen assignments from others where the assignment scope was unreasonable for the allotted time. And for those teams, the filter becomes not so much “is this person capable” but “is this person willing to put up with our shit”, and the teams likely don’t even realize that’s what they’ve done (because they also “don't ask or check how long candidates take”).
> Again, the underlying smuggled premise here is that candidates have to finish the work sample. No they don't. In fact, that's a strong sign it's not an effective work sample. A test that everybody passes isn't a real test; it's just a hazing ritual.
Now this is an interesting take. Usually when people talk about these take home assignments, they talk about assessing the quality of the work. How good is the design? How is the coding? Is it efficient/elegant/whatever?
Here you take a much different approach, saying that the completion itself is the filter. If one person completes your assignment in the allotted 2 hours and another needs 12 but never tells you that, do you not care about that discrepancy?
We do assess all of those things. Again: you're a professional. We give you a work sample test. You look at it, and use your best professional judgement to decide if it is (a) reasonable and (b) doable in the budgeted time given your capabilities. If either is untrue, you don't do the work sample.
I'm having a real hard time seeing how this isn't strictly better than an interview, which, as the article (and basically everything written in the last year about interviews) points out, is basically a random function.
A standard interview loop kills an entire work day, and is preceded by phone interviews that eat several hours. Properly budgeted work samples are strictly better from the candidate's time perspective, not to mention that you can do them from your couch rather than under flourescent lights in a confeence room.
The AI thing is an interesting problem, but a solvable one. We continue to hire resume-blind.
The question is whether companies would tolerate their own process if their employees did that recruiting process at a different company. They obviously do to some extent via plausible deniability; I have a 1 hour "doctors" appointment this afternoon, or I'm taking leave on Monday. Using it as cover to attend an interview.
Would this company permit an employee taking 3 months unpaid leave to provisional hire somewhere else and have free choice whether they stay or go at the end of it.
I feel like you could get around the AI bit by asking about components and what they do, rationale for decisions, etc. If someone can't speak to it, it should be a clear tell.
We hire entirely based on work sample testing, and there's a lot of stuff you can do to make it work in with AI-equipped candidates; I'm not prepared to write it up at the moment, but you start by recognizing that everybody is going to be using AI and designing the tests accordingly, and by relying on unassisted interactive challenges as a component of the process.
>> A standard interview loop kills an entire work day, and is preceded by phone interviews that eat several hours. Properly budgeted work samples are strictly better from the candidate's time perspective, not to mention that you can do them from your couch rather than under flourescent lights in a confeence room.
Yes, standard interview loops also discriminate, and the more time they take, the more discriminatory they are. Any on-site requirements compound the issues.
Like Yegge says: provisional employment/internships solve all of these issues. You get the best of all worlds: stable employment for the candidate where they get paid a regular wage and aren't under a stressful interview setting, and lots and lots of work samples for you, the employer. It's not perfect. For example, it can be difficult to entrust the provisional employee/intern with anything impactful if you don't know whether they'll be employed at the end. But it is significantly better than the alternatives in most contexts.
Provisional employment does not work. It requires candidates to leave their jobs before they know whether they have a secure job with your firm. I concede that provisional hires are higher-signal than work sample testing (or rather: that they're the platonic ideal of work sample testing), but the entire problem of hiring qualification is to make decisions in the context of a candidate doing a job search.
>> Provisional employment does not work. It requires candidates to leave their jobs before they know whether they have a secure job with your firm.
It works. I’ve seen it in two different places.
At the second one, the fundamental realization I came to was that it is virtually no different than “regular” employment, where the new employee can get fired for not meeting expectations within an arbitrary time period after being hired. This can be months, or even weeks. From the perspective of the candidate, regular employment and provisional employment have roughly the same level of risk: in both cases they take a job where they might be let go at some point. The benefit of provisional employment is that they know how long they will be evaluated for and against whom. It turns out a lot of candidates do in fact like the all-cards-on-the-table approach and enjoy being given the opportunity to prove themselves on the job.
Everything will "work" in the sense of you'll eventually get somebody in the job. To me, it's self-evident that a process that disqualifies everybody unwilling to work for weeks speculatively isn't actually working, at a minimum because it DQs most (probably all) competitive candidates. But yes, your mileage may vary.
I couldn't find the text of this joke, attributed to Dirac. I'll paraphrase.
A man walks into a pet store. There's a parrot for $100, it says this parrot speaks perfect English . The one next to it is $1,000, and says, This parrot speaks 12 languages fluently.
Then there's a bedraggled looking, droopy, parrot, and its label simply says One Million Dollars.
Does it sing opera and has successfully run for President? the man asks with a sneer.
This parrot, says the store owner, _thinks_.
That's what this entire post is about - how to evaluate people with a series of attributes, score, correlate, blah blah blah.
Hire them, see if they think. If they don't, fire them. It's cheaper than this credential/signal rigmarole, most of which is about CYA legal b+llsh1t. Yes, it's a simplistic strategy and it doesn't work for Shoogle, Banthropic, Goober, whatever. You know what, boo f*cking hoo. You're a trillion dollar company, suck it up. You have a zombie horde at your doors and you're just upset the "true gems" are hard for you to spot amongst the slavering masses. You're going to heartlessly lay them off anyway in a few years. You SHOULD feel this pain and anguish of having to sort through them, constantly regretting all your choices. That's the only way to have balance in the Universe.
There’s an old Malcom Gladwell podcast episode, I think the show was Revisionist History, where he says he’s an interview nihilist. As long as the person seems reasonably capable, and can probably do a bit of what you need, hire them. Interviews are so hard to get right that what you’re saying ends up being most effective.
Edit: Didn’t link it initially because I thought it would be hard to find. Turns out it’s not. https://www.pushkin.fm/podcasts/revisionist-history/hamlet-w...
Unfortunately from an organizational perspective, a bad hire could cause so much damage through incompetence let alone malice, that making no hire the default unless they're a perfect cinnamon roll of a fit, is actually a good strategy.
> a bad hire could cause so much damage through incompetence let alone malice
The fact that an organization cannot deal with such a case is a bigger problem in the first place. Eliminating incompetence and malice is among the basic skills of an organization.
Our hiring dis-function is because there a lot of people that dislike conflict and firing someone.
Everyone is annoyed when Google or whatever has a gruelling high bar to get in, but nobody bats a lid when say Jane Street does it. Both wildly successful.
Because Jane Street is unabashed about greed, and yet they do not let that greed lead them into attempting to pollute and derive us of our attention every day.
The industry should get down from its egocentric ivory tower and start hiring like other industries. You are not special, tech. Just have a sort of bar exam you have to take every x amount of years. The actual interview should just be an in-person behavioral one, with your future boss. Period. Don't get enough signal from that? Sorry, that's life, taking risks. Imagine trying to open a business without taking risks, and only kickstart it once you are a 100% sure it will work. No other industry is as delusional. Here is a reality pill: what you are asking, a 100% safe investment, is impossible, as any economist will tell you. "Campfire", give me a break, grown up adults with families don't have time for that Silicon Valley wankery, and you have no evidence that the results will be as good and unbiased as you think they'll be...thanks for bringing attention to the subject though, and in passsing also confirming how garbage the Google (and FAANG, in general) hiring process really is.
Just one more thing: the industry should really put a bit more weight on measuring people's potential and the concept of long-term growing and learning on the job. Just saying. You know, like every other industry on this planet.
Very well thought and written. Provisional employee or intern. Or having the candidate to come and do real work for a couple of days. The challenge imo is the big company culture vs startups. Do the things move at the pace in big companies where the teams have the ability to evaluate? Startups are a different beast however.
The paradox that strikes me is that "hiring is broken" yet these companies are beyond successful. So there's still yet another layer of something in between observing that employees are capable / incapable, and the company successful / unsuccessful.
Seconded, stop the theatrics and gatekeeping and let's keep a growth mindset while training / retraining those who 'pass the buck' overtime. At least everyone can get skills and talented outliers will find themselves with more structure and collectively we'll produce better outcomes for more engineers at multiple levels of experience.
> Another reason is that on the supply side, nobody wants to sign up to do a bunch of free work just to be rejected. If you just put up work, the candidates incur all the risk, meaning they walk away with nothing if you don’t hire them.
It's true, but prepping for a typical senior+ onsite loop in big tech still requires weeks of grinding leetcode, re-learning the latest system interview questions and the system interview answer framework, refreshing and rehearsing STAR stories, studying the company and its unique quirks that you're expected to know to pass the culture filter, remembering how to do all of this speedrun-style since you only get 40ish minutes per session, etc.
While that knowledge is more reusable across onsites, it's likely even more work than doing real or pretend-work for the company for a couple of days.
> When candidates get to walk away with something of lasting value that they can keep forever
I'm curious why them getting rejected from the position, even with the work sample they can carry away with them, wouldn't be still interpreted as a negative from future employers. "The other co passed on them, am I the fool for thinking they're good?" type of herd mentality which is often unavoidable.
Won't that "work sample guest book" be treated as the list of all companies that rejected you, a net negative for your personal brand you're projecting?
> (Me paraphrasing what Steve was implying) Take-homes are impacted by AI one-shotting them for candidates
I've been pleasantly surprised by how much you can glean from having the candidate upload their conversation log with the coding agent for whatever take-home you give them.
I was going to scoff at the amount of interview prep you said is required but then I remembered I read the book written by the founders of my current company before the interview.
Man do those slop images look ugly. I’d take child scribbles over the garbage picture in the article.
His idea has some merit but will require the old system to completely crash out before anything new will be considered and I'm not sure if it will crash or just keep limping along. If it really does crash out hopefully we will see multiple new strategies emerge as there are many possible options once the current one is off the table.
As yegge mentioned, there might be more appetite for trying out this idea now because there are many engineers who are currently unemployed. Offering them short co-op could be beneficial to both the engineer and prospective employer
Maybe three days is enough for some code bases, but if you have millions of lines of code, agents aren't going to help you that much.
I don't understand how a failing stamp for a campfire is good for the interviewee. It signals that they weren't good enough to get hired. Why would they want to parade that around?
I had the same thought. "I didn't get hired at X! I didn't get hired at Y!" It's like how people write ex-Google, ex-Amazon in their headlines but worse: failed-OpenAI, couldn't-get-in-to-Anthropic. Let's all get around the campfire and sing kumbaya
A lot in here about Google, which hilariously has done a bunch of studies that concluded it's hiring process is awful (is sure is!) and the takeaway is that candidate evaluation is impossible, not that Google in particular does it badly.
This reads as if he's really struggling not to say "Now that the applicants are desperate we can begin to interview them properly mwahahahaaaa!"
The current interview process isn’t meant to get the best talent, its intention is to give managers on visas an easy way to bring in other visa workers (via sharing questions and scaling difficulty for no-visa applicants)
> One day, the recruiters gave us a special round of packets to review. In these special packets, we were able to read the interviewer notes and candidate responses. All personal details were stripped out, and we were told it was a “calibration exercise.” We had to do our regular voting job with these special packets, and see how it went. I think we may have assumed they were from another site, since cross-site calibration was common. Our group did our job, and voted not to hire about 2/3 of the packets. This was about par for the course. But surprise surprise, this time, those were our own packets from when we had all interviewed at Google. The recruiters had tricked us into reviewing our own interview packets, and we had voted not to hire most of our own group. For that brief moment, we all had a glimpse into how utterly broken our process was. The people-team had rubbed our noses in it.
Or maybe the company changed in the 10 years or so since everyone in that room was hired and the employee needed 10 years ago is not the same as the ones needed now?
The most talent dense place I've worked had a dead simple process - two one hour chats, one with your potential manager/team and one with the CTO or CEO. If things didn't work out, well you got sent away, probably happened twice per month. There was a particular meeting the CTO/CEO used and if you saw someone meeting with them there on a Friday afternoon, you would not see that person on Monday.
The place was not big - never got much beyond 100 engineers, but produced dozens of founders, VPs, GMs etc at well known companies, as well as engineers with very notable OS projects and lots of high-placed engineering in FAANG companies.
Curious what those two hours would entail!
I think interview is part of tech life where I feel very, very bitter at.
Warning, sad boi rant ahead.
I was from a programming bootcamp. I entered the tech because I was the only person in my bigger family members who have the skills/education/chance to earn a big salary. I still remember, I paid $12k back then, and it was me and my mom's only savings. I started tech in my 30s, and mostly worked physical labor work before that.
I was the weakest at that cohort, but I studied really, really hard, until the bootcamp noticed my progress and hired me, albeit at a very low salary. That was my first programming job.
I eventually learned about big tech, and liked the fact that they didn't care about credentials, whether I came from a good university or not, unlike the YC combinator startups who mostly cared about credentials. I learned that they pay really well, and I did, read Steve's blog, "Get that job at Google". It motivated me to study DS&A, and also to get CompSci degree.
Overtime, I lost count, how many interviews I have failed at big tech. I gained more experience, I became older, but I kept studying, and studying, and studying, but I keep failing. I also wasn't sure which area to study, so I ended up studying for everything, from frontend to backend. It was a lot, really, a lot of things to study, from leetcode to JS specific to DOM to backend system design to frontend system design, to behavioral, and frontend interviews back then was still a crapshoot, some companies ask for deep JS/DOM questions, some companies just ask for leetcode questions.
But I kept failing.
I think I'm pretty good, or at least, that's what I thought. I learned quickly, I have no problems for clearing mid level leetcode questions in under 20 mins. Overtime, the bar gets really hard and it became hard level leetcode questions in under 20 mins.
But what made me really bitter over all of these interviews, was that I saw my friends, people I knew, from programming bootcamp, from my CompSci degree, got a job at big tech. I knew, or at least, what's what I thought, that they had less skills than me in programming and in DS&A. But they got into big tech. Some of them were minorities, and during that time, diversity hiring was a thing, and maybe that's why they got in, I thought to myself.
Sometimes I asked them what the interview questions were, and to my surprise, it was easier than my questions. Idk why.
Sometimes I wonder if my luck in interviewing is really bad. I tried everything I could. I bought courses and devour those materials. It's been years and years and years and years. It did wear down on me. I want to cry, which I did sometimes due to keep failing big tech interviews. But it won't do me anything, I can only keep my head down and keep trying.
I ended up making pretty good money in this field, and able to help my family members. I did work with some of those big tech engineers. I realized that those big tech engineers were just average, and I don't think I am less capable than them. That made it sucked even more, because I don't understand why I kept failing, and why the people I know are succeeding.
I do some freelance now, but will finish some of my contract. The job market is scary, and one of my contract will finish soon. I am having hard time getting even recruiters to contact me, maybe because I don't have big tech credentials.
I also did mostly fullstack/frontend leaning lately so I ended up studying frontend interviews. But frontend job market is kinda dying lately, since most companies don't really respect frontend and don't think its worth it anymore. These days, I don't even know what to study anymore, so I need to study everything again, with the addition of all the AI stuffs.
I can't help but to think, and always think even today, especially during this tough economic times, what if I was able to get the big tech job. My family would be proud of me. I would have better companies in my resume, and could stand out more in the job market. I could've done some cool highly scalable projects that I can boast of in my resume. I could've joined some good team, mentored by good engineers. I would have more savings than now.
These days it doesn't matter anymore. The big tech salary era already closed. Things are way way more competitive than before. With my average background, I don't stand even a chance at being asked to interview.
Life is really a mystery. Things that you really need or want, you don't get it no matter how hard you try. But it is wasted away on those who got it.
I usually don't post comments, but seeing this post, I just needed to vent.
Thanks for reading.
Honestly, it was probably just your age. Being in your 30s, an entry-level coding job at Google or other big tech company just isn't going to happen. Those companies all have a lot of ageism especially in the coding ranks.
Not sure why HN doesn't display my edited post. So I'll just reply here.
Thanks for this article Steve. I need to read this. Maybe it will finally give me closure, after years of failing.
kitchen confidential? in your dreams, nerd.
> And it can pay for itself twice: once in real work shipped, and once again in something else you could probably use more of, which is gravity.
what?
Steve Yegge is one of my very favorite authors I love his work. But lots of things to say here.
FIRST - is that before you get to campfire anyone, you have to have done some sort of interview process to boil it down to the one person to do the campfire - so how does that work eh?
SECOND - campfire is deeply invasive to the candidate's life and time.
THIRD - you have to pretty damn sure someone is a hire before doing a campfire. You CANNOT do campfire as an evaluation step, after which there are more interviews.
FOURTH - this is effectively just a really really long version of the take home work test which is absolute bullshit.
FIFTH - there's STILL no science to the campfire. Don't give anyone a fucking test if you don't actually know how to scientifically evaluate the results. And campfire does NOT result in a scientific outcome, it still results in an arbitrary opinion.
SIXTH - any company that wants me to do a campfire - to commit days or even weeks of work as part of them trying to decide to offer me a job - can fuck off. Sorry, the party got spoiled by all the other companies who asked me to do something as part of the interview process and then either ghosted me or gave me some bullshit outcome like "they didn't like your work".
I can tell you how to recruit people and it does not require campfire.
You TALK to people about software development - you engage them in extended conversation about what they have done, what they know, what their interests are, what they have built, what projects they worked on, what went right, what went wrong. You look for people who have BUILT STUFF - this was true before AI and is 100X more true now - anyone who has not built anything today is not worth employing and anyone who has built something must be able to talk about it in depth. This interview processes worked before AI and it works after AI. And finally, you accept the limitations of recruiting which is that people are people and you won't find out how well someone performs until they have been on the job six months - live with it.
Sorry Steve - I love your work but I'd never work for any company that wanted me to do a stupid campfire because they don't know how to actually work out if I can do the job or not.
You CANNOT do campfire as an evaluation step
why not? to expensive? candidates don't have the time? i'd love to do that because it also gives me insights into the company. how they work, etc...
I can tell you how to recruit people
why is interviewing broken then?
You TALK to people about software development
didn't we try that and find out that the sweet-talkers master this and are able to fool everyone? or didn't we find that this leaves out good people who don't do well when questioned like that?
btw: my personal preference for a tech interview is 1 hour of pair programming. (not just live coding)
I think you're largely right - but there are some challenges.
Talking requires that the interviewer be competent and care. Which seems like a low bar, but it easily degrades. When an engineer is burned out, or is interviewing for a project they have less stake in, or has business requirements forcing them to hire someone fast, the bar lowers. Those engineers now are the gatekeepers, and they let in even weaker engineers.
Even worse, any utility from this is predicated on the founder making good hiring decisions. If they don't understand how to hire a competent engineer and make them care about the company, then it's dead from the start. And a lot of founders or execs in general are awful at this.
Companies that maintain an excellent work culture such that engineers deeply care about the team and have stake in any project they conduct interviews for will do well with this model. I hope we see it used by them.
This sandwich is huge but the bread layers (top and bottom) are moldy, love the empathetic writing style though. Agree on your TALK paragraph - mostly - as well. Make sure to consider juniors in that lumping too though, we can't have systemic failure over time. AI-outcomes are not guaranteed.
And good riddance.
It’s interesting, this guy has a Wikipedia page but no achievements on it. It seems like his whole career has just been moving around and bullshitting about how great he is. I kind of expected to actually see an achievement on there, like inventing a programming language or developing something important.