Every few weeks, someone posts an article about how broken tech interviews are, and the articles always follow the same formula: but I’m really good at REAL engineering… it’s the INTERVIEWS that are wrong!

It sounds like the author may have faced a bad interviewer, but I’d be curious to see their feedback on the author so we get both sides.

As I comment each time: you’re not being asked to sort a million item array because it represents the job, you’re being asked to sort a million item array because I want to see how you think, how you solve problems, and how good your underlying CS fundamentals are.

Yes - that means regardless of seniority, I expect you to know CAP theorem. Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem.

The job will change from project to project, but the CS skills should carry through.

▲

sharts 3 hours ago | parent | next [-]

The problem is you want a proxy for that which you really can’t evaluate and you think the proxy is accurate because it provides some feel-good binary.

Fundamentally, you can’t really figure out the things you are interested that way. This is the underlying problem with tech and CS bros which results in the broken system being even more broken.

If anything these types of interviews are really only to validate the interviewers bias which is that they think they are smarter than everyone else and anyone else that came before them. Otherwise why would they have been entrusted to being the gatekeeper of shiny job and privilege to work along the interviewer.

One may as well just defer to SAT scores, GPA, or the fact that a person actually graduated from a reputable CS program, or dare we say, the fact that a person actually had the same or similar jobs successfully over many years.

The reason people bomb these are precisely because they don’t need to exercise that “deep knowledge” that often in the first place. It doesn’t mean they aren’t capable it just means they’ll need to walk thru it longer than possible in a contrived situation. And the fact that they haven’t needed it is telling —these jobs aren’t really hitting the edge of CS research; it’s just a CRUD app.

The autists need to get off their high ponies and look at every other professional industry out there. Those industries have smart people too. Somehow humanity survives and the industry evolves…go figure.

▲

Esophagus4 3 hours ago | parent [-]

> you think the proxy is accurate because it provides some feel-good binary.

Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities. If you prefer, there are absolutely companies that don’t use the process, and they’ll hire you after a quick resume conversation. Frankly, I wouldn’t want to work there, having seen the abysmally bad talent hired through lax processes, but Godspeed if that’s where you want to work.

> the fact that a person actually had the same or similar jobs successfully over many years.

No matter how good you think you are, if you can’t pass a basic live coding exercise, you have no place on my team.

…You’re not being asked to invert a binary tree in 20 minutes with your eyes closed, you’re being asked to traverse a string and use a set. Stop whining.

	▲	johnsmith1840 an hour ago \| parent \| next [-]
		I think in reality though what you're doing is asking people to grind out puzzles until they're good. It's kinda like saying high math scores equal financial sucess. It is true in general but you're basically proxying hard workers not that the basics you test for are right. Getting an A in calculus doesn't mean that calculus helped you be a top engineer I bet most engineers would fail their old tests. The leetcode interviews to me basically signal: 1. This person is of minimal intelligence required 2. They work hard The real problem I have is that this system requires an endless calculus test requirement. Most proffessions have one big test to get in then you're basically done. Refreshers are given but once you pass that initial bar no doctor is required to pass their entire medical exam for every interview. Why not just have a certificate and be done?
	▲	EliRivers an hour ago \| parent \| prev [-]
		"Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities." Genuine question; how do you know? Presumably you have some good feedback on the accuracy of your process when you hired the candidate, but do you have any measure of how accurate your process was on the ones you turned down? I'm sure some of the ones you turned down would have been bad hires, but some would have been good hires; is there a measure of that?

▲

Herring 5 hours ago | parent | prev | next [-]

The interviews are wrong. Check with your favorite frontier LLM. There has been a lot of research on what's predictive for job performance and what's not, but it's largely ignored.

An easy example: Google's "Project Aristotle" - https://psychsafety.com/googles-project-aristotle/

tl;dr: psychological safety was the determining factor of highly effective teams. Then Google goes and does large-scale layoffs. Think about your workplace, do you feel safe? Do you think these interviews help people feel safe?

▲

Esophagus4 3 hours ago | parent [-]

Great idea.

So we’ll do both: have a high bar for technical interviews and a culture of psychological safety. That should be the best of all worlds and create a high performing team.

