Follow-up to “The dystopian world of software engineering interviews”

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.

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.

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.

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.

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.

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 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.

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...

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.

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.

What do your counterparts at the company think the source of their hiring difficulties is? If not flawed process?

Needless to say that company had a lot of problems with technology. But they seemed to be good at making money strangely enough.

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.

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."

Is the amount of youth in tech part of the problem?

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.

¯\_(ツ)_/¯

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!

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.

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.

> 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

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 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.

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.)

(this is the Portfolio button URL in the nav bar)

It seems implausible. It's counter-intuitive. But the idea seems pretty persistent.

It's an interesting question for me personally. I'm a mechanical engineer who likes to program a little and I've sometimes wondered whether I could work as a programmer. I haven't got the right qualifications or experience with enough popular technologies, so moving fields would be tough. But I know I can implement basic things from scratch. It doesn't seem like much (and clearly it wouldn't be enough for the prestigious places with really tough computer science interviews) but it would be interesting to know if that actually was enough to clear a certain low bar of competence.

That cycle has been going on for years. Now, there are so many companies that are essentially writing variants on the same software over and over again that demand is dictating the shape of the field. The shape of the industry. “We” are all industrial designers in a world that just isn’t that enthused.

If we wanted this other world that we keep interviewing for, then it’s not a matter of not enough programmers, but way too many. They’re cheap enough that people everywhere are reinventing wheels instead of assembling off the shelf components designed for that purpose.

Luckily actually working in software development is a hell of a lot more like practicing than performing, and there's usually no-one watching you, so I'm fine at that part.

Speaking of the second chance, from the link you referenced https://news.ycombinator.com/item?id=11662380

In that comment you said

> I want to turn this system into something that's open to all users who want to take time to review stories. We'll make it a form of community service that will be a new way to earn karma. However, it's still an open question how to pull this off without simply recreating the current upvoting system under another guise.

Have you guys looked or thought about this any more since then? I'd love to see such a community service become reality.

It has all of it: creative jobs, theoretical jobs, and factory-like jobs. White collar and blue collar jobs at the same time.

What we suck at is admitting which jobs are which types and assigning the labor accordingly (as well as setting targets).

At most of my companies, we tried moving exclusively to take-home interview problems for this reason. Short problems that could be solved in 2-4 hours of time, as benchmarked against current employees during daytime hours.

Inevitably, some candidates hated this so vocally that they'd ghost us, or some times even take to social media to lambaste us for trying to take away from their free time. Or we had people refusing to do the toy problem (not real work, same test for all candidates) unless we paid them hundreds of dollars to compensate their time.

It didn't matter how much we tried to explain that the entire purpose of the take-home problem was to grant flexibility to the candidate. A large number of candidates vocally hated any interview technique that didn't involve company employees giving 1:1 interview time to them.

We just filtered those candidates out of the pipeline, but I walked away with a clear understanding that interview practices will never make everyone happy.

I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.

I've had recruiters talk to me at length about each of the people I'd be meeting in the on-site, their backgrounds, what they'd be covering. I've had ones give me broad strokes about why previous candidates were passed on. At the end of the day, it's not in their interest to bring too many people to an on-site who will fail spectacularly, because that means they're not doing their job properly.

I may just be lucky.

Turned out he did 500 interviews a year. Five hundred. Unless that's your entire job, I don't see how you could come out of that without becoming an asshole.

Yes I agree but the current way we have is not even close to that.

He touch that issue in the article. So you spend a lot of time and effort to learn about binary tree, great, you pass with flying colors with company A, then you interview with company B, they ask you trie tree ...fuck.

1. False positives: you get folks who do really well at DS&A yet who are really bad developers. I mean really bad. I wouldn't have believed it if I had not seen their interviews and then subsequent performance. I'd wildly guess that it's about 20-30%.

2. False negatives: you get folks who are really good developers, and yet for whatever reason, perform badly on DS&A algorithms despite practicing. I think this number is higher than false positives, probably around 50% or more.

If you're a FAANG company, you can afford to play these odds. If you're not FAANG, then you're killing yourself by requiring DS&A interviews, almost inevitably.

Both are contributing to destroying the profession for huge numbers of people, IMHO. I mean, that's good for me, because I'm almost certainly sticking around and generally do OK on DS&A interviews with adequate practice (which is a waste of time, since anything beyond a broad knowledge of the performance characteristics of various DS&As is totally unneeded for 99% of us). But it's not right, and I really don't like it.

Strange postscript that suggests you hold some problematic opinions that indicate you can't play nicely with others?

Did you fail to get the job because you didn't have the tech chops or is it because you said something wildly inappropriate on the behavioural questions?

What did you say?

I left Google in 2009, quite unhappy about the difference between a startup and corporate politics. After that I worked at 3 startups (5 years), 1 telco (1 year) and at McKinsey (3 years).

I ended up interviewing at Google again in 2018, after deciding that a) I liked programming more than management consulting and b) my comparative advantage was in programming. I definitely could have felt entitled after 1) passing Google interviews once before, 2) having had three somewhat successful startups and 3) proving I can also handle the corporate side.

I was asked multiple questions that could be interpreted as 'algorithmic' (and I have to admit that after 3 years of not coding I was nervous about them). However, they can also be interpreted differently, more charitably. They all followed the structure of: 1) give a reasonable but not completely defined problem - you should be able to clarify enough of this to show you can deal with some ambiguity; 2) turn that into an algorithm - you should be able to articulate an easy algorithm and be able to discuss improvements to it; 3) turn your algorithm into code - you need to show you can actually program. I definitely didn't have to memorize and regurgitate textbook solutions.

I acknowledge that a) the above may optimize for rejecting all negatives at the cost of some false positives and b) it's still a very basic lower bar and doesn't predict who will perform highly vs. ok. However, I did think it tested for the core skills I expect from programmers.

