Fast forward a year and a friend of mine gets hired there. Turns out not only was my code pretty good, but had magically made its way into one of their production systems. The test cases that I wrote for my interview the year before word for word copied and pasted right into the prod test runs.
I know this because I used my name as the input for fname, lname trying to be a bit cheeky.
I have a theory. It's quite cynical, but it's taken me about 5 decades to arrive at it: life is a beauty pageant. I don't say this lightly. It was a very slow process to get to this point.
A friend, colleague recently interviewed at a very popular, pre-IPO company that is often discussed (positively) here. He doesn't look like your typical engineer, but he's literally the smartest person I've worked with. He gets shit done. He learns new things all the time. As his current manager, I told him I would give him a perfect recommendation. He had an "in" with a current employee. He aced 5/6 of the mini interviews, but "failed" one. Fine, it happens. But, something he said to me stuck in my head: the building of said company was filled with rows and rows of 20-30 white kids. He saw 2 people of color, and one was a greeter at the front door.
I don't believe the people that interviewed him were racist, but I think every person applies a "does he/she look the part" filter and if the answer is no, the mind finds reasons to not hire.
It's not just hiring that I think is pageant-like. So many things in life are. So much so, that I think people themselves actually live up or down to their physical features and characteristics. Look at the executives at a F500 company. Male and female. Why do they look so similar? I live in a somewhat affluent community. Why does everyone here look like they "belong"? This is not a gated community, so why does that happen?
Physical features are such a basic filter, applied to ourselves and others, that I don't think we are hardly aware of it.
EDIT: there are always exceptions. It's been my experience that exceptions are rare, though. And the exceptions sort of prove my point.
Can you elaborate on that?
I'd just download the next version of their app off the store and save a copy of it, then decompile it to prove my code is there and sue the living shit out of them
I guess that's not an option if you write server code for them though.. I'd probably negotiate to be paid for the work in that case
We are failing to bring certain softwares into existence by effectively requiring programmers to their effort into the World Wide Nether, finding the Kth smallest element in an unsorted BST for the millionth time, for seemingly no purpose except for it is "how things must unfortunately be done."
This is a funny topic to me. A decade ago, before Leetcode, Hackerrank, and Cracking The Coding Interview, it was common for developers to complain that software developers were losing touch with algorithmic knowledge. HN-type websites were full of discussions about clueless software engineers doing damage to companies by implementing O(n^2) algorithms that worked fine on small datasets but failed in production. It was popular to complain that modern libraries, frameworks, and programming languages were making developers too soft to write good code.
The industry responded by re-emphasizing the value of CS fundamentals and algorithmic knowledge. The training industry responded with easy tools to teach and learn these algorithms. The internet is full of easily accessible materials to teach these principles to anyone motivated enough to Google it.
Now, the popular narrative has flipped. Internet comment sections want to hate algorithms and suggest that programmers don't need to understand the basics. Just rely on the frameworks and libraries to do the right thing. Just Google the solution and weave the libraries together to do what you want.
> Whereas a young programmer in the past may have spent their extra days writing games in Basic or static web pages, hackers these days seem to do Leetcode until the wheels come off.
Young programmers don't wake up in the morning and choose between writing static web pages or grinding leetcode. There are more opportunities than ever before to learn whatever you want.
Have you actually worked with students lately? Leetcode style systems are a lot of fun for people. It's a straight to the point system that teaches algorithms and other fundamentals in self-contained brain teasers that are straight to the point. And it's trivially easy to Google for supporting training material. In my experience, the same people who are self-motivated enough to build web pages and games are frequently also interested in Leetcode style brain teasers.
People aren't choosing between one or the other. That's a false dichotomy. All of the highly driven students I've worked with have a range of experience from toy projects to Leetcode style learning challenges.
That’s not true for everyone, especially in such high stress situations as an interview. I like crosswords, but I wouldn’t want to do them in front of someone judging me for a job in 45 min while thinking aloud.
Heck I was too young when I started learning lisp (clojure). Took a long time to get used to non-functional constructs.
Things definitely changed once I got to university though. Competition for internships meant I had to get good at interviewing. The CS program I am in encourages the career focused so grinding leetcode is popular. One of my interviewers asked me a number, and used that to retrieve the n'th leetcode question from memory.
There does exist a small cadre of people, myself included, who find leetcode and similar interview grinds unethical. I'd rather spend my time having a life or learning/building interesting tech. Interviews are then less of a performance art and instead a genuine 1-1 to work through a problem.
Ultimately, though, you're right. The problem is that software engineering interviews aren't actually about software engineering. And, that's what really needs to change.
What's your reason for thinking there are more "software engineers" than "programmers"?
The part of recent grads getting job is more related to market conditions, back in 99 recruiter would be happy to hire anyone who have attended the programming 101 while in 2001-2002 no one even wanted to talk to 5 -8 yr experience candidates right after the market crash
I have a portfolio that consists of six figures LoC of code, across dozens of open-source repos; most of which I am the 100% sole author.
I've written a fairly large open-source system that is rapidly becoming the world standard for a specific (rather small) demographic. It deliberately uses old and rather primitive technology (which is a big reason for it becoming a standard).
I've written hundreds and hundreds (probably thousands) of pages of documentation and Web site entries, designed Web sites, and helped hundreds of people and organizations to develop online presence (all for free). I've run instructional courses on a number of different topics.
I speak Swift without an accent. I can write ship-ready applications for every Apple operating system. I've been writing shipping software for over thirty years.
I'm good with device control. I've written embedded operating systems (long ago -different beast from today's).
And, of course, I can PROVE it. It's all out there.
And no one bothers to look at my portfolio when I've been contacted to apply for engineering positions. I usually send a couple of links to repos and/or blog entries that apply directly to the position. My portfolio leaves absolutely no question at all about what I can and can't do, technically.
I once even had someone insinuate that I had somehow faked my portfolio. I'm not exactly sure how they thought I did it. Maybe I hired an Indian shop to write tens of thousands of lines of code, hundreds of blog entries, design multiple Web sites, and hack GitHub and BitBucket to fake a decade of commit history.
At least, that was the reason they gave for ignoring the links I sent, and instead, giving a binary tree "Draw Spunky" test (I don't do well on them; never have, never will. I spend exactly 0.0 hours on HackerRank, practicing).
I stopped trying to look for work. I don't need it, and I was getting tired of the grind.
I just set up my own gig, where I do the stuff I want to do. Maybe someone will want to work with me in the future; maybe not.
I don't really care, and I'm quite happy.
I hear this a lot from software engineers, but it might be worth thinking about the underlying expectation that anyone should spend time poking through repos on the internet, why they would, and how hard it might be to standardize a hiring process that compares you to other candidates. Contrast your own opinion of HackerRank with the hope that hiring managers, who perhaps often don’t have the time, interest, or even ability to read someone’s portfolio to determine the quality of the code.
As someone who’s done a lot of hiring, I often glance at an online portfolio briefly, but I find it to be a low-quality signal for whether I will want to hire the person, and even for the technical ability. If I don’t know you, I can’t tell from your online portfolio whether you’re the sole author and/or how much you’ve contributed to a project. I can’t easily tell if you get a lot of your code from StackOverflow, or write it yourself. I can’t tell what motivates you, whether you love programming or you are hoping for a high salary.
While high technical ability is a requirement for someone I hire, it’s not actually the primary requirement. What I need to know is how adaptable people are, how well they’ll work in a team, how quick they are on their feet, whether they’re friendly under pressure, a whole bunch of things that you can’t learn from a github account. Communication, attitude, curiosity, optimism, and cooperativeness are incredibly important traits, as is technical potential vs existing technical ability. I seek out ways to hire people who can (and want to) learn quickly, regardless of current skill level.
Personally, I’m totally convinced by your comment that your technical ability is high, where you say it is. You would easily pass my entry filter and make it to an interview. But after that, I’d want to talk to you, not sit at my computer looking through your portfolio.
I learn faster, and much, much more comprehensively, these days, than I ever did when I was younger (I suspect because of the vast context I got from experience). The main reason I'm doing my own thing, is because I love learning so much, and I see there's a whole world of stuff to learn.
StackOverflow is a critical tool for me, but only a reckless madman would stock a majority of their code from there. I use it to solve occasional vexing problems, from time to time, and always modify the (usually tiny) snippets I may glean from it.
All the rest is mine. I've been writing original code, often far ahead of its time, since the 1980s.
I would have been happy to work for a fraction of the salary a lot of folks far less capable would have asked; simply because I love doing this, and the challenge of the job would have been the most important coefficient.
But that's water under the bridge, these days. Once I accepted things the way they are, and just started doing what I wanted, on my own, I became much happier.
Would love to hear a little about how you're making ends meet and still doing what you want on your own. Are you selling software, doing contract work, making money some other way and doing software on the side...?
I also have two corporations, one with restrictions, but decent assets, and one with few assets, but a lot of flexibility.
How are performance reviews done where you work? It strikes me that you have to do all the same things to see if the portfolio of work an employee has done _for your company_ is up to snuff. Because i’ve seen a few places that just offload this to some numeric ranking based on the subjective (nay, political) perceptions of one’s peers through a filter of imperfect, variable understanding of how the numbers should even work, and I hated that process just as much as I hate most interview processes. In a way performance reviews are like interviewing to keep your job or get a promotion, so I’d find your approach to hiring to be a warning about how the culture operates there.
Everything about how a person works, in your subsequent paragraph, is true. But parent is talking about their currently existing body of work, vs every stupid take home challenge to do some menial transformation of a data structure wrapped in polished UI. Not as a stand in for their personality or culture fit.
Hahaha, well I can't stop you from making bad assumptions. When I say I believe that online portfolios are a low quality signal, I am speaking from experience. I have seen first-hand people that look amazing on paper who were bad hires, and also people who didn't invest in their online presence but were rock stars. I'd encourage you to think a little harder about what you really want out of hiring and performance reviews, and whether online material is actually what you want to be measured by. Not only is online material a low-quality indicator of someone's work performance, it's also much easier to game, in ways that are both subtle and not subtle. If you prefer that someone reads your repo checkins over talking to you, you're letting other people figure out how to make themselves look better than you with less effort. I'm not even talking about unscrupulous behavior -- when the metrics are online material, you will be competing with others' online material. People who write better will tend to "perform" better, people who produce more code will tend to look better (even though LOC is a terrible metric), and people who borrow and build on others' code will tend to look better than people who write their own.
Are you really certain these are the metrics by which you want to be judged in interviews and performance reviews?
The job I have now, thankfully, has the lowest overhead performance reviews I've had at any other job, because my team believes that annual performance reviews are not a very good system at all. We practice continuous performance reviews by working with each other and giving feedback on a regular basis. You should never be surprised by a performance review, or have to wade through the last year's work to see how someone did. If you're doing that, something is already wrong, it means you haven't been paying attention. When you have a system that reviews people annually, even if people are keeping records, it still tends to result in people changing their behavior for 1 month out of the year right before performance reviews. Doing amazing work for 10 months and then getting put on a crappy task can undo your whole year.
There is no online substitute for talking to people; it's much, much higher bandwidth than trying to read code checkins. Once someone has demonstrated they can code, I don't need to check for that again. What I need to know is why someone made the choices they did, what their philosophy about coding is, how they handle themselves during code reviews, how they work with others. I need to know what people are feeling, how they see themselves fitting in, and what their dreams and aspirations are. You can't get any of this from online portfolios, not when hiring, and not when reviewing employees.
But in terms of hiring, you as a newcomer will be jumping into a codebase and are expected to be able to work in it quickly. A symmetrical relationship for a hiring role might be to be able to find something to talk about in a candidate’s portfolio. Could even have the candidate point out the region of interest beforehand so you can have a good talk about it when the time comes. Not unlike a code review for a PR.
For new hires, I like to have an assigned mentor for the first year, it really helps ramp them up quicker, and have good material for performance reviews if necessary.
There’s nothing at all wrong with reviewing code and talking about it with the candidate/employee, that’s highly encouraged, and I do it constantly. I just can’t spend a lot of time looking at candidate’s portfolios without them being in the room, I don’t get enough information from it, and the information I do get might be misleading.
I interview extremely well. I am empathetic, gregarious and genuinely like people. I have spent my entire adult life, getting along with some of the most difficult people in the world (long story, and has nothing to do with tech), and that has helped me to get along with people from a huge range of cultures and backgrounds.
Integrity is something that I take quite seriously. I live by a very well-defined personal code of ethics. It has served me well in my career.
It seems that I am not "cut out" for today's software development culture.
If you’re experiencing issues interviewing, there are lots of things that could be going wrong. It might be the types of jobs and/or companies you’re applying for. You might be shooting slightly too high or too low for your experience level. You mentioned plainly that you’d work for not much money, that could (perhaps surprisingly) work against you if you say it in interviews. It could even be sampling noise, just an unlucky string of interviews. But I’d hire someone like you on my team...
What's sad, is that people like me used to be represented by a certain kind of recruiter, more akin to a literary agent. They'd beat the bush, and get a portion of the take from that.
Apparently, this type of job no longer exists. I suspect that the big aggregator sites, like monster.com and Hired are responsible for that.
It's been a rather sobering experience. At one time, I had to fight off people trying to hire me away from my employer, to whom I gave a great deal of loyalty. When they finally rolled up my team, I completely understood it, and supported their decision; even though it cost my team and I our jobs. They treated us well, and with great respect. I had issues with the way they did things, in many cases, but in the aggregate, it was a great experience that I don't regret in the slightest.
I've been shocked at how standard recruiters haven't shown much enthusiasm. They are the ones that get in touch with me, gushing about my résumé, then quickly backtrack, for...reasons. I know why.
I've had to concede defeat, eat a huge platter of crow and egg-on-face, followed by a dessert of humble pie. I hadn't planned on early retirement, but there you have it.
Edited to add: One other thing. I tried sites like Hired and Upwork, and the contacts I got were 100% (not 95% -100%. Not one single legit contact). scams -some, rather scary. I have heard numerous people praise these sites, but they were all people looking to hire folks; not be hired.
To be fair, many of the scams weren't predatory. They assumed that I would be fronting as an American programmer, and shopping my work out to Indian programmers (who were the ones contacting me). I suspect that some of the contractors out there may not exactly be what they say.
> Apparently, this type of job no longer exists. I suspect that the big aggregator sites, like monster.com and Hired are responsible for that.
I’ve worked with Code Talent both when building out a team and when seeking a position myself and found that they work very much like this. I haven’t dealt with them recently, but they seem to still be going strong and doing what they do. I wouldn’t hesitate to reach out to them were I look to hire or find opportunities in the Denver area. Other than as a satisfied client on both sides of the table, I have no relationship with them.
Then perhaps this person should not be interviewing in the first place?
Why should an unqualified hiring manager somehow asses the candidates technical abilities ? This seems really bizarre to me. Imagine putting someone who is clueless about the medical field in charge of hiring surgeons based on some test score they took online, whilst completely ignoring their years of experience.
> I can’t tell from your online portfolio whether you’re the sole author and/or how much you’ve contributed to a project. I can’t easily tell if you get a lot of your code from StackOverflow, or write it yourself.
The OP has hundreds of citations in his portfolio. It's interesting that leetcode which can be gamed by a grad has more weight than multiple, well established projects.
If you place this much trust in applicants, you will most likely be micromanaging them as well.
This isn't the way to attract top talent.
> I can’t tell what motivates you, whether you love programming or you are hoping for a high salary.
This is what the in person interview is for.
> While high technical ability is a requirement for someone I hire, it’s not actually the primary requirement. What I need to know is how adaptable people are, how well they’ll work in a team, how quick they are on their feet
All these are valid points, but the discussion here is regarding whiteboard algorithms vs actual experience.
I honestly think it boils down to a few things:
- Companies are willing to waste the candidates time.
- Copying FAANG style interviews serves as a marketing tactic for startups (we have the same hiring standards as Google)
And finally an unpopular opinion:
- Asking Algorithm questions makes the interviewer feel smart, Especially if they are interviewing someone which is more experienced.
Look, this is the same as taking tests in school. Tests suck, but there's a reason we have to take tests and not just only turn in homework. The reason is that you need to demonstrate that you can do it on your own in a time-bound environment. Github doesn't demonstrate that even when you're amazing. Talking to someone who can ask questions about your abilities, and demonstrating your abilities on the spot is the way to do that, just like taking a test. I'm sorry it's less comfortable than posting online, but it's reality.
Leetcode doesn't have more weight than projects in my book, and I didn't mention it, neither did the top comment, so I'm not clear why you're saying that. Are you referring to the article?
> the discussion here is regarding whiteboard algorithms vs actual experience
The discussion in this sub-thread was about interviews & online portfolios. I wasn't talking about whiteboarding.
> Companies are willing to waste the candidates time [...] asking algorithm questions makes the interviewer feel smart.
I can't speak to all companies, you are probably right about many of them.
However, young grads today seem to feel entitled to easy interviews and job offers from all of them. What I hear in your post is some angst and frustration. I can understand that. I think it's a buyer's market. Getting a good job means figuring out how to stand out from the rest of the crowd, and it's really, really hard to do that with code alone.
It's true that companies are optimizing for their own needs, just as you are optimizing for your own needs. You can choose to see that negatively, as them wasting your time, or you can take more control of your interviews, and work to protect your own time.
The deal on offer is, if you pass the interviews, then you get paid well to code. Or, you can go start your own company and make your own money.
If you paid attention in school and understand algorithms, them you should think of algorithm questions as the easy part of the interview, something you can pass without problems. The questions are there to see if you care about algorithms and understand the basics. Don't take them personally, and understand that the questions are for all candidates, and they need to filter people out who don't know algorithms. So stop complaining about the easy questions, and start spending your time figuring out what the hard questions are and how to ace them. (Also, just FYI people who complain about certain kinds of interview questions is a small red flag in my book. If you love programming, algos might not be the exact thing you want to do, but it's part of the job pre-requisites and basic knowledge, so enjoy them instead of fighting them.)
If I have to become the culture in order to participate in it, then I will just take my toys and play in my own sandbox. I won't compromise my personal ethos, just because everyone else is.
As a manager, I took my Responsibilities very seriously. I worked for an extremely frugal and conservative corporation, and had to fight like a badger to get headcount. Making sure that the person that filled that headcount was top-notch was critically important, and I spent a great deal of time evaluating résumés and interviewing candidates. I would have killed for information like what you can get from a well-stocked SO story. Each candidate was a potential "family member." I kept them for decades. Japan wouldn't even recognize their existence until they'd been there for over a year.
Have you ever seen a designer get ready for an interview? I was trained as an artist (way back when), and know the drill.
They bring a large (usually black) case with them. It contains samples of their work; often including things like sketches and layout exercises. They go over the contents of this case with the interviewer; often telling stories about how they addressed some kind of issue, or the creative process that went into the work. I guess they may bring a laptop with them, these days.
No design manager in their right mind would ever think of ignoring the portfolio, and, instead, throw a matchbook on the table, and ask the designer to "Draw Spunky."
I'm not saying ignore people's portfolio. I'm only saying I don't spend a lot of time doing it before I talk to them. You also understand as well as I do that code portfolios and art portfolios are very different things, we can't compare those two types of interviews directly. It's easy to get a sense of quality from an art portfolio very, very quickly. At the same time, it can take days to understand whether a code portfolio has high quality.
You, as someone who'd done a lot of hiring, I think understands that a hiring manager doesn't have 4 hours to research each and every candidate at the resume phase before interviewing them on the phone, while also trying to write code and manage other coders at the same time. We take the best candidates we get, rank the resumes, look over the portfolios, reject any candidates that aren't prepared for the job, then call the top candidates and chat on the phone for a few hours, after that bring in the top from that set for interviews, which can be multiple days.
I also take hiring extremely seriously, and I've never had to fire someone, because we spend a lot of time talking with the candidate and making certain they'll fit in well on the team. That time spent talking is spent talking about their portfolio, having the candidate explain in their own words why they made the design decisions they made, why they chose to work on certain projects.
I would be willing to bet that in a face to face conversation, we would be agreeing damn near 100% on hiring philosophy and process. The problem here is it's hard to get across my motivation online in text. :P
My writing tends to be a lot more casual, and even a bit humorous. I like humans, and believe that the human relationships we make are the most important artifacts of our lives.
... That's a software engineer's everyday job, specially when just starting a new gig. In fact, the "reasonable time" part is often a pipe dream.
Someone unwilling (or unable) to read and try to understand someone else's codebase has no place doing technical interviews. That's literally the first thing that a new hire has to do.
You might have half point if you were saying that you discuss someone's portfolio during the interview (which would be analogous with the new hire discussing the code with the rest of the team to better gauge the decisions made), but you've said that you dismiss it and instead defend tests.
Speaking of that defense of tests: surgeons also had to do tests in medical school, yet they're not asked to perform routine surgery as part of their interviews (that I know of). This is to say that you were using a false equivalency.
> I'm sorry it's less comfortable than posting online, but it's reality.
Evidently, it isn't. What makes it easy for you (which is ultimately the real reason for those pointless tests) is not the optimal process. It's, in fact, the entire problem discussed in the FA and the comments here.
> Leetcode doesn't have more weight than projects in my book, and I didn't mention it, neither did the top comment
From the top comment:
>> At least, that was the reason they gave for ignoring the links I sent, and instead, giving a binary tree "Draw Spunky" test (I don't do well on them; never have, never will. I spend exactly 0.0 hours on HackerRank [emphasis mine], practicing).
What exactly were you going for?
> The discussion in this sub-thread was about interviews & online portfolios
One of the main points of the top comment was the explicit and deliberate dismissal of the commenter's portfolio in favor of leetcode type tests. I refer to the paragraph I just quoted.
> and it's really, really hard to [stand out as a programmer] with code alone.
Interesting, most of the programmers I know of, I know of them because their code is great; I'm here mostly thinking of authors of widely used open source software.
To reference a famous anecdote: I'd hire the creator of homebrew on the spot. You wouldn't even give him an interview.
> you can take more control of your interviews, and work to protect your own time.
In other words: Potential candidates should make your job easier by continuing the drill this whole discussion is about instead of complaining about how ineffective it is. How much of a problem this whole charade is.
That's just borderline insulting, and it's pretty clear that it is deliberate. I'm surprised it flew here, specially considering the featured article(s) and most of the other comments.
> If you paid attention in school and understand algorithms, them [sic] you should think of algorithm questions as the easy part of the interview, something you can pass without problems.
You called yourself a great programmer, I'll make no comment on that, but you've given me a good idea for how to screen which engineers should participate in interviews for when I have my own company: I'll ask them what they think of algorithm questions and I'll ask them whether they think that what is taught in college should be enough to pass those questions.
If they respond on the affirmative, I'll ask them the most obscure thing I can think of from any of my physics or calculus classes. Hey, after all, they "studied that in college", they ought to remember it even though it would be a gigantic coincidence if they ever actually had to use that knowledge in their job, and the question should be an easy point, correct?
Hopefully that will be a teachable moment, on how responding on the affirmative was wrong, maybe even unethical (because I sure wouldn't have asked that during their own interviews, with one caveat).
And this is, of course, ignoring the whole point of the featured article and the original one this is a follow up to: algorithm questions have devolved into being far more difficult than anything anyone had to do in college and they're something that 99% of candidates would never have done, or needed, in any previous job.
> The questions are there to see if you care about algorithms and understand the basics.
They aren't, GP comment was on the money by saying that they're just there for the interviewer to feel smart.
> Don't take them personally, and understand that the questions are for all candidates, and they need to filter people out who don't know algorithms.
Filtering out people who don't remember (as opposed to not knowing; for remembrance only a short refresher is needed, but that's something that a coding test doesn't give the time for) algorithms is a terrible practice unless the company doing the hiring is explicitly researching for algorithm design and creating knowledge as opposed to applying existing knowledge.
Or, in short, most people won't ever need to dive deeply into algorithm design in this field (most, if not all, of the algorithms needed are already baked into the commonly used libraries), meaning that filtering out the ones that don't remember is pointless at best, self-defeating at worst.
For the very rare cases (outside of the aforementioned companies that need to create new stuff for their products) where reimplementing an algorithm is needed (and there better have been enough research to know that it's not an example of NIH), a couple of hours of getting reacquainted with them is often enough.
> So stop complaining about the easy questions
You've given no reason to. In fact, by rationalizing it, you helped me see with even more clarity how much of a problem this is.
> Also, just FYI people who complain about certain kinds of interview questions is a small red flag in my book.
That's good, every person you rejected for that reason (along with the ones rejected over tests, specially if they had portfolios) clearly wasn't a culture fit and they are better off in a different company.
I just wish they could have dodged the whole hiring process you employ. Then again, I wish that for everyone, myself included.
> If you love programming, algos might not be the exact thing you want to do, but it's part of the job pre-requisites and basic knowledge
They aren't prerequisite for 99% of the jobs and I would say that, if you love programming, you would, well, program and let everyone know you do, like by contributing to open source software and building a portfolio. And yet you would barely spend a second of your time looking at someone's portfolio.
So whose criteria for "someone who loves programming" is the right one?
Finally, a disclaimer: I often do well in those stupid tests and have never spent more than a few weeks in between jobs, while my online portfolio is pathetically barren. Just to put in perspective that one can hate everything about the problem and rightfully complain about it while still having to play, and mostly knowing how to play, that awful game.
I can see that you’re frustrated by interviews. Why don’t you tell me more about your experience and what about interviews isn’t working for you? You said you’ve never gone long in between jobs, so why are interviews bothering you so much? If you’re just commenting on the awful game, why are you taking it personally and insulting me?
You took much offense to my explanation of algorithm questions without acknowledging that I agreed with the GP comment that many companies might be doing it for the wrong reasons. Still, that doesn’t make it a good idea to just speculate on the reasons companies use algorithms questions. Just because you feel like they’re pointless and interviewers are trying to feel smart doesn’t mean it’s true. Jumping to a negative conclusion isn’t the best idea, even if you’re right.
The person who’s criteria matters for loving programming is you.
You're the one defending rote tests (that literally only test for technical knowledge), not me nor anyone who replied to you (as far as I read).
From my previous comment:
>> You might have half point if you were saying that you discuss someone's portfolio during the interview (which would be analogous with the new hire discussing the code with the rest of the team to better gauge the decisions made), but you've said that you dismiss it and instead defend tests.
I value discussion, that's ultimately one of the things that matters most for a developer. And, mind you, thanks to git platforms (GitLab, GitHub, etc.) this is also becoming more transparent in portfolios, like by looking at how the candidate handles merge/pull requests and issues.
> your many personal insults directed at me.
Could you quote which sentences in my previous comment were personal insults? I'd like to know where I phrased myself poorly and apologize and/or explain my intent.
> If someone who was interviewing you read your comment, do you think they’d want to hire you more?
If someone who was interviewing me disagreed with any of my points, I guess not. Then again, I wouldn't want to work in such a company either; making it a win win situation.
I fail to see how this sentence is apropos anyway, HN isn't a job board.
> You said you’ve never gone long in between jobs, so why are interviews bothering you so much?
That's all but spelled out in the article and most of the comments, but I'll share my experience explicitly: I am yet to have a job, that used those leetcode type tests or generic coding challenges as part of the hiring process, where I needed to use the knowledge required for the tests or the challenges in the actual job.
It's a gigantic waste of time, testing for all the wrong things.
> Just because you feel like they’re pointless and interviewers are trying to feel smart doesn’t mean it’s true.
I'm yet to find a counterexample in any job I've had. You seem to be mistaking your own experience (assuming you actually do those tests for the "right" reasons) as the norm. Though I guess all of us are a little bit at fault of that.
> Jumping to a negative conclusion isn’t the best idea, even if you’re right.
You are the one who told someone else to stop complaining and even made another not-apropos comment about how complaining is a red flag. There's no way to interpret that other than negatively. If there is, I would love to read what you meant by that.
> The person who’s criteria matters for loving programming is you.
Alas, evidently it doesn't, because even hiring managers/interviewers/recruiters who comment in HN posts about the awful state in hiring for software engineers think that rote algorithm tests are of utmost importance, and I don't particularly agree.
I think the root cause of all interview issues is that interviewers aren't incentivized to care. You're never going to get promoted or even a good performance review for reading a candidate's code or ask them meaningful questions. On the other hand, it takes little effort to pick a couple algo questions and use them for everybody, and they still provide some meaningful signal. With alternative interview methods, apathetic interviewers will just rely on their intuition, which is how a "good ole boy's club" is formed.
I think maybe this is the unspoken issue with interviews - if a candidate was any good, they wouldn't need a job at all! So it's a given that all the people who apply are no good - the interviewer just needs to find the reason.
That would be believable if the same positions weren't being advertised for a year or more; e.g. I've had one position sent to me at least 5 times in the last year by different recruiters.
 In London, at least.
 Interesting work and a job I'd want but unfortunately the corporate culture is 100% no-go for me.
That can't be true simultaneously with "companies are having trouble finding good enough candidates", which is often said these days.
What can be true: There are many high quality candidates, and many positions looking for high quality candidates, but they cannot find each other and overcome matching hurdles.
So you have candidates applying to a large number of positions, and positions seeing applications from a large number of candidates, just because the matching process is so inefficient. Then both sides can legitimately complain about the large amount of work and time it takes.
There are reasons why the current IT hiring status quo seems to be so paradoxical.
Interesting link, thanks.
I've tried to reconcile that paradox by seeing it as a matching problem which requires both candidates and companies to be overwhelmed with attempts to find a good fit with each other.
However, reading the linked article gives another perspective on it. Which is, frankly, a worrying perspective for candidates, in that it suggests the labour market is shrinking and bifurcating (just like everything else these days) into "haves" and "have nots", where crossing from the latter to the former group may be getting more difficult with time.
I am quite aware that most positions are for folks that don't have my level of expertise.
I just love designing and writing software; especially software that connects to devices. I'll do it; whether or not anyone pays me.
If they want to own it, though, and have more of a say in what it does, that's another story.
A lot of the reason that I stopped looking for work, was because, almost instantly upon finding out that I am afflicted with eld, the microaggressions and veiled insults begin.
It's kind of amazing. People contact me, telling me how awesome my résumé is, then quickly backtrack, as soon as they find out it comes with grey hair. I guess the industry is full of 30-year-olds with 35 years' worth of experience.
It was really getting me steamed.
I'm not rich, and could always use the income from more work, but not badly enough to put up with that stuff.
I just make sure that people know that I'm "ancient," right up front, so we don't waste each others' time.
Other non FAANG/Unicorns that don’t pay as well as FAANG can drop the practice of asking DS&A questions. But for those companies that pay really really well, there will be insane amount of people that are willing to get a job there, and DS&A is a “May the strongest win” filter (although luck play a very strong role as well, yes there are stories where a junior job applicant get 4 Hard Leetcode out of 5 questions). I happily oblige. I happily will get through 1000 Leetcode and roll the dice (apply multiple times) if I need to in order to get that salary. No I’m not willing to get lower salary than FAANG/Unicorns, that’s why I’m doing this.
For companies that don’t pay as well as FAANG, just drop your DS&A interview practice, or just lower the bar, otherwise it is a waste of time for either the companies or the applicants.
TL/DR. The whole answer to this DS&A debacle is only 1 thing: SALARY. End. Period. No other factor matters.
You lower the salary, no one will bother with DS&A. You increase the salary, every single person on earth and their dog will study DS&A 24/7 to get that FAANG salary. Don't believe me? Head to Leetcode forum and reddit cscareerquestions. Actually we don't even need to go that far, just look at this topic on HN every single time. It is all about SALARY. Full stop.
Then why do they also apply this to candidates they reach out to? I've never applied to FAANG, only interviewed after (in-house) recruiters or internal referrals. It always seems to be the same bullshit.
Jokes aside, my point is, you can only get better, and when you get better, a non FAANG interview is actually a piece of cake, and you can just job hop every year until you maxed out your salary band, rinse and repeat.
Repeat after me: It can only get better, and one day you will actually conquer FAANG.
It is as follows:
Offer ridiculously low pay, such that only basic expenses could be paid for, like basic housing...
Then, see who shows up.
Whoever shows up... really wants a job.
You don't hire them yet.
You implement your own corporate bootcamp, where you give then coding assignments. These start easy, but progress, over a number of weeks, to those that are similar in form and difficulty to the type of work that the corporation does...
A supervisor or group of supervisors reviews their work after every week.
People who do not meet expectations are let go.
What you're left with after that process is your new hires.
That's how you cut down on frivolous resumes.
That's how you weed out the casual job seekers from the purists.
The purists don't care about money as much as working with the right people.
It's not for everybody.
People who need salaries obviously, beyond the most basic of living expenses, would be unable to apply...
If you want to be a dick and systematically screw people, just hire an army of agency contractors in some out of the way place.
...The intended goal is to figure out who is intrinsically motivated (i.e., curiousity, innate interest, desire to learn, etc.), from those that are extrinsically motivated (i.e., salary, money, title, career, corporate position, etc.)
I’m also not an idiot and I can readily bubble sort a low offer against my current comp and against the other offers.
Hypothetical scenario, tell the startups/VCs to pay more for software engineers, just a little bit lower than FAANG, then two things will happen:
1. Either FAANG will even increase their salary even more to attract type A types
2. A huge number of applicants of varying quality will flock to CS as an industry lowering the overall quality, forcing companies to do hard DS&A questions to filter applicants.
I posted what I said as a note to my future self, if/when I run a software engineering company... if/when that happens, then that's how I'm going to handle hiring...
2) Pay them to spend several weeks taking tests.
I'm curious what step 3 is?
Also you say that "The purists don't care about money as much as working with the right people." but you're intentionally selecting for the wrong people, so is this intended to avoid purists?
This will differentiate companies looking for true partnership with an engineer vs those who need hamsters in a wheel.
Take this with a grain of salt, because my experience may differ from many here (never worked at FAANG, I spent a lot of time at smaller startups in Boulder and am currently in Miami) but I have only been put in front of a whiteboard one time during many dozens of interviews and it was a generic logic puzzle to see how I performed under pressure.
Having been on both sides of the hiring table now many times, there is only one approach that makes sense to me:
1. Speak to them over the phone to make sure they are decent human being, verify again in person.
2. Be upfront with general compensation ability and expectations so that neither of you waste the others time.
3. Do a pair-programming exercise where they build a small piece of software that mirrors something that would be working on as a day-to-day there. Make it clear that finishing is not important, you just want to see their thought process and how they communicate. Ask them to refactor parts of it at some point to see how coach-able they are and how they respond to criticism.
This strategy has worked exceedingly well for me, and when I was on the other end of the hiring table the companies whose process generally looked like this were great places to work with good people.
Algorithm questions are a hazing ritual, and so many junior devs get sucked into wasting hundreds of hours practicing them when they could be building real-world skills. This practice has got to stop, IMO.
In my experience, the gap between the HN comments section and the real world is massive when it comes to hiring practices.
In the world of HN comments, most people tend to identify with the candidate rather the interviewers. The interview candidate is the hero, the underdog, and the person we're supposed to root for. The interviewers are bumbling fools, drunk on power and dead set on abusing their power to find flimsy excuses to reject candidates.
In the real world, most of the senior engineers I know have spent considerable time on both sides of the interviewing table. At different points in their career, they've been the ones asking questions as well as the ones being interviewed. This leads to a lot of cross-pollination of interview techniques as well as different perspectives on what works vs. what doesn't.
We can all agree that interviewing and hiring practices aren't perfect, but it's much harder to suggest better alternatives. At one point, I tried directly asking candidates how they'd prefer to be interviewed in a way that best highlighted their talents. A surprising number of people defaulted back to standard interview practices, but I also had a number of "just trust me when I say that you should give me this job" type answers.
These online discussions inevitably skew one way, because no one wants to be the bad guy defending the current imperfect status quo. Even the author of this article artfully dodges any request to suggest alternatives, instead falling back on the safe and secure "we have a lot of work to do" response.
I'm one of those engineers. The company I currently work at has no problem finding and hiring competent engineers. I also have no problem suggesting something better than what most companies do. And yet, whenever I interview at other companies, the most common interview experience I still have are the horrible ones described time and time again here.
The sort of "cross-pollination" you refer to is not widespread.
: A few times a year, just to keep my feet wet.
This is really cool to hear from someone else. I've done a similar thing, asking "What do you think you could do during a technical interview to best showcase your skills?"
I too got a surprising number of terrible/generic answers, though it very likely could have been nerves in the moment.
Is that really so far out? In many lines of work, you're expected to be trained into the position. My experience in software is that each company thinks they want someone who already knows X, Y, and Z, and can hit the ground running with no training.
But in reality, the hire will likely spend more time maintaining P & Q, and working on S, and will need quite a bit of domain knowledge as well as knowledge of the company's custom code and practices and internal organization before they're fully ramped up. And by the time they'd even get to work on X, Y, and Z, the company has likely moved on to A, B, and C, which almost everyone there is just learning.
It's a job that requires constant learning, and you're going to need to train your new hires whether you like it or not.
That's why when I'm called on to be the one asking questions, I mostly look for whether they enjoy learning and experimenting, whether they can have fun with old stuff and convey the differences between that and the new stuff (and why they're different), and whether they're open-minded or stubbornly convinced that they know the one true way.
That's the sort of thing you need when your old system has a decade+ of custom code and the dust hasn't even settled on the new system enough for the pros to know the right ways to do things with it yet. What you really need is someone with basic skills that's also open to being trained and learning new things.
Not just the algorithmic part, even the part leading up to it.
You have to impress a recruiter or an HR drone by listing all the buzzwords that are currently trendy.
Then, even after the algorithmic questions and interviews where you prove you can DO the job, you get rejected.
Every company I've worked for had trouble hiring.
I'm working for a company that also has trouble hiring right now.
Last week, the person interviewing our latest candidate told me that despite the candidate doing perfectly fine, he couldn't come up with something that he felt excited about doing in his current job, which was a red flag for him.
I tried explaining that perhaps that's something you shouldn't expect from someone who's at that point switching jobs.
We're still discussing how hard it is to find good people.
Most of the companies I've interviewed for also have trouble hiring, yet I've been rejected for the most asinine reasons.
These companies have the same positions open years later and not due to growth.
All this rant is to say, we're mostly doing this to ourselves.
I don't have a better way of doing things, but I can't just blame a handful of big corps for this, as if their technical interviews weren't designed by technical folks themselves.
And the funny thing is, that got us a pretty good set of people. Even funnier: both the very best of them, and the absolute worst of them, eventually ended up at Google.
I guess if you can spend what Google spends; have a ruthless hiring process; can afford to carry dead weight indefinitely; have a standardized engineering culture; and have an endless supply of projects covering every conceivable skill level and impact to the company -- then you can probably hire your way to whatever FAANG-like cohort you think will work.
But if you have those things you're probably already a FAANG-like company.
For everybody else, I am not convinced there is a better system than "everybody use your best judgement, and have people who give a shit do the hiring."
I'm part of another online community that has a strong emphasize on social justice issues. These "just wing it" hiring practices are one of their biggest complaints about tech companies. There's a perception that the less well-defined and structured your interview process, the more likely it is to produce vaguely biased results.
Whether that's true or not, it would be a tough sell to implement a "just use your gut" style hiring process at a major company in 2020. There is a strong push for standardized and repeatable interviewing processes, complete with sufficient documentation to support hiring decisions.
I personally find some of the current (if I can call them) standards of tech hiring to be very narrow in which skills and capabilities they test. It presumes a lot—particularly that one has time and resources to commit to spending time studying enough of the spectrum of CS subjects in order to pass a given question from the rather large field. (By this I’m referring to the classic “white board a <somekindof>sort algorithm purely from memory” process that has become the de-facto standard)
What would you propose as an alternative?
I’ve been involved in training new engineering managers how to hire and interview. Everyone starts with the best intentions, but reality quickly forces some compromises.
The bottom line is that you only have a number of hours in which to evaluate the candidate. The longer and more comprehensive you make your interview processes, the stronger signal you get. However, the longer your interview process, the more you’ll find people dropping out of the hiring pipeline due to lack of time or willingness.
I’ve worked with companies that tried to implement week-long paid interviews where candidates pair with employees to solve real problems. It’s great! But only when it works for the candidate. You can’t realistically expect busy professionals to take an entire week off of their current job to spend time with a company that may or may not hire them. Monetary compensation only goes so far when you’re forcing someone to choose between spending a week of their vacation interviewing with your company or spending a week taking their family on vacation.
Easy. Just talk to people as would-be peers. They want to find a role they can succeed in. You want to find someone who can succeed in the role.
I interview by just talking about their past projects (based on resume). You can't fake your way through a friendly technical dialogue if you haven't done it. (Pre-requisite: the interviewer must be technically competent. This is where many companies miss. Algorithm puzzles won't make up for it.)
Also it is important to describe the role and expectations in detail. Nobody (really: nobody) wants to get hired in a role just to be let go in six months. There is no need for elaborate whiteboard algorithm dances which discriminate against everyone who doesn't have the time to memorize every possible question. Just be up front about the requirements and let the candidate decide if it's a match. They know themselves better than you ever will.
What troubles me is that people will say this allows all your biases to run wild, but my feeling most of the time is that these biases will find a way to express themselves unless you remove humans from the hiring process entirely.
I absolutely disagree with this.
I've interviewed people who seemed incredibly impressive, both in terms of showing me actual past projects, and in their explanations of them. I've then gone on to give them simple programming exercies, the kind that people with far less experience take, and they've gotten nowhere on them.
I'm talking a two hour, "here's a computer, here's internet access, here's a setup environment, code this simple thing, which you could probably copy-paste from Stack Overflow / documentation". And they couldn't do it.
And what's worse - I'm pretty sure I could fake my way through most technical dialogues. I mean, not literally everything, but I could probably fake my way through interviews about most technical topics, and given a bit of preparation time, fake my way through most things. I mean, I could probably get caught out if someone was seriously trying to do it - but to the depth that most interviewers get, I can pass as experienced on most things.
You can’t pre-correct for some things, but you can for others.
Having someone speak in detail about their experience isn’t easily faked.
Having someone speak about their experience in brief and then giving them a “skill-testing question” as if they won the lottery can be gamed.
I think a general chat about a broad problem and the interviewee's thought process of how they would approach it can tell you much more than whiteboarding some memorized algorithm.
Good tests, I find, are to give them a simple piece of code with minimal comments. For example, some non-standard special purpose container implementation. Then ask them to explain what the purpose of the code could be as simply and short as possible.
- They'll start literally explaining each line of code without understanding the whole.
- They completely miss the point.
- They at least figure out it's a container of some sorts.
- They'll explain technically what it literally does.
- They'll give you the academic term for the concept it implements.
- They'll actually explain the purpose briefly in simple words.
Those last three are good, in different ways. The better ones will also spot the bugs or performance issues in the code.
I mentioned to a colleague that what I value most is someone who is creative. There are many candidates out there who know all the buzzwords or can discuss features of a programming language purely from memory, etc.
This can make for some impressive interviewing, but it tells nothing of their ability to use that knowledge to solve real problems, or their creativity in how they use their skill and expertise when faced with new dilemmas.
Sure, you could contest that the creative side isn’t necessary for certain levels of engineering, or that only tech leads require this as a mandatory trait, but I would argue that it is far more important than what most interviews test - rote memorization.
I've always tried to do that... until recently.
With a new recruit, this is the fastest way to nightmare discussions. He always emphasizes the cons of my proposals, and never admit that his proposals also have cons. To be honest, I really think he believes what he says, he seems to not see ahead of time where the blocking points will be.
I am now forced to only submit the pros, and prepare an argument for the cons, which is rarely needed. This is not a way to have good technical decisions.
This is not how it works! There are over 1000 problems on leetcode. Sure, many of them are solved using the same techniques but there is usually a twist and you often need to combine multiple approaches or come up with something new (to you). And then there is usually a very problem-specific way in which the problem can be solved 10 or 50 times faster. Often these insights are very difficult to come up with. The people who created these questions are actually very smart and excepting some of the questions at the easiest level it's usually a far cry from simply implementing Dijkstra from memory!
The problem with leetcoding in interviews is that it is easily measurable but not an important metric. Focusing on someone's aptitude at skills they never use at their job means good developers get tossed aside or are forced to waste energy jumping through hoops needlessly.
In my company (totally remote) we decided to automate hiring (also remote) as most as possible and we are happy with the results. We also value the candidate's time very much so we made the hiring process very straightforward. It works like this:
- First the candidates must do some online tests, which are mostly multiple choice questions. The subjects are logic, english and a specific test for the coding language. All of these tests were hand made to us and customized to our needs. The candidates spend about 2 hours in total doing theses tests, and they know immediately their score in the parts of the tests that can be accessed automatically (which are the most part)
- The candidates that are approved in the previous step - about 2-4% of the candidates that applied for the job - are called for an interview. Now is the time when we take a look at the candidate's resume and look at the human side of things. Given that we have very few candidates to look at and we know they all meet some minimum skills we are very confident when conducting the interviews. By now we usually have a very clear signal to tell who the best candidate is even before we conduct the interviews. So in practice the interviews are NOT used to select the best candidate. They are there just to see if a red flag doesn't show up.
We are very proud of our coding challenges app. If someone wants to collaborate on it just drop me a message. It's a Rails app on GitHub, but it probably not good enough for an open source project yet - one needs to know a lot about Docker and Rails to make it work.
Also, from experience, I've never come across a two hour takehome that actually takes two hours. Everyone always says not to spend more than two hours on it, but I can't exactly turn in an incomplete assignment.
I'm glad it is working for you, but it's not something to be proud of. Essentially what you've done is replace the standard 30 minute intro phone interview with a 2 hour SAT.
4 hours over two steps to get to the human part? I wouldn't mind it. Last company I successfully interviewed, I spent about 2 hours on the phone with different people + a lot of e-mail exchange, before I got to 4 hours long on-site.
That's asking for too much upfront before the candidate can even decide if the job is a good fit. Job descriptions alone don't tell you much. That's where the phone interview comes in. It's a two-way street.
I think when your company comes up with a hiring scheme, they need to analyze it, understand and be cool with the kinds of applicants their system is screening out. In my view, most SV tech companies' practices tend to screen out the "skilled professional who's currently semi-comfortable at her existing job" and filters in the "desperately needs a job and will jump through hoops and put up with whiteboard hazing to get one." Which class of applicant does your company want to court?
[^]: I consider myself "reasonably-competent" and the 100:10 ratio was about what my last job search was like a few years ago.
I understand this was the goal. You can either waste your company's time or the candidates' time. I don't think there's a way to preserve both. Given that your goal is helping your employer, this seems like the sensible thing to do.
If as mentioned previously wasting candidates' time filters out the most competent people, then you're not helping your employer.
Also, I object to thinking that someone's time needs to be "wasted".
But probably a lot of people that don't make it into your company just can't be bothered to do 2 sets of technical tests with zero human contact. I can tell you that my most "successful" interview processes (there is, the ones with offers/acceptances or just the ones I can even remember the name of the company) were the ones that focus on me as a human and as a professional, the ones that looked less automated and that seemed to have taken more time trying to know ME rather than just my skills.
Not that there was no tests, there were and some went kind of overboard with the complexity, but in the end what I remmember about these companies was the conversations we had and how they were interested and knowing me.
So, like I said, if it's working for you than great, but I probably would forget your test in my inbox to be honest.
Half the interview process is about selling the company to the candidate. How can I know if I want to put up with your bullshit tests if I don't know whether I'm going to enjoy working with you?
The message you're sending with more automation is simple: you will be a cog in a machine here. We're not interested in what you have to say, we're only interested in whether you're smarter than the average bear.
Programming or the fancy name of Software Development has sort of become the new blue collar job.
How many hours do you spend assessing each candidate and how does that compare to how many hours you make them spend jumping through your hoops?
Depends what you mean by "use your gut" but that's not my experience. Currently at a well known public tech company in silicon valley and there isn't any standardized interview process. Every interviewer is free to approach it as they wish and the hiring manager gets to listen to all input and decide. This is a strength.
Perhaps (very likely) as a result, this company is also rated highly in diversity.
A standardized interview process will inevitably lead to a standardized employee pool, as only the candidates who fit the very narrow profile (willing to memorize endless algorithms they will never need or use in real life) can get in.
I should add that my current employer is not, in my experience, unusual. In my ~25 years in the valley, it's how it's always been. I have not worked (and never want to) for the companies which value conformity in hiring above all else (infamously, google).
And for the social justice aspect, we do have a very diverse group of engineers, especially for our size and location.
If so, how are they "objectively" evaluated?
Do chemists recite the periodic table backwards in interviews?
I don't pretend there's never any bias, but I'm still not convinced you get any less, or any better bias with the whole hoop-jumping algorithm day-long whiteboard thing.
As has been noted elsewhere in the comments here, ours seems to be the only industry that does this to itself.
I feel "just wing it" can lead to somebody talented from a non-traditional background getting a chance at a great career that they would be auto-rejected by google at the resume submit phase.
Which seems reflective of the underlying pool of applicants.
It would be interesting to see what their application/success ratio demographics are like.
How many of them hold relevant degrees for job openings at Google?
There's even a sourced 2018 article about current hiring practices trending away from degree requirements for you to peruse:
It's not about the degrees (relevant or otherwise).
Of course the most important thing is: out of minority applicants who are qualified, what percent are hired? Because we may expect a smaller proportion to be qualified due to systematic barriers that they face. Google is not necessarily in a position to fix those.
I'm willing to bet that Google's demographics hew pretty closely to CS graduate demographics. You need to look farther upstream.
Standardized processes don't mean unbiased processes. The SAT for example is pretty racist.
Is it equally racist now versus in the 90s?
What do you mean by this?
You want your company to be 50% women? Tell your teams that at least 50% of their hires must be women. That's it.
To me, formalizing the quota but keeping the overall hiring process looser makes a lot more sense than the other way around. A quota is dead easy, and a formal process is hard for all of the reasons discussed.
A quota is not "hiring people just because they're female/black/gay/etc"—it's a way to make us more effective by preventing us from overlooking good people. If we're naturally inclined to skip people who are black, then we need a process to counterbalance our natural tendencies. And of course, recognizing and taking advantage of an undervalued resource is good for business.
If there are legal issues with a quota (I'm legitimately not sure whether there are), then the law ought to be changed.
50% women may be the wrong number because of the demographics of computer science majors or what have you. It was just an example. Choose a number in good faith that you believe represents the potential population of good hires.
One simple solution might be to have your quota match the demographics of your job applicants. But this decision bares more thought than I'm qualified to provide.
That would be quite literally destroying the anti-discrimination laws which safeguard the exact thing that you think you're arguing in favour of. Quotas implemented the way you describe are the antithesis of equal opportunity. That 'instinctual negative reaction' you come across is people seeing the complete logical reversal going on in your claim.
This is a subject of entire books and hours long debates, but we can skip to the reductio ad absurdum with your line of reasoning: 99% of underwater welders are male.
Trying to 'represent' females in that occupation and push the gender ratio to 50/50 would harm all parties involved and result in a measurable number of deaths. Protected attributes are not uniformly distributed in terms of fit for job, and trying to hit a uniform quota across those attributes is naively idealistic, at best.
A less generous interpretation is that you are actually totally cool with discrimination as long as it's in the 'right direction', whatever that personally means for you. In which case you are exactly the force that you claim to be fighting against.
The notion of reverse racism is something that requires religion-like amounts of self delusion and selective consumption of facts. The flaws of the notion are just too glaring for any rational individual to overlook even at first examination.
Not only that, but it's blatantly hypocritical since you don't spend your money based on the demographics of a company, you spend it based on performance.
Edit: This leads to a much more interesting line of discussion that can be summed up as "discrimination (and similarly bias) isn't always bad".
They're useful tools and we should be careful about practicing them, but the idea that because discrimination is sometimes bad it is always bad doesn't follow. (or an alternative way of looking at this is that discrimination often includes the qualifier "unjust". Bias in favor of some group in the pursuit of greater justice therefore isn't discrimination).
Profound injustice in favor of averages is not an acceptable social trade off. This is why countries enact general discrimination laws, making it illegal to judge people based on single bits like gender and race.
For example, in most places in the US it's okay to discriminate based on political party, and I don't know of any jurisdiction where you aren't allowed to discriminate based on someone identifying as a racist.
Political affiliation, political views, political association, all those are protected.
The state can step in if it is in the interests of national security or to preventing of crime, but it is just as wrong to discriminate someone who identify as a feminist as someone who identifies themselves as a racist.
It should also be noted that where I live, Sweden, the right of political association is particularly cemented in our constitution. The same protection that is given union members are given to political members, including racist political groups. People talk about changing the constitution whenever neo-nazists goes around and demonstrate, but that kind of talk usually dies down when people realize that life goes on even if a handful of people believe in something which the rest of the nation consider crazy.
It appears that you're conflating government nondiscrimination with government mandates on individual nondiscrimination. Those aren't equivalent.
Here in Sweden, yes. The law is very clear that you can not deny service because you disagree with someones political, religious, or world views.
Government nondiscrimination is a US technicality of the first amendment. European Convention on Human Rights is not limiting to government behavior. Everyone has to follow it.
I think you should speak with a lawyer, because you're not correct.
The report also note that current law does not protect children that get discriminated based on their parents political activity, which the FN convention of children rights says they should be protected against.
The report goes on to basically say that the EU convention of human rights extends the Swedish anti-discrimination law to include, among other things, political and other world views, class, and social status. The report then goes on that courts must already follow those extensions.
There were also a specific case a couple years ago where a politician was kicked out of a restaurants based on his political affiliation. A Judge commented on that case noted that while the Swedish anti-discrimination does not make it illegal, there is a case to be made under the EU human rights declaration.
So there. The government report, and a judge, both saying the same conclusion.
Genuinely asking. My morality follows from basically “discrimination based on immutable personal characteristics is always bad” (with the possible exception for family, bwcause that’s just cruel), from which I cannot conclude for example that discrimination is bad if it’s agains blacks but good if it’s against whites.
I fear that by dropping this principle, while allowing for “positive discrimination” (e.g. preferential hiring / admissions of blacks/women), you also allow e.g. White Nationalists to argue that it’s OK to discriminate for whites. How would you convince a White Nationalist that such discrimination is bad while leading by example that other kinds of discrimination are just fine?
> My morality follows from basically “discrimination based on immutable personal characteristics is always bad”
As a bit of an aside, are you saying that this is your base moral precept from which all other decisions about what is or is not ethical follow? This would be a very strange ethical framework (for example, it follows that murder is ethical). Usually moral and ethical frameworks follow from very high level principles "optimize happiness/utility" (utilitarianism), "do good things" (deontology), etc. It seems like you might be coming from a rights based ethical framework, but it's not clear.
> How would you convince a White Nationalist that such discrimination is bad while leading by example that other kinds of discrimination are just fine?
I don't generally waste my time arguing with people who are engaging in bad faith. In this day and age, I don't generally believe that a white nationalist is going to be convinced by facts and logic, or really anything else. I'm more concerned about appealing to the majority of people who aren't white nationalists, because ultimately I believe that discriminating against white nationalists is okay.
Ok, now back to your actual question: in what cases is it okay to discriminate? I'm approximately utilitarian, so the simple answer is "when the expected value across society is positive." For me, I don't think optimizing for strict utility is the right goal, instead I personally think that we should maximize agency (possibly median, possibly total, unclear exactly), which is something like each individual's ability to make meaningful decisions.
This sidesteps issues of de jure rights. It leads to conclusions that we should do things like lift up the least fortunate and provide social safety nets, since a destitute person has less agency than a person capable of getting by. Similarly, it addresses questions of when regulations on personal liberty are ok. If allowing some action has a reasonable possibility of reducing agency of some other group, we should give it less protection than another action which does not.
So for example, when you have two groups, racists and some racial minority, it makes sense to provide the racial minority more protection than the racists, since the racists want to reduce the racial minority's rights more than the racial minority wants to reduce the racists rights. That is, the minority would prefer it if the racists weren't allowed to be racist. The racists would prefer it if the racial minority weren't allowed to live in the same area, or use the same water fountains, or what ever.
That's an extreme, but illustrative example. So back to the less extreme position: Discrimination is okay when it's done explicitly to counteract a gap between what the law (or more broadly society) intends and where society actually sits.
Society intends for hiring to not discriminate based on race. But it did for a really long time. The put (and continues to put) the subjects of discrimination at a disadvantage. If you're deontological, then "nondiscrimination" is the rule and that's that, but if your goal is justice or utility, then discrimination to bridge the gap between intent and reality is ethical. It should be done carefully of course, but it's alright.
If you want to see a fun set of examples of this, voting district and gerrymandering law in the US is full of weird examples of trade offs between the need (under the Voting Rights Act) to allow racial minorities to elect representatives of their interests, with the current opinion of the USSC that any districts can't be drawn based on racial lines (except in very specific circumstances). In other words, States must draw districts to preserve the interests and representation of minority groups, but can't draw districts based on where those minorities live. It's weird.
> If you're deontological, then "nondiscrimination" is the rule and that's that, but if your goal is justice or utility, then discrimination to bridge the gap between intent and reality is ethical.
I'm definitely pro-justice, it's just that I see it principles based (e.g. free speech even for (especially for) speech I don't like), not "utility" based. The flaw of your philosophy, in my view, is that you're just sweeping the tricky parts under the carpet by introducing concepts of "utility" and "right goal" and "society intends". You're even conflicted about that yourself, introducing another concept of "maximizing agency" (sounds like pro-freedom); a good moral system would somehow maximize (or balance) both in some way.
I don't think that's a good view, because those are fundamentally non-reconcilable goals. Should a billionaire be able to spend $1m for the health of his/her child (maximize agency / freedom), or should the society put that money to "maximum utility" and spending it to help several (poorer) children (with illnesses that are less expensive to treat but still life threatening).
Sure, picking the "right" utility function is one of the hardest parts of utilitarianism. FWIW, I don't think maximizing agency is a different concept so much as a specific utility function that avoids some of the common pitfalls of strict utilitarianism (utility sinks: the person who gets enormous happiness from cannibalism). In other words you could imagine Agency as the "reasonable person" standard applied to the value of a choice. This still has flaws, but, IMO fewer than many other framings.
Some people might also find this to be similar to optimizing for the most "positive rights" across society, but I dislike that framing because the idea of positive vs. negative rights is silly, any right can be framed as positive or negative.
> Should a billionaire be able to spend $1m for the health of his/her child (maximize agency / freedom), or should the society put that money to "maximum utility" and spending it to help several (poorer) children (with illnesses that are less expensive to treat but still life threatening).
Note that giving a poor person money such that they can choose to treat their child's disease also increases agency! If you want to dive deep into this, I think that the marginal value of a dollar is probably logarithmic, or at least inverse quadratic or something, so a tax scheme modeled to tax top brackets in such a way that then improves the situation of those less off (pick your method: national healthcare, UBI, etc.) increases overall agency.
I think most people making a case for 'good' discrimination don't realize that the existing 'bad' discrimination originated exactly the same way.
We need to strive to eliminate discrimination, not perpetuate the swing of the pendulum that's been going back and forth for hundreds of years. Pushing down on some demographics to uplift others is not going to solve anything, it's just a no-op perpetuation of what's already going on.
The historical discrimination did not originate from people saying "yes discriminate against me in the interests of general equality". In fact, to return to the start of this thread: historically much discrimination was the result of bigotry. It's very unlikely that hiring quotas (or similar) are the result of bigotry.
Your conclusion also doesn't follow at all, at least not without some argumentative work that you haven't presented. Suffice to say that I believe that the best way to, in the long term, eliminate discrimination is to allow some specific forms now, with the intent of undoing past discrimination.
You haven't presented even a shadow of an argument as to why that isn't reasonable.
The way to create equality is to manipulate on levers that individuals can control, e.g. taxation brackets, education incentives, government investment into particular industries. Passing up the best candidate for a job because they didn't have some inherent unchangeable attributes that you're arbitrarily favouring is the opposite of creating equality.
I do not know what the costs, efficiency and employee happiness would be, but it would make for an amazing social experiment. Having 40% of the garbage men, sewer workers and construction workers being women, and 40% of the teachers, nurses, and social workers being men would make for a very different society than what we have today. There would be a lot of people trying to cheat the system in order to keep the work place gender segregated, but I wonder if that is a local maximum of happiness rather than a global one. Such study could shine some light and give us some final answers if quotas is a good idea or not.
(While there's a separate discussion to be had about why so few women choose to be engineers, that's not the company's problem to solve.)
There's no logical reason why "10% of engineers are women" implies "10% of every engineering team should be women" instead of, for example, "10% of engineering teams should be all women".
A number of teams could be 40% women even if the average were 10%, and there's also no reason why excess men have to be engineers just because they were educated as such. That's a thing that happens anyway, just like people without CS degrees go into programming.
1. I hit the wrong button :)
2. I'm a bigoted member of a majority, and am downvoting because I think minorities should be oppressed.
3. I don't think any questions of race/gender/etc. should ever be considered in a workplace, and and downvoting because I dislike the whole idea.
4. What I suspect is actually happening: Like (3) I think everyone should be considered on their own merits, and you can look at company-wide stats to see if bias is occurring. Its good for the company to act against it in sum, but acting on the basis of race/gender/etc. on an individual basis is shocking and unfair.
The problem with (4) is that you're trying to have some kind of emergent effect that magically appears. It's a goal without being a goal. Worse, its a global goal you want to be actively worked against locally.
Developers love to complain about clueless management that doesn't know what it wants. Guess what folks, it's a common trait. Our other favorite trope is to figure out a technical fix for a people problem. And the problem with that is of course a tech fix only takes care of specific situations and not the underlying problem.
For example, as a tech fix we might decide that all interviews are done in a pitch-black room with vocoder voice synthesizers. Great, no question of race/gender/etc. Except, of course, for selection bias in our candidates. And even after they are hired there's biased reactions (unequal success for equal quality). People just naturally favor familiar attributes, even if those attributes don't contribute to a correct outcome.
So to be consistent, there are really only three choices: a) don't care, let the chips fall where they may; b) have an actual goal to equally represent everyone; c) encourage playing nice, and hope the results aren't too far off.
What actually happens, of course, is d) encourage playing nice, hope the results aren't too far off, then someone actually looks at the results and complains, so flail around trying to avoid doing anything too unpleasant to fix it.
So, while I wholeheartedly agree that diversity inherently benefits teams and businesses (different experiences will lead to new and different approaches), it's just not a very convincing argument, because it feels "mushy". Here's one that I think is better:
If it's true that e.g. women have a harder time getting engineering jobs due to unconscious bias (and I'd posit that this is clearly the case), then that means female engineers are, as a group, undervalued. You should be able to hire a better female engineer for the same amount of money.
Harsh? Sure. But that's beside the point.
For the tech sector, in developed nations, this is nonsense.
The evidence for that is dubious
What did they do? Suggest sacrificing a puppy to moloch to make a feature release go smoothly?
This is my least favorite part about discussing interview techniques.
It's taboo to say anything other than "interviews are broken", as if there is some alternative perfect practice that companies are voluntarily choosing not to use.
If no one, including the author of the linked article, can think of anything better, doesn't that mean that companies are already using optimal practices? At least from our current knowledge of interviewing practices. I always have my eyes open for new research, new suggestions, and new trends, but it's getting old to hear the constant chorus of "interviewing is broken" with zero attempt to suggest improvements.
That doesn't mean current practices are perfect or that we should stop trying to improve them, of course. It does feel a bit like politicians going on record saying that they're "deeply troubled" by something without proposing alternatives, though. It's the safe thing to say.
Not necessarily, it might just mean that the more optimal approaches are not obvious. It seems extremely unlikely that the current approach is optimal.
>At least from our current knowledge of interviewing practices
You have three promising candidates? Instead of trying to extract signal from gimmick interview tactics, hire them all and put them on a 3-month contract with the opportunity to renew to full time. Then you're giving them real weork instead of easily crammed questions, and remove some of the anxiety affecting interview performance.
There’ll be no shortages of applicants for quite some time but really destroys the society. So no.
No unless I’m guaranteed that upper echelon slot to judge them — no I wouldn’t want to live in a society like that.
On the other hand, I think it may be a good idea for the company to consider:
- either hire fulltime somebody, who has solid track record and "prooved" themself during on interview
- offer 3 months contract to someone, who is not that good at passing interviews, so they can prove themself doing real work.
On the other hand, another company I applied to that seems really desperate for developers (no fewer than 9 open dev positions when I applied) completely dropped the ball. During the screening process they asked me to do an online test that took me about 2 hours. I got 100% on the test but it took the HR rep an entire week to respond. The response? The same canned email I received when instructed to take the test. From the same person. After a back-and-forth it was confirmed that they did receive my initial test score and I didn't need to retake it. About a month later and they never did get back to me. Sometimes I wonder if companies even want to attract good talent.
Sometimes we find a unicorn and want to make an offer. They get hired by FAANG after our interview and before we send the offer. Wonderful.
Contrast that to my side hustle where I sometimes hire folks to help out with coding so I can focus on other stuff.
Go into 1 or 2 Slack/Telegram groups "Hey anyone need work?"
Exchange 5 texts with 3 people.
"Okay here's a project, how much?"
Pick person. Get job done. If I like the way it goes, they get more jobs later.
Whole process from search to hire takes 1 week.
But at the dayjob we're a funded startup so we gotta be choosy and picky and make life all sorts of hard in the name of I'm not even sure what. We wouldn't even consider a part-time contractor because commitment is worth more than getting the job done.
Needless to say that company had a lot of problems with technology. But they seemed to be good at making money strangely enough.
Companies that really want to hire are flexible. Maybe they need someone to do Python but they've found a good candidate who has all of the other requirements except for Python - but they happen to be really experienced with Ruby. Well, OK, if they're really experienced with Ruby they'll be able to pick up Python in a month or so. Sure, they may not produce the most pythonic code for the first six months, but that's what code reviews are for.
I've been in this game since the 80s. Back then companies weren't nearly so picky it seems (at least not in my memory). The second job interview I had out of college in 1986 at a startup in the valley went like this (it was an embedded/hardware job):
Interviewer: We just got this new CAD system. I'm going to have you sit down and play with it for several minutes. When I come back I'd be really interested in hearing your opinion of it. What are the good and bad parts?
And so I play with the CAD system for a while and when he comes back I give him my opinion. And he agrees with my assessment.
Interviewer: I've got this schematic here and a breadboard, some parts, power supply and test equipment. Do you think you could hook the circuit up while I attend to some other business? I'll come back occasionally to see how you're doing.
I wire up the circuit, get it going, look at the output on a logic analyzer. Interviewer comes back and seems happy. After this he asks when I can start.
This took all of maybe 2.5 hours. In the 34 years since then I've only had a couple of other interviews that seemed that... I dunno how to put it, maybe "natural"? And both of those were in startups. They wanted to hire someone. They needed to hire someone.
Back in 2001, I dropped out of tech and became a land surveyor for almost 10 years. Now, land surveying or civil engineering is not the same business at all as software development, but they are both technical and there is some overlap in terms of engineering and outcomes.
My technical test and interviews were all completed on the same office visit, and I got a decision in 24 hours! Just think about how incredible this would seem today. First, I was welcomed by an engineer who gave me an overview of the company. Then, I was taken to a conference room and given a trigonometry & statistics test that took about 45 minutes for me to complete. Then I waited in the engineering library and browsed books while they graded my test. When my results came back, I then proceeded to the interview proper. After that I was introduced to the CEO of the company and escorted to the lobby.
The very next morning, I got a FedEx envelope with a proper offer letter. They really needed a good instrument man and they got one in 24 hours. Throughout the entire process, everyone I interacted with was completely professional and prompt.
What do your counterparts at the company think the source of their hiring difficulties is? If not flawed process?
But when you reach the final stage with 3 people who you know can pretty much do the job, who you know have successful careers working in successful companies, and you drop them because they didn't exactly behave the way you would prefer them to in a high stress scenario, and keep looking, I think you effectively forfeit the right to claim that's your problem with hiring.
I didn't think of the solution you had in mind, because I've identified another problem that you didn't consider. And somehow that takes me out of the running. Good luck with that.
Not to mention the nebulous and vaguely discriminatory "cultural fit" problem. So, even if I manage to ace the technical, I still fail.
Then I recently had an interview myself (thank god for no pressure) where I was asked to do more or less the same thing myself, and I totally blanked. It took that to make me realize it probably wasn’t a good problem.
At the same time, pretty much all the candidates we’ve hired have worked out.
I’m starting to think it might be easiest to just hire anyone that applies and doesn’t seem crazy.
> I tried explaining that perhaps that's something you shouldn't expect from someone who's at that point switching jobs.
Ugh. You are, of course, correct.
They want "the best candidates" but when they get one that's evaluating new positions they go on about "why do you want to move", "candidates don't seem to enthusiastic about our company" well maybe because you're not enticing then to move, quite the contrary.
Good candidates get hired (from an unemployment/"underployment" pool), excellent candidates get poached. Sports teams gets that but apparently if it was a software company they would ask Michael Jordan if he would be able to hit a 3 pointer
I had a great job lined up, perfect fit for me and them. But my SO has a condition. The pill my SO takes everyday costs ~$1-5 per pill with most insurance companies. The substance is used in horse feed, just like how humans put vitamin D in milk, or iodine in salt, this substance is put in horse feed gratis. It does not appreciably change the cost the feed.
When I looked into the health insurance for the new job, the pill would have cost us ~$100, so ~$3k/mo or ~$36k/year. I, obviously, had to turn the job down.
That US healthcare is completely broken is not just contained to families, but it leaks out over our whole society. A perfect hire, ruined because of shitty healthcare.
If you do good enough work at a job that your coworkers will want to work with you again, you've got it made and can choose between jobs for the rest of your career.
If you don't impress coworkers that way, you need to go through this crazy stranger interviews talked about here. Do try hard to avoid that!
In all the companies I've worked for, referrals for ICs meant that these people were prioritized for interviewing, not that they skipped the process.
And no one, not even the manager of the hiring manager, had enough say in hiring someone that they could simply decide to skip the process
This means one phone screen of about 30-60 minutes to both introduce the candidate and decide if they are worth a follow-up with the team followed by a one hour interview with the whole engineering team more focused on technical capabilities directly related to the job. Finally, just to be sure, a one hour take-home assignment that is simple just to make sure they are not bullshitting. This last one only goes to the top few candidates of which one will be chosen (assuming they can code the simple assignment). People have been hiring this way (ok minus the coding assignment) for decades, maybe even a century or more. And you know what? It works.
Now on to the second requirement: having a company that's worth working for. That means a company that at least partially values its employees. The best way to do this if you don't have FAANG money? Remote work. Ideally for everyone. That guarantees your pool of hiring (even if limited to certain locations for artificial reasons) is much higher and the demand for the job will be huge. Other things that make a company worth working for: good salary, yearly raises, performance bonuses, 40 or less working hours a week, flexible schedule, decent managers who understand engineering, interesting tech, etc. Note that none of those is out of reach of any company, even the smallest small-business.
So yeah, let's stop with this bullshit that we don't know or can't think of a better way to hire. That's idiotic and frankly, closed-minded. Let's stop pretending like there aren't a ton of qualified candidates just waiting to be hired when there are so many. Let's give people a chance for once to prove that they can do the job. Not everyone will work out, but you know what, in the US with at-will employment, that is not a big deal. Doesn't work out, fire them. Easy fucking peasy. If you can't do that, you shouldn't be leading a team/company.
My company currently works this way and we have had NO problem hiring. Whenever we want a great candidate, we go from resumes to hired in less than a month. There is nothing special about us. We don't pay top dollar. We don't even have a lot of the perks I listed above, but we have enough of them that candidates love us and we have no problem attracting great talent (the top one being remote work, of course). If a company isn't willing to make itself desirable, I have no pity for them. It's like never showering or grooming and expecting to find a hot girlfriend. Highly unlikely.
A month is considered fast?!
I guess as long as the great candidate you're hiring is not looking at other options.
A recently saw a recruiter lamenting that their clients needed to be told that if they don't make a hiring decision within 2-3 days of introduction, they tend to miss out on the best engineers, who get offers from elsewhere within the week and take them.
If you have a steady stream of equally capable, qualified candidates, it's a buyer's market and you don't need to do anything. Carry on :-)
There are other companies who complain that they can't find qualified candidates though. Some of those have those positions that stay open for months.
Those are the ones the recruiters urge to change practices so they have a chance at getting "the best" engineers, on the rare occasions "the best" interview with them. The seller's market situation, where buyers need to compete.
It sounds like you don't have that problem though.
Is the amount of youth in tech part of the problem?
I've outlined it here before. Been using it and tweaking it for the last 3 or 4 years. I keep bring it up because it's a tested alternative to the usual death marches and dumpster fires and it has been a success for the teams I've led and our applicants.
The principles I've defined to guide our process:
- Hiring cycles will be structured and as short as possible.
- When we start a hiring cycle, we will finish it by hiring the most qualified applicant who accepts our offer.
- Every applicant will receive a response within 48 hours and be updated on the status of their application at each step asap.
- The hiring process will be as transparent as possible.
- Objective and fair-minded measures will displace biased and bigoted ones.
- Every applicant will appreciate their experience, even the rejected ones.
- The process will be agile and adapt over time to improve and meet the specific needs of the organization.
- Onboarding will begin with hiring.
One problem I'm confronting at the moment. As our company grows, we've brought on a new HR lead who wants to jam the process we've been refining over the last couple years into a new ATS (Applicant Tracking System) that could significantly screw up our meez. We'll see how that works out. I'm doing everything in my power not to let it fall apart.
If you have the power to improve the situation, please do so.
 For an outline of the process, see https://wiki.klenwell.com/view/Hiring
Most of our work is on web applications, primarily Rails. So, for that role, the challenge is to fix an issue in an implementation of Fizzbuzz on our sandbox Rails app. We give the candidate about an hour to work on it. It's not as trivial as the common Fizzbuzz exercise but it's a pretty representative sample of the kind of work we do.
As part of the phone screening, we check to make sure the candidate understands there will be a code challenge involving Rails and that they're cool with that.
There's a handout we present before we turn over the laptop that explains the issue and clearly defines requirements (e.g. create a branch with this name). We read a brief intro section then give the candidate time to review the requirements on their own and ask them if there are any questions. Candidates are reminded to read the README included with the project and encouraged to use the browser to Google stuff.
One tweak we made was to add check-in stages to the challenge to make sure candidate doesn't get stuck for a half-hour trying to open up the text editor or something. Every 15-20 minutes, a team member will check in with candidate and if they haven't hit a certain milestone (e.g. has started local server or had reproduced issue), we'll assist them in getting to it. At the second or third check-in, it usually turns into more of a pair programming exercise and at the end we'll review the solution with candidate so they understand why the problem is relevant to the job.
There's not a definitive pass or fail for the challenge. The candidate's performance gets scored on a simple 1-5 scale alongside the other competencies we're evaluating as part of the interview. We're pretty thorough about preparing the code challenge and consider it a good example of our "onboarding begins with hiring" principle.
Even sticking to the pure 'trivia' aspect, there's just so much of it that people are missing altogether. (Sure, maybe you can write out a nifty algorithm on the whiteboard, but can you sketch even a very rough proof that the algorithm is correct? I don't think many people can do anything like this. I'm not even sure that the topic of correctness comes up all that much in a CS/SE curriculum - which is surprising, since we are supposed to be doing engineering. And yet, someone who is familiar with what provably-correct code might look like in practice will likely be a lot more productive as a result.)
People blindly and dumbly implementing any practice is going to yield bad results. I've interviewed for Google, for a small company with a crappy pipeline and a low need for talent, and for my current job, which needs Google-level talent across multiple specialties. Whiteboarding has played a critical role in all of these. The goal isn't to have them answer trivia questions in marker, it's a basic test of their ability to think critically and program. Naturally, the exact questions differ based on the role: for the second job, it was basic processing of data structures, while for the third, I got a question that involves some degree of spatial reasoning. But in general, this is a pretty fundamental way to test a pretty fundamental set of skills.
I even was lucky enough to get a negative example: I ran the tech org for the second company, which had two non-technical founders. We hired a candidate with no engineering experience on my recommendation because he did very well in his coding interview: this guy ended up being the most reliable, clutch engineer in the company. I also rejected a candidate on the basis of failing the simple whiteboard problems, and the founders decided to hire him anyway based on his years of experience. The founder ended up having to bounce him around from task to task, leaving a trail of destruction wherever he went. His code would bring production down, he'd create weeks of work for others in a couple of days, he utterly destroyed devops during his brief tenure there, etc. He was very sweet, hardworking, had a great temperament... But the inescapable fact was that he was just kinda dumb. The whiteboard interview handily caught this, _which is what it's supposed to do_, and all the HN sniveling about whiteboard interviews only being useless trivia contests doesn't erase that fact.
 You can imagine how hard hiring is for us right now...
OK, but this topic is not about "simple" whiteboard problems. (People can of course disagree wrt. what's 'simple', but a rule of thumb is that anything where the average dev would need to train and memorize whiteboard trivia for an extended period in order to perform satisfactorily is far from simple.)
I decided to not to do any whiteboard challenges unless the whiteboard has a built in editor, search engine and stack overflow. So far people who interviewed me just wanted to know about the different projects that I worked on during the last 15 years.
I'm lazy and don't have time to prepare for interviews or do home assignments because of family life. I'm going to be frank about this if I'm asked to do anything more than talking during an interview.
I was talking about minimizing risk for the people hiring at sub-FAANG companies. If they make crap hires, they can just say "well we're doing it exactly like FAANG". But yes, I also agree there might be better ways to optimize for minimizing bad hires.
Despite it being a turn of the decade 1980/1990 Microsoft thing.
Meanwhile asking questions that are grounded in the actual work you're going to have the candidate do, often gets you people making the estimation even if they haven't heard of Fermi Estimation, ever.
That's what makes them riddles, to me, and mostly useless BS in actual interview.
When someone says they hate "logic problems", it sounds as though they're talking about this:
I don't like those either, but I doubt they are used in interviews.
Many common examples of interview riddles that are defended as "it's just Fermi Estimation!" end up "memorise, interview, forget" method for many people, because there's close to total disconnect between assumed background knowledge and actual background knowledge (a question I encountered recently asked for estimate of revenue of an MLB stadium. If not for being spelled immediately after, my questioning would start with "wtf is MLB?").
Then there is the other part, namely that unless you don't know (memorise) certain common tropes of a Fermi quiz, you might understand the question as asking correct answer, not showing that you can use random number for most of the input data.
That said, I have been asked things that are fermi estimation problems on interviews that didn't suck and didn't feel like pointless riddles of Mensa wanna-bees. They tended to be based on the work problems, thus allowing to have a real and concrete expectation that the interviewee shares the background knowledge (in fact, part of the reason for the question might be checking if they do share that knowledge!). That kind rarely gets the flak of "how many piano tuners in city of Chicago".
The fact that not everyone knows the same things is the whole point! And if you don't have any knowledge that is related to the interviewer's, then how are they going to evaluate you using any method?
But sure, there are specific, inflexible requirements. You have to know false precision is BS, and I have no sympathy for people who have a problem with that. You have to in general, know what you know and what you don't.
OTOH, especially if you're interviewing internationally, using "common knowledge" instead of job/technology area related one? Pretty much a fail, helped along with books dedicated to memorising bullshit questions.
Another issue is that the typical "fermi problem" is stated in absolute, precision way. Ask "how would you estimate X" and you'd probably get good answers even from people who don't memorize interview gotchas.
But I suspect the reason people widely hate the concept is because schooling pounds into you that there is only one way to get the right answer, and it must be exact.
And so when people complain about being tested on trivia, what they really mean is "I want to be tested on trivia that I know". I would actually like to be evaluated based on something other than knowing trivia, but of course I would not like to take a stupidly constructed test.