[1] https://en.wikipedia.org/wiki/Random_forest
[2] https://en.wikipedia.org/wiki/Naive_Bayes_classifier#Trainin...
[3] https://en.wikipedia.org/wiki/K-nearest_neighbors_algorithm
2,422 karma · joined November 9, 2020
Former head of product and lead for assessments @ Triplebyte.
[1] https://en.wikipedia.org/wiki/Random_forest
[2] https://en.wikipedia.org/wiki/Naive_Bayes_classifier#Trainin...
[3] https://en.wikipedia.org/wiki/K-nearest_neighbors_algorithm
Minecraft has user-generated content and is a highly social game. But what it isn't is optimized. Notch has plenty of personal failings, but he isn't a businessperson or a product manager, he was just a guy making stuff he thought was cool and fun. He wasn't sitting there tracking conversion rates. He didn't have a dashboard indicating average Time-To-Diamonds for new players, and he certainly wasn't creating a platform where thousands of others could all optimize in parallel.
Roblox, on the other hand, is optimized. And predation is, at least in part, an emergent property of a business optimizing its metrics (and of its employees optimizing theirs). No product manager ever got fired for increasing revenue or improving user retention, so they just continually do things that do that - in ways that throw other things under the bus, because those things are not their job.
It feels emblematic because that same parallel-optimization-turned-predation has been happening to everything else, too. It's why your Pizza Hut pizza sucks now, it's why you can't buy a TV that doesn't track you and insert ads, it's why you can't get takeout without having to go "no, I'm not tipping, skip >:(", it's why the front page of CNN is full of crystal-woo-level health advice, it's why almost everything you eat is meant to push overconsumption, it's why a toaster from 1965 still works but one from 2019 doesn't, it's why every phone and Windows update installs shitty mobile games and Facebook, and on and on and on.
Games just make it obvious because the optimizations are (mostly) visible. And even then, for every example you see, there's another you don't.
But I'm not paid by the click, so different incentives.
The harms here are not the result of some broad faceless force so distributed and ethereal as to avoid accountability. The people performing them know exactly what they are doing. They're choosing to do it, when no systemic factor forces them to. If they wanted to not harm people, they could do so at zero or even negative harm to themselves.
Systems-level thinking is a useful tool, but it can make you miss the trees for the forest when a single concrete human being in front of you is just a bad person.
> I don't think how far a candidate gets on this particular test determines if they're OK or if they're great.
It doesn't with certainty, but measurement of this kind is always subject to some degree of error. The point of interviewing (especially at the early stage where this interview is applied) is signal, not certainty, and we do seem to be picking up on signal:
-- # of steps completed on the coding task is the strongest single signal of success at later final interview rounds. Candidates who have gotten offers (not from us, to be clear, so this is uncorrelated error) average ~1.1 more steps completed on our coding problem than candidates who don't. That's after we filtered a lot of the weaker results out, so it's sampling biased in slower candidates' favor. This is a larger gap between offers and non-offers than any of the other nineteen individual internal scores we record for each interview, iirc.
-- # of steps completed correlates with results on the rest of the interview in a way that is aligned with reasonable psychometric measures of quality, same as most of the other parts of the interview (see e.g. [1]).
If your point here is just that interviews involve somewhat artificial work and are prone to error - well, yes. Everyone involved in testing as a field already knows that and is working around it.
To use your concrete example, creating a problem involving "sussing out all the ambiguities and contradictions" for an hour would be asking a lot more work from candidates. If we did that, I bet we'd have people complaining about the lengthy workload of doing an interview (or simply not doing it, which would be fatal to us as a business). I would also worry that that's a much fuzzier skill to measure, particularly in a cross-organizational way. It's not that, in isolation, you could never create an interview to test ambiguity-resolution, it's that (at least in my judgment), it would be impractical for us to do so given what we are trying to do.
And finally, to this:
> I posit that a great one could finish 2-3 steps and an OK one could finish 4-5.
See [2].
-------
[1] https://bsky.app/profile/otherbranch.bsky.social/post/3lpcdl...
> Very few people will finish the full problem. You do not need to complete every step to pass our interview.
A problem that an average candidate completes doesn't have a lot of differentiating power on the high end, whereas a problem where an OK candidate finishes 2-3 steps and a great one finishes 4-5 carries a lot more information.
-- CS grads are, on average, better programmers than non-CS-grads.
-- The average CS grad is not a very good programmer.
My company does a standardized interview with a straightforward coding problem that is only a few steps above fizzbuzz level. In just the past few weeks, we've had candidates who:
-- Had to look up basic syntax (defining a function) in the language they chose.
-- Duplicated a reference a few minutes in and could not figure out the problem in the remaining twenty minutes.
-- Couldn't extract the 2nd element of an array of five elements.
These same candidates, on other portions of the interview:
-- Knew nothing about common data structures (something that at the very least a CS degree should help with)
-- Couldn't handle an intermediate SQL query fix involving a simple normalized schema
-- Couldn't tell you anything about internals or security, and
-- Didn't seem able to describe how they'd build a CRUD app.
All of these candidates had CS degrees from respectable-to-good universities.
Anecdotes are not data, but high-level data says the same thing. Our coding problem is very similar to the practice problem shown at [1] (though slightly harder). It doesn't require any tricky lateral thinking, deep language features, esoteric algorithms, dynamic programming, weird race conditions, or any of the other usual trivia BS - it's as straightforward a task as we could design.
And if you look at how much progress people make (see [2]), it's not much. The vast majority of people we interview have CS degrees, and two-thirds of them still get ~nowhere.
Meanwhile, the best interview we've done this month was with a guy who has been the sole developer for an ag business in rural Arkansas for the past decade. He has no degree and his previous two jobs were a sandwich shop and running a website for his church.
(Specific details slightly fudged for the sake of candidate anonymity, but not in a way that materially affects the point.)
[1] https://www.otherbranch.com/shared/practice-coding-problem
The argument here isn't "the goal of a software engineering job isn't economic", it's "sometimes quality is aligned with economic goals" (which is of course true).
If there's a 10-point scale from 0 = the most hacked-together nonsense and 10 = perfect formal proof of correctness, I'm arguing that a lot of engineers should come down from a 9 to a 6, not to a 0 (or at least, that they'd benefit from picking their battles about when to argue for a 9).
In business contexts, I often argue the opposite, trying to move them from a 3 to a 6, because nontechnical people often underestimate the importance of tech debt. That's not a typical problem on HN, though.
The quality of your team is more-or-less a pre-existing background variable. The question is whether a team of comparable quality takes longer to produce quality software than hacked-together software, and the answer appears to be "yes". The only way out of this is if optimizing more for code quality *actually helps you recruit better engineers*.
I can put a little data to that question, at least. I run a recruiting company that does interviews, so we have data both on preferences and on apparent skill level.
I went and split our data set by whether an engineer indicated that emphasis on code quality was important to them. Our data suggests that you can probably make slightly better hires (in a raw technical-ability sense) by appealing to that candidate pool:
- Candidates who emphasized quality were slightly (non-significantly) more likely to pass our interview and,
- Candidates who emphasized quality were slightly (non-significantly) less likely to have gotten a job already
The effect is pretty small, though, and I doubt it outweighs the additional cost.
If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.
"How do you discern truth from falsehood" is not a new question, and there are centuries of literature on the answer. Epistemology didn't suddenly stop existing because we have Data(TM) and Machine Learning(TM), because the use of data depends fundamentally on modeling assumptions. I don't mean that in a hard-postmodernist "but can you ever really know anything bro" sense, I mean it in a "out-of-model error is a practical problem" way.
And yeah, sometimes you should just say "nope, this source is doing more harm than good". Most reasonable people do this already - or do you find yourself seriously considering the arguments of every "the end is nigh" sign holder you come across?
The people around are telling the storyteller that "he" (Pierrot) has stolen the purse, but the storyteller misinterprets this as pointing to some arbitrary agent.
Truth says Pierrot can "find [the thief] with this mirror": since Pierrot is the thief, he will see the thief in the mirror.
Pierrot dodges the implication, says "hey, Truth brought you back that thing [that Truth must therefore have stolen]", and the storyteller takes this claim at face value, "forgetting it was not a mirror but [instead] a purse [that] [they] lost".
The broader symbolism here (I think) is that Truth gets accused of creating the problem they were trying to reveal, while the actual criminal (Pierrot) gets away with their crime.
I'm very clear with anyone who works for me that our interests won't always align. I'm also clear with them that I'm not going to screw them over and that I won't take any offense if they negotiate with me or ask for things. I lay out what my lines are: I will not knowingly lie to them, and I will usually provide complete information except when I have a good reason to. I ask the same of them. Beyond that, we're adults who can negotiate like adults.
There's nothing wrong with a transactional relationship, and it doesn't mean you can't be human. Things only get unfair when the relationship is only expected to be transactional in one direction, where employees are supposed to have undying loyalty to a company that will lay them off as soon as it becomes convenient to do so.
No, but it's a relevant data point that allows you to counterbalance possible sampling bias.
If everyone tells you people are poisoning halloween candy all the time, but no one within your direct experience encounters it, you should investigate possible sampling bias. Perhaps you are in a privileged context that avoids poison halloween candy, so the sampling bias is in your local environment. Or perhaps such stories easily go viral, so the sampling bias is in people's tendency to share sensational stories. Either way, you have something to watch for.
Relying on multiple weakly-correlated information channels is a good way to hedge yourself against dysfunction in any one of those channels.
Doctors ask you to do things that are unpleasant, involve things you don't understand, and create uncertainty. Your doctor says "hey, your blood pressure is high, you need to eat less salt, but that may or may not solve your problem." If you believe them, you have to measurably damage your quality of life, you have to trust in a bunch of medicine that you don't fully understand, and you now have to worry about whether your health will ever improve (when there is a very real chance that it will not). Or you can go "actually doctors are all quacks and if I just eat Natural Whole Foods(TM) I'll be fine" and have an approach that asks you to do things that make you feel good, fits within an intuitive model of the world, and creates artificial certainty.
In isolation, this isn't new. What is new is that:
- The asks have been unusually unpleasant in recent memory. COVID lockdowns are a particular focal point for a reason: they were psychologically painful and involved a distant and low-probability threat in the minds of most people. (To be clear, I think they were clearly correct policy - but that didn't make them fun.)
- The world is a lot scarier and more uncertain than people are used to, so acknowledging the facts has a higher emotional cost.
- The truth is more muddled than it used to be for most people. They're bombarded with an enormous amount of misinformation. Even if you're good at filtering misinformation and avoid uptake of 90% of it, the 10% that gets through can erode trust. And institutions - while still on balance the best source of information available to a layperson - have been abusing that trust enough that some suspicion is warranted.
- Propaganda is channeled through social connections untraceable to organizations. You might not believe a youtube video if it tells you about chemtrails, but you might believe your friend, who heard it from a friend, who saw it in a youtube video. And algorithmic targeting means you can be served exactly the propaganda that strikes your biases and vulnerabilities.
------------
The authoritarianism you're talking about, on the other hand, says:
- You should not be asked to do anything new or process the discomfort of cognitive dissonance. In fact, the things you've already been asked to do were unfair and targeted oppression aimed at you.
- The world is scary, just like you feel it is, but in a narrow and controllable way. You have agency over your fear, and a champion who fights for you, and you won't (say) die of a random disease because of a bad roll of the dice.
- The truth is simple: I am telling you the truth, always, and our enemies are telling lies, always.
- You don't need to listen to authorities who are scary and untrustworthy. Just listen to your neighbor or your favorite TikTok creator, who you trust and feel safe around.
In that sense, it doesn't feel authoritarian, because it isn't authoritarian to them. It asks them nothing, and in some cases, less than nothing. It oppresses someone else, asks someone else to sacrifice, removes someone else whose presence may cause cultural discomfort or cognitive dissonance, and promises simple, certain, free solutions. This is why you see people affected by layoffs or tariffs or whatever going "wait, um, there must be some mistake, obviously this couldn't affect me" - that really is what they believe.
That's not to say that there are not very serious problems with the status quo. There are, and that's part of what's fueling these (malignant) solutions.
I made a comment about a month ago [1] that applies again here: the average person is usually good at identifying problems but terrible at identifying solutions. And when the average person has been able to identify problems for decades and institutions have failed to solve them, they're less likely to hold the line against misinformation and mob rule. That goes double when the average person's life has gotten significantly more uncomfortable and scary, reducing their appetite for self-sacrifice in a world that is extracting more and more of their well-being.
Sophisticated users on mature platforms generally behave more-or-less rationally, but those will not be most of your users early on. That's to your benefit, because abuses take time to arise - you can get away with stuff on year one or two of your platform that would be a glaring vulnerability in year ten.
If tomorrow the greatest dream of AI was achieved, and we had a perfect benevolent AI that would shepherd humanity to comfort and safety forever, that would be just about the best outcome imaginable in material terms. But I think I'd be unhappy with it, because I derive a lot of my personal sense of worth from what I do - from what I build and for what I contribute to other people. I don't know what I would do in a world where that was no longer needed. I'm great at being helpful! I suck at being fun.
Is that healthy? Probably not. (It's actually something I'm working through at the moment, that I increasingly understand as a consequence of both personal and societal-level abuse.) But we're not all healthy creatures. We live our lives as the people we are in each moment, including the ways in which we're dumb and flawed and insecure.
> We all hate the culture on the social media network hosted by LinkedIn
Who is "we" here?
I work mostly with Bay Area companies and engineers looking for early-stage startups, about as HN-y a crowd as you could possibly hope for. A plurality of our candidates - about 30% - have come in from HN engagement.
But many people on both sides of that set still buy into the things people theoretically hate about linkedin. Status-jockeying is everywhere, and insecurity shows up on both sides all the time. Founders are alert for any signal that you don't consider them The Most Special Company To Ever Exist (because they see that as a sign you'll leave). Engineers are often eager to withdraw at the first sign a company might not be a rocketship (because they want a stable job). It's not everyone, but it still happens plenty.
I'm not blaming them. This is the correct self-interested strategy (within reason) for both sides. In a game of imperfect information, you try not to show when you have a bad hand, and you look to see if your opponent has one. Sometimes you bluff, and sometimes you call others' bluffs - and as long as everyone wants everyone else to stop lying first, this doesn't change. You can choose not to bluff (and I do) but you will be playing suboptimally if you do. And good bluffs don't look like bluffs - the stuff that you see as "banal and insincere" is just the people who suck at it.
As a personal example: a friend of mine came to me yesterday and asked me about a job offer he was considering from a founder I'd met before. I hadn't been impressed with this founder. Bluster is pretty much all they seem to do, frankly (I'd blocked them on linkedin not long ago because I got annoyed with it). But my friend's impression was "wow, they seem so confident and energetic!". The bluster (or what I think is bluster, anyway) nearly became a self-fulfilling prophecy, and still might if my friend accepts their offer despite my opinions.
This call, unfortunately, is coming from inside the house. We do signaling differently, but we still do it.
I worked on this problem for a couple years, with vastly more funding and an existing userbase to bypass the cold start problem. So did my predecessor. Neither of us succeeded, nor came particularly close. Here's what I wrote last year in a retrospective about how we failed (with a few things not relevant to this post trimmed):
> "LinkedIn For Engineers" - that was the by-phrase within Triplebyte for most of 2020 as we shifted into the Source era.
> Job searching on LinkedIn sucks! (True.) Engineers hate LinkedIn! (Often true.) So if we just make a LinkedIn that doesn't suck (uh-oh), everyone should want to use us instead!
> I present it here in a somewhat comedic tone, but this wasn't a ridiculous idea on the face of it. We didn't need to worry about the cold-start problem (because we already had a bunch of users on both sides of the hiring process) and we were competing against an incumbent people don't like. None of Triplebyte's leadership were stupid, and they didn’t pick that direction arbitrarily.
> Conventional wisdom, and wisdom within the company at the time, was that if you want to disrupt an incumbent, you need to be a step function better. The claim was that our skill assessments and our engineer-specific functions could accomplish that. And our assessments were very good. That part wasn't wrong.
> But the problem was that we couldn’t just be a step function better at something. That can work for a company just starting out (and in fact it’s standard advice for making a great startup), but we were a growth-stage Series B company with a nine-figure valuation. We needed to be a step function better at the core value proposition of our space. And the core value proposition of LinkedIn isn't "we make finding a job easy and pleasant". It’s "we have all the jobs and all the candidates".
> No one wanted another LinkedIn, because LinkedIn had already perfected its we-have-all-the-jobs-and-all-the-candidates value prop.
I'm not quite sure what OP thinks their step-function advantage is, either. It certainly looks nicer than LinkedIn, but if you're generating a profile from a resume, what does it add beyond resumes? Resumes that are already a de facto standard supported by every ATS in the Universe?
We had a UI with a bunch of nice displays and animations and such. No one used it - they all just used the PDF export. At my current company, I pretty much exclusively use linkedin's PDF export when viewing candidates there for the same reason.
But then, I got much better results from the cowboy prompt by changing "partner" to "pardner" in the text prompt (even on neighboring words). So maybe it's an issue with the script and not the generation? Giving it "pardner" and an explicit instruction to use a Russian accent still gives me a Texas drawl, so it seems like the script overrides the tone instructions.
https://www.pewresearch.org/race-and-ethnicity/2024/09/12/la...
Less than half of Hispanics have even heard the term "Latinx", and of those that have, an overwhelming majority (75%) say they'd rather you don't use it. This is true regardless of age, gender, race, education level, party affiliation, orientation/gender identity, and immigration status - you don't get a much clearer picture than that in a poll. The plurality, and usually majority, preferred term across all demographic slices was "Hispanic", which is also not gendered.
If we choose particular terminology, and ask others to do so as well, shouldn't it be with the clearly-expressed preferences of the people we're talking about in mind? To me, that seems like the most obviously-respectful path.
First: the standard isn't relevant to a nuisance suit, since by definition you don't expect to win a nuisance suit anyway.
But setting that aside, disparate impact requires a significant difference in outcome and can be defended against by showing that the standards are relevant to job performance ("business necessity"). That's true for both the federal Civil Rights Act and the California Equal Pay Act (which is what this suit was brought under). So a "single variable analysis" isn't the end of the story, and employers can (and often do) provide statistical arguments that their policies satisfy business necessity.
I'd suggest looking up the case (Griggs v. Duke Power Co.) that established the disparate impact standard in the first place. TLDR, a company that had explicitly discriminatory Jim Crow-era policies banning black employees from certain departments adopted new requirements on the day the Civil Rights Act went into effect. Those requirements hadn't been in place before, Duke Power could not show any actual connection with job performance, and white employees were two to ten times more likely to satisfy them. A unanimous court (which, as a fun trivia fact, included an open former member of the Klan!) said nope, can't do that.
Capital often outstrips actual business acumen as a factor in the success of a business. That's partly because we live in a world where word of mouth, reviews, online presence, etc. are all commodified, partly because tech (like the Industrial Revolution before it) has greatly increased the growth potential and concentration of capital, partly because of investors actively intervening to ensure the success of their other investments, partly because of increasing and increasingly-naked corruption, and partly because of the importance of network effects. (I don't know which of these factors is the most important.)
The more important capital becomes relative to the actual functioning of a product, the more disconnected from reality a business can (perhaps must) get. Their actual business becomes selling a pitch to investors, not selling SaaS, because their actual product is investor returns, not long-term viability or value. And because a big part of that pitch to investors is the rockstar founding team, founders have to (or at least feel they have to) do the golf-buddy shit. It's literally their job, or at least, they think it is.
Post-ZIRP doesn't kill that because capital being scarce just increases demand for it even more.
The reason I don't believe in (1) is that the candidate I described in my previous post claims nearly fifteen years of experience, some of it as a lead, and completely bombed our entire interview. Referrals are another matter (and they are indeed an excellent channel when you can get them), but they tend to be pretty low-volume - if you're hiring from the general public at all, presumably referrals didn't get you what you wanted.
By the same token, the majority of people we've placed so far were people whose resumes didn't particularly shine - but who turned out to be very good engineers when given an opportunity to actually work on a problem. (That isn't just my opinion, it's the opinions of the companies that hired them.)
For (2), I agree. We do do that as well (coding's one of three parts of our interview, not the whole thing).
For (3), have you ever had a reference give a negative review? A lot of companies make it outright policy to do so, and iirc there are legal restrictions on employers doing so in a lot of places. I wouldn't trust that with any reliability (although it's still good practice 'cause it's cheap).
> I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.
Of course soft-skills matter! I never meant to imply otherwise. But soft skills will only get you so far if you don't know how to do the fundamental responsibilities of your job.
I run a technical recruiting company, and we ask candidates a question like [2] on our interview (EDIT: we ask other stuff too, this is only part of it). It's not exactly fizzbuzz, but it's really not far beyond it. A candidate we interviewed just a couple days ago took that problem and couldn't even complete the first step. This is the equivalent of asking someone applying for a job as a statistician what the distribution of the sum of two normals is, or asking someone applying for a job as a con-law lawyer what the fifth amendment is, and having them go totally blank.
Is it conceivable that they were just having a rough day and their brain hiccuped really badly? Sure, I suppose. If we did ten thousand interviews, we'd probably have at least one person who is objectively great perform that way.
But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.
-----
[1] https://news.ycombinator.com/item?id=43006330 [2] https://www.otherbranch.com/shared/practice-coding-problem
It's the same principle as another comment I made a few days ago ([1]). It's not hard to identify problems that really are problems, but finding effective and feasible solutions to those problems is often far more difficult, especially if you're an outsider. The mistake isn't in identifying the problems, it's in thinking that you can come in totally blind and know how to solve them. (Or, put another way, in thinking that you as an outsider can tell the "dumb and easily fixed" problems from the "horrifying systemic nightmare" problems.)