[sjc33]

Honestly having an interview process that is highly standardized and teachable + learnable is a good thing, so I'm not sure why people complain. You know exactly what sort of questions you will be asked from company to company, and can spend nights and weekends over a couple weeks studying for it.

Most jobs are not like that, and then you get extreme variance in expectation with little communication on how to prepare, which is a waste of time for both the interviewer and interviewee if the interviewee has no clue what will be asked or expected ahead of time.

[monoideism]

The problem is twofold:

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.

[christiansakai]

Where did you get all of your numbers? My experience dictate otherwise. Plenty of people who don’t know DS&A and are bad coders, and call themselves senior.

[cryptozeus]

Is it really true though? FAANG seem to be doing just fine and innovating new products year after year. Obviously the developers are performing amazingly.

[monoideism]

"If you're a FAANG company, you can afford to play these odds"

[NoOneNew]

Except programming and engineering is about overcoming the unexpected. Adapt and improvise. Not everything is textbook and, at least this is my opinion, the better engineer is the one that can solve unexpected problems. You can really only judge that utilizing past experience. Canned, standardized questions similar to Mensa intelligence questions or any type of "brain-twister" puzzle are pretty crappy. Once you know the tricks they're applying to the question, they're easy to solve. But that's not the same as actually "figuring out" a real world problem.

[sjc33]

Ok, but why is that a bad thing for engineers that are interviewing?

If the interview process is largely memorizing 200 or so commonly asked algorithm questions and that is the gateway to a $200k+ job then it's a good thing for applicants, not "dystopian" at all.

Again, it would be much, much more painful and time consuming for the interviewee if they were asked to code up some fullstack project for every interview. That is far more time consuming, and in my opinion more "dystopian" to expect those interviewing to do dozens of hours of work specific to one interview for free.

[NoOneNew]

I think you missed the entire point of these articles. The algorithms you're forced to memorize are, 99% of the time, useless. Instead of hiring someone by their track record, managers are choosing to hire those capable of memorizing trivia.

Part 2, paying someone on trivia instead of capabilities is not sustainable. The company ends up suffering in the long term. Other engineers that are actually capable have to pick up the slack. Longer hours, less family time, higher burn out risk. Then comes the firing period because the company is losing revenue due to rampant incompetence. Putting even more pressure on the capable engineers. There's plenty of articles where trendy startups have some brutal layoffs, even though 12-18 months earlier had massive funding rounds and went into "extreme" hiring phases. The chickens come home to roost, no matter the sparkling bling of big paychecks.

[matz1]

I think you missed the point of this interview style. This style of interview is scalable, predictable, efficient and effective. It is useful in that way.

[Apocryphon]

It's scalable all right, but the other points- especially the latter two- are being debated in this thread.

[matz1]

Right, which misses the point of having this interview style in the first place.

[monoideism]

> the gateway to a $200k+ job then it's a good thing for applicants,

For most of us outside the Bay Area and NYC, it's quite unlikely that we'll secure a $200k/year job unless we go into management.

[Hydraulix989]

What a misconception. I know plenty of people in Seattle, Austin, Los Angeles, and even Pittsburgh, pulling in $200k/year in tech.

[monoideism]

According to the Bureau of Labor and Statistics, the median salary for software develors is $103,000. Top 10% earned $166,960 or higher. Take out the cities I mentioned and those numbers are even lower.

If you know plenty of people outside of the major tech big cities (and I should have included Austin and Seattle in that, for sure) making over $200,000 year, they you have a statistically unusual sample of friends.

All the data back up what I'm saying. Go look at the numbers. Look at salaries on monster.com or your favorite job site. Perhaps you and your friends don't realize how unusual it is (granted, you also have higher cost-of-living in those cities, sometimes by enough to eat up the additional salary).

[Hydraulix989]

Base salary is only one portion (usually less than half) of total compensation. Also, these engineers that I am referring to do not have the entry-level title -- they are often "senior software engineer" or "technical lead".

Maybe I should revise my claim to "top software engineers make over $200,000 in Austin, Pittsburgh, Seattle, etc.".

[perl4ever]

Interesting factoid for perspective - if you take the US and exclude every metro area at least as big as the Austin* MSA...you still have a majority of Americans.

*I think Austin is the smallest mentioned.

[NoOneNew]