I’m not sure your point here. Yes, high performing teams have psychological safety.

	▲	Herring 24 minutes ago \| parent [-]
		Ironically, that's my point right there. Zero real thought, zero follow-through. There's plenty of research but nope, it's all vibes no data.

▲

siva7 6 hours ago | parent | prev | next [-]

> Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem.

Eh, no it doesn't? I guess it's one of those questions - what makes a good software engineer - that people will never universally agree on like many other topics in the field but still think their own truth is universal.

	▲	Esophagus4 3 hours ago \| parent [-]
		Those that don’t know CS fundamentals end up making bad technology decisions. I can’t tell you the number of times I’ve failed a “senior” level engineer because when I asked, “Tell me why you chose X database on Y project,” the only thing they could come up with was, “Well, we were storing JSON data, so we used Mongo.” I don’t want to be left cleaning up the mess that guy makes.

▲

wakawaka28 15 hours ago | parent | prev [-]

>Yes - that means regardless of seniority, I expect you to know CAP theorem. Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem.

There are lots of good engineers who don't encounter this, but who will understand the CAP theorem to the same level you and most other people you consider "good engineers" do, after simply reading the top of the Wikipedia article about it. Ultimately you need to be the kind of person who can understand such a thing to be a good engineer, not someone who knows any particular random thing. On the other hand I would like to know that the candidate knows the CAP theorem if we are working on a distributed database or massive web service. In that case it is actually relevant.

>Every few weeks, someone posts an article about how broken tech interviews are, and the articles always follow the same formula: but I’m really good at REAL engineering… it’s the INTERVIEWS that are wrong!

Interviewing is mostly a different skillset from day to day work. That is why everyone complains about it. Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview), is hella frustrating. If you urgently need a job, it is even worse.

▲

hinkley 14 hours ago | parent | next [-]

The number of times I've worked at places where the competent people likely could not pass their own interview questions if they hadn't thought of them themselves is too goddamned high.

I'm getting tired of having to coach other senior devs on how to interview like they mean it instead of like it's a drinking game.

Google has come right out and said that none of their interview strategies have made a statistically significant difference in employee outcomes.

▲

Esophagus4 14 hours ago | parent | prev [-]

> Interviewing is mostly a different skillset from day to day work.

It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.

There are plenty of places that have lower bars for hiring if you can call a JSON API in Python and run some Linux commands - but for the places everyone wants to work, you should expect a high bar. And that’s a good thing! A players want to work with A players. I would not want to work at a place that has a low technical bar for hiring.

> Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview)

It goes without saying that interviewer successfully passed that interview process to get hired there. So they have demonstrated at some point that they can do the problems they’re asking you to do.

Blowing a technical interview sucks, I get it - I have blown dozens of them. It’s humiliating, I’m aware, and so people find all sorts of copes (I would’ve been better than my interviewer at the actual job if I had just been given a chance! They couldn’t solve that problem anyway!) but they don’t want people that can just do the job - they want really talented engineers that can grow with the company and build all sorts of things.

Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.)

And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.

	▲	barchar 5 hours ago \| parent \| next [-]
		> It goes without saying that interviewer successfully passed that interview process to get hired there It does not. Also, even at the places with the most consistent interviews difficulty is pretty all over the place (or questions are well-known). Anyway, for me the answer to my interviewing woes was a propranolol prescription
	▲	wakawaka28 4 hours ago \| parent \| prev [-]
		>It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills. I don't write websites at all. I have had to deal with performance issues but frankly it is rarely a major concern for anyone. Furthermore, interviews don't resemble work, they resemble LeetCode or other competitions. >Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.) Having a degree and a long employment history implies that you are a good engineer more strongly than your performance on a random puzzle question. Most interviewers are not that good. >And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one. Yes, these companies want a process that provides superior vetting compared to 4 or more years of intensive schooling, or else something so far out that it can distinguish among expert candidates (while taking no more than an hour). It's a stupid objective. Coding interviews should mainly determine if you lied on your resume or not. It should not be seen as a magic way to spot "good engineers." If you want to filter out bad engineers, just ask them questions that you expect bad engineers to do badly. These are mostly design questions and not coding questions.