I've also set up interviewing processes at startups. I did end up emphasizing ownership and 'getting things done' more than Google does. I do think startups should test for different attributes than 100k+ FTE corporations.

Yeah. In a world where Google exists (or even where Knuth exists), what's the value in having algorithms memorized? Knowing the characteristics, sure. I agree that that's important. But the algorithms themselves? Why? I've got better things to do with the memory space.

Yea, if I had also been working on this particular code for the past two years I'd be able to breeze through these problems too.

One person's "ladder pulling" is another person's "raising the bar".

Over time, companies should continue to raise the bar for both candidates and existing employees. As your company grows, you can and should become better at attracting more talented and ambitious employees. You tend to have more resources to compensate new hires better, allowing for more selective hiring practices. Growth means you've learned how to more effectively identify the best candidates.

Companies aren't being vindictive or selfish. If they can't hire enough people, they'll dwindle and die. The bar should be set just low enough to keep enough talent coming in the door, but no lower.

Companies aren't obligated to hire talent at the same levels they did in the past. It's not ladder pulling, it's just business.

I agree that this was a cheap shot from the author.

The current zeitgeist of hiring practices is that we're all obligated to chant "interviews are broken" without ever suggesting alternatives. Suggesting alternatives is dangerous because someone, somewhere will come up with a reason why your suggested practice is bad. Even the author of the article avoids suggesting any alternatives.

It's the equivalent of politicians saying that they're "deeply troubled" by something, and then proceeding to do nothing because they are secretly okay with the status quo.

No one is dumb enough to go out of their way to publicly argue in favor of the current hiring practices in this atmosphere. Yet when we're put in the hot seat on a hiring committee, we all fall back on the tried and true methods of interviewing for a reason.

No doctor is expected to share money with his teachers nor is expected to teach sons of his teachers. Abortion is allowed and lately euthanasia too. Current doctors can perform operations and are not required to treat all sick people.

I expect, though, that the issue is that the degree of correlation measured will depend on the population you're screening with it. If you are wanting to screen out fraudulent or otherwise utterly non-programmer persons, it will show a good correlation. However, among those who are actually programmers, it will show much less correlation, and if you're in a condition of developer scarcity, the false negatives could be more costly than the false positives.

I can only claim to have personal anecdotes, but the critiques I hear and have are things like asking you to write Bash on a whiteboard an focusing on minor syntax errors (Bash was not the primary language for the job and the candidate was obviously familiar with the language). Or asking about details from compiled languages when the job exclusively dealt an interpreted language. I'm not saying these interviews shouldn't touch on these topics. I do like to see how deep a candidates knowledge goes (sometimes it can mean they're over qualified and would be bored).

I'm not sure if it's interviewers showing off, because they've "always done it this way," or what, but I often see both job posting criteria and interviews focus too much on things well beyond what the job requires.

Of course, I'm biased and think my way is better. Outside of the minimum requirements for the job I never really care if a candidate has an answer to most questions. In fact, when they get it too quickly it seems rehearsed and I don't think it reflects their skill. For me, the technical questions are a starting point to see them talk through how they approach the problem.

> Four meticulously orchestrated Google interviews could identify successful hires with 86 percent confidence, and nobody at the company—no matter how long they had been at the company or how many candidates they had interviewed—could do any better than the aggregated wisdom of four interviewers.

https://www.theatlantic.com/business/archive/2016/04/the-sci...

All of this is well orchestrated by large tech companies in an effort to drive down labor costs. The problem is, there's an assumption that the current labor market is just asking too much.

I think looking at the current labor market landscape, practices in place industry wide (e.g., agile, interview processes, etc.) were starting to see labor market feedback that this simply isn't the case. Development is hard, it's time consuming, expensive, and requires a lot of active practice--no matter how much you want to drive labor costs down.

Ultimately I hope the entire strategy backfires and we turn away talent industry wide to other sectors and then there truly are shortages resulting in businesses pushing these practices unable of maintaining their businesses and forcing them to scale back--wishful thinking though.

Perhaps you should stop flocking to one location in the states and go somewhere else?

If there was, hiring and compensation practices would reflect it like in any other field.

I don’t think the FAANG-style coding puzzles have anything new to add to the conversation here. The reason big companies do that is because the questions are prompts are simple to write explain (hence interviewer has to do very very little), the answer space is generally well-defined (so it’s easy to grade, and easy for a Hiring Manager to check if the interviewer screws up), and they almost exclusively select for completion time (which is key in a high-pressure feature house company).

Most of the discussion here seems to be interested in alternatives. Through my experience, I can’t agree enough with the article author who posts:

Not a single person out of several thousand emails and messages came out in defense of the current state of interviewing processes - I’ll let this one stand on its own.

The only people I’ve seen to defend the current process in public are ex-FAANG people who were actively monetizing their experience (e.g. Gayle Laakmann).

Appreciate it. For some background it would be nice if you clarify the perspective of your role as one of HR/coordination or a more technical view on participants of these interviews.

Do you feel like current FAANG hiring practices for lower level roles incubate a generation of programmers that trains specifically for the interview process moreso than they do for the actual role you want to fill (and if so, do you feel like that is benefitial to your employer / simply a necessity at their scale / worth changing)?

edit: That makes sense, thanks!

The top comment is brilliant and sums up the brokenness in the best way I've ever seen.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and posting more in the intended spirit of the site, we'd be grateful. Note this one: "Assume good faith." That's not because people do always act in good faith (of course that's not so), it's because the assumption of bad faith leads to crappy HN threads and the assumption of good faith leads to better ones.

We detached this comment from https://news.ycombinator.com/item?id=22393019.