Damn, you're right. I did the spreadsheet math quickly based on 2018 estimates on the top 314 cities by population in the USA. Apparently 100k minimum population is the marker of "city" according to this. Anyways, ~94m city dwellers compared to ~327m (2018) for the USA. "Big" cities are a minority.

At 284, Boulder, CO is considered a "city". Don't get me wrong, it's a nice town, but you can't compare it to Austin (11), Portland, OR (25) or NYC (1). Top 100 cities comes to ~64.5m (Spokane, WA coming in at 100 with 219k).

I just... wow... I don't know why, but I truly thought "city slicker" America made up like 50%+ of the population. At best it's 29%. Not insignificant. But... not a wide majority.

[hanswesterbeek]

One reason to complain is that these interview-questions usually bare so little relevance to the actual job.

[sjc33]

So what? It's a logic test. And you're still proving that you have enough experience to code well in general language e.g. java, python, javascript, ruby, etc.

It would be way more time intensive for the interviewee to be asked to code up some fullstack project for every interview.

Having to memorize some basic algorithm questions that are maybe 20 lines of code each is way better.

[bobwaycott]

> It would be way more time intensive for the interviewee to be asked to code up some fullstack project for every interview.

Assuming the role is a fullstack developer, memorizing basic algorithms doesn’t show one is fit for the purpose.

Providing a simple skeleton of a fullstack project—in the chosen tech stack of either the candidate or the company—and then verifying a candidate can add a simple feature, or something similarly fullstack, would accomplish that far faster than algorithm answers.

Edit: I realize this risks sounding like stupid take-home interview homework. I personally oppose that crap. However, I recognize why some companies take that route, as I don’t think I’d feel confident that a candidate could work in my company’s stack by asking silly algorithm questions. I’d probably feel more confident watching the candidate do a remote screen share, git clone a starter app, and do some simple to moderately complex fullstack tasks. Of course, the tasks should fit the role, I think—e.g., I wouldn’t ask a candidate who’s being hired to tune DB queries a bunch of fullstack questions. And if I was hiring a backend dev to build out APIs, I wouldn’t bother with a bunch of frontend tasks and questions. The hiring processes I’ve seen and managed always had better results when more time was invested in prepping specific, job-focused interview processes, rather than offloading that time onto candidates because recruiting teams can’t actually do more than ask shallow questions or follow checklists.

[matz1]

>Honestly having an interview process that is highly standardized and teachable + learnable is a good thing

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.

[vsareto]

The closest to a standard (and only for FAANG) is Cracking the Coding Interview, but even that is a large pool of questions to keep in one's head far above what you're likely to do on the job.

[sjc33]

It's pretty standardized. 99% of the questions you could possibly be asked are on leetcode for most large companies.

[andrewflnr]

The article to which this is a follow-up answered your questions fairly comprehensively. Among other concerns: no, it's actually not that easy to predict what questions you'll get.

[matz1]

Doesn't leetcode pretty much cover most of the question?

[Apocryphon]

There are thousands of questions on Leetcode.

[matz1]

Yes, which is not impossible to tackle. There is structured and systematic way to attack it. Tons of study guide and materials on the net to help you. Not to mention tons of people successfully get hired.

[Apocryphon]

As mentioned elsewhere, this is discriminatory against people with families and and commitments that prevent them from spending hundreds of hours in prep. Not to mention it affirms Goodhart’s Law, where a single metric- the ability to answer DS&A questions- overrules qualified applicants from becoming hired.

Not to mention such interview styles can be gamed. Suppose a Flatiron bootcamp for DS&A questions becomes big in response. What then? An arms race for more and more difficult weeder questions?

Such questions aren’t necessarily bad, but focusing on them to the exclusion of all other skills is becoming an anti-pattern.

[vsareto]

I think a decent amount would trade "no technical interviews" for credential hiring (degree required for job). The degree would be a well-known, long-standing target vs. the vague moving target of technical interview competence.

This isn't unlike other professions, but you would lose self-taught developers who don't have the time/money to afford the credential. That is currently something special about development compared to many other professions.

This assuming you prevent people who can't do something like fizzbuzz from graduating with a CS degree.

[matz1]

> this is discriminatory against people with families and and commitments that prevent them from spending hundreds of hours in prep

Maybe but its not the purpose to select people with families or commitment. You choose to have families or commitment, you have to deal with the trade off.

>An arms race for more and more difficult weeder questions?

Its always be an arm race. Why to expect otherwise ?