Hacker News Reader

>are we just going with a base assumption that interviewers can NEVER be trusted with anti-bias training and learning how evaluate people fairly?

Yes. Because interviewing is

1. hard, but no company has proper full time proctors. So "expert interviewers" are a rarity

2. not standardized in the slightest. So your performance varies entirely by the interviewer, their style, and their mood that day.

3. some weird blind test where you hope you studied the right topics. You're not getting the best out of a candidate, you're basically hoping they read your mind and know exactly what you want them to say.

>Is the culture just so broken at these companies that it’s hopeless to expect people NOT to blatantly exploit the system for their friends? Why don’t people get fired for doing that?

Sure. but that's a universal problem. "It's who you know, not what you know" is advice that has spanned centuries. I can't even blame the modern tech industry for that one.

That + the above issues with interviewing mean you're always going to go with a referral over a random applicant.

1. I’ve worked at multiple companies that absolutely have expert interviewers who design the interview questions and then teach mid-level engineers how to proctor them correctly. It’s like one 30 minute meeting, it’s not that big a deal.

2. All tech companies I’ve worked at since around 2015 have completely standardized interview questions, sometimes also hosted in a GitHub repo where any employee is free to comment or even open a PR to request a change. Every candidate gets the same questions. This thing where “faang” interviewers just pull a random LC question out of their ass is complete insanity to me. An organized set of questions takes a senior engineer like a week to organize and commit to… And if your questions can be memorized and recited by rote memory and the candidate can do well on it without the proctor knowing, then your questions are BAD or your proctor is a moron.

3. I’ve never worked anywhere where I would describe the interview like this. Even the startup where I was the first engineer and there was no formal “test”, it was an hour long chat with the technical cofounder where he grilled me about coding skills and past experience/accomplishments. I won’t take a job if the interview isn’t asking me things that focus on my existing experience and skills, it’s a red flag about the company culture in general.

As for your “universal problem,” I disagree with fatalistic takes where you just throw your hands up and say “whatever shall we do” all the while YOU are the one benefitting from the system that cannot be changed. This is how simple-minded people think about the world.

1. I've 100% met with interviewers that felt like they were googling interview questions on the fly. YMMV which was the point of the "no standardization" argument. I've had interviews with no whiteboarding, some with whiteboarding, and some that simply felt like we both wasted our time.

2&3. I wish I could relate. I work in games, fwiw, so maybe it's simply more wild west than the other domains in such regardss. It's not even that I can't answer some of the questions, but if I'm asked a question on CPU architecture after I spent my time studying a bunch of C/++ trivia, I'm not going to answer the former as confidently since I'm pulling out knoweldge from a 3 year memory bank that I happened to work with at work.

>all the while YOU are the one benefitting from the system that cannot be changed.

I am? I'm a year out of a job and I sure wish I had a referral. My last studio shut down so those references scattered all over.

But for "whatever shall we do"... I don't have some magic perfect interview, but a few basic steps to save everyone's time:

1. we don't need 5-10+ rounds of interviews and 3 months just to make sure a candidate isn't a lemon. IMO if it's over 3 rounds (not including an HR call for basic alignment), there's some process that really isn't necessary. You dont need to speak to a CEO unless you're applying as a director or executive yourself. You don't need to meet every team member separately for their variation of an interview

2. Ghost jobs absolutely need to be regulated. I'm surprised it's even legal to lie to your shareholders and say "we're always growing" when half your postings have little intention of attracting a candidate. At the very least a job posting should delineate between urgent (hired withing 1-2 weeks of response), "normal" (2-4 week process), and "cold" (6+ week process, non-necessary role).

3. jobs should in fact give a general direction of what kinds of technical questions you expect to be asked for that portion. Who does it really benefit if one candidate happened to study leetcode (and the right kind of leetcode), but the other was focusing on system design, or questions about their specific industry problems solved? Or domain specific probblems?

Just a few ways to be honest, efficient, and bring out the best in candidates. Interviews shouldn't be so hostile to the labor the company clearly requires.

> if your questions can be memorized and recited by rote memory and the candidate can do well on it without the proctor knowing, then your questions are BAD or your proctor is a moron.

I agree in spirit. My only caveat sympathizing with interviewers is that most questions can indeed be "memorized", and arguably all questions/practices can be studied for. And there is some merit to trying to figure out how someone approaches a new problem. I think that approach is highly inefficient when you do in fact mostly want someone who "already memorized" the right domain knowledge, but I digress.

But people and their experiences are diverse. Without knowing their background (and again, some people seem to read the resume for the first time during the interview) you are never going to surprise 100% of your candidates with the same question bank. But that may be too much of a burden on trying to cater every inerview for every promising candidaet.

> 2. not standardized in the slightest. So your performance varies entirely by the interviewer, their style, and their mood that day.

That isn't always true. When I interview HR gives me the exact questions I'm allowed to ask. These are vetted both to prevent me from asking something illegal, and also by research to get the type of things useful for interviews. Sometimes it is annoying - you can easially finish the interview with a great score but I have no clue if you can write code or not. However we are carefully trained on how to ask the questions and how to grade them.

That makes sense for soft questions. But I doubt it's HR devevloping a dynamic programming problem and writing a rubric for how good a score you can give based on a response.

I was mostly referring to technical tests, but I understand there are definitely some set of questions you need to ask no matter what. I don't really knock recruiters too much for repeating the usual "are you authorized to work in the US" kinda stuff even though it is the first question on their job application.

> Is the culture just so broken at these companies that it’s hopeless to expect people NOT to blatantly exploit the system for their friends? Why don’t people get fired for doing that?

How do you catch them? Unless they’re idiots they’ll write facially plausible explanations of their hire/no-hire decisions.

> Forcing people to study for two months is blatantly discriminatory to age and family status, at a systemic level.

How is this any less discriminatory than any other assessment based interview where you need to prepare? Non-assessment based interviews end up being vibes based which is much more discriminatory.

You’ve set up a false dichotomy here; for any given position, there is typically a way to conduct an assessment-based interview that doesn’t require too much preparation for qualified candidates.

For example, at my current job, we hire web developers with Rails experience. Our technical interview process consists of either a pair programming session or an async/take-home task (candidate’s choice) which requires the candidate to implement a small feature in a Rails codebase. We do have some room to improve on objective evaluation of the candidate’s performance, but there is a test suite and a rubric which we use to evaluate their work. None of this should require that the candidate study, unless they’re coming in to the interview without Rails experience.

This may work out great if you happen to have worked on Rails for your last job. However, I doubt that everyone you interview is actually that familiar with Rails but rather is pursuing any sort of opportunity that they can get. In that case, they would actually more time to brush up multiple different tech stacks than simply on algorithms.

In that case, the interview question is working as intended. For most of our roles, we want several years of Rails experience, and we are clear about that fact in the job listing. If someone applies without Rails experience, they either didn't read the job listing, or are desperate to find any job. While I empathize with folks in the latter situation, our positions really do require the experience, and the job market isn't so bad right now that a smart candidate should be going a long time without finding something.

If you happen to have Rails experience but it was several jobs ago, the task we give you is basic enough that you should be able to Google what you need during the task to refresh your memory fairly quickly. In fact, I did this when I applied, having not worked with Rails in a number of years.

Edit: My main point is, even if you technically do have to "study" (really, just Google a few basic Rails concepts) if you're rusty, everything you do is preparing you for the actual job. Studying how to implement a hashmap, or computing the longest palindrome from a string of characters, or whatever other harebrained problem FAANG etc want to ask, is 99% of the time not really helping you prepare for those jobs.

This leaves those who don’t wish to limit their candidate pool by previous stack experience with no option.

No, it doesn’t. I was just giving an example from personal experience.

For any given job, I believe there’s a way to design an assessment that allows the candidate to demonstrate skills directly relevant to the job, even if the job doesn’t have requirements that are as specific as “Rails developer with a few years of experience.” I have yet to see a single job listing in several decades in the industry where I think to myself “ah yes, the only way to find qualified candidates for the job would be to ask them to implement a quadtree.”

I've done a lot of whiteboarding interviews in my life and it's never been "implement a quadtree." It's always, at its core, a small coding probably that could plausibly be part of a real-world problem, and therefore it is directly relevant to the job.

I've also never been asked a question like this, but it's because I specifically avoid the companies that are known to ask them. Sounds like you have as well (knowingly or not). But the OP is about LeetCode-style interviews, so that's what I was discussing.

No, I've been applying to companies all-in on the "leetcode" style of testing and I think you are misconstruing it.

Are you claiming that no company asks irrelevant leetcode-style questions as part of its interview process? If so, that’ll require some more evidence than “well, I haven’t been asked any such questions.”

I'm rejecting your characterization of "leetcode-style" questions as 1) irrelevant 2) primarily about simply implementing some obscure data structure (as opposed to correctly using data structures).

I'm sorry if I wasn't clear; I didn't mean to say that all LC questions are irrelevant. I was just asking if you're claiming that no company uses LC questions which are irrelevant. Because if you are, that seems like a pretty difficult claim to prove given all the stories out there on every company review/discussion site like Blind or Glassdoor.

And my "implement a quadtree" example was hyperbole; again I'm sorry if you didn't recognize it as such. I do suspect we have wildly different definitons of what questions qualify as "relevant to the position," though, so I'm not sure how far we're going to get in this discussion.

Because the interviewers themselves typically have wide latitude to select the actual question, no, I don't think such a thing can be claimed. But I'd say the majority of questions asked are reasonable ones that can plausibly be solved in the timeframe and the majority of interviewers I've observed from that side of the table have not expected perfection or wanted their candidates to fail.

I don't think I (nor most others commenting here) were claiming that the questions couldn't be solved in the timeframe, that interviewers expected perfection, or that they wanted candidates to fail. So I'm not really sure why you brought that up.

>any other assessment based interview where you need to prepare?

because most other assessment based interviews are based on what you do on the job, likely stuff you've done at previous jobs as well. Less prep time when you spent thousands of hours already as a career.