wrote about tech interviewing and how it's broken as hell:

https://basementcommunity.bearblog.dev/tech-interviewing-stinks/

i do a lot of interviewing in tech, and have asked some of the questions you justifiably complain about.

of course, i think my company's questions aren't too pernicious, and a big part of our interviewer training is about making people feel as comfy as possible and not being dicks who are like "ooh you don't know the specific word i want you to say, no job for you!", because that's definitely 100% a real thing and it sucks

the only thing i want to push back on a little bit is the big-O notation thing. i don't at all think it's important that you can use the right math to talk about your code's runtime complexity, but i do think it's really important to have a notion of complexity. (when i talk about it, i normally say "runtime complexity" or "what if the input was a million long—would we run into any issues?", not "what's the big-O of the function you wrote"). so, like, your complaint is deeply valid as written, because that's a weird way to ask about it, but... i've seen a lot of database access code, e.g., that's n^2, which works completely fine in dev when n=10 and falls apart in prod where n=10_000. or doesn't fall apart, but makes the experience magnificently shitty.

i don't even really care if the answer is right, as long as the person i'm talking to can talk about complexity cogently. if i'm interviewing for an entry-level position, i don't even really care about that, we can teach it, it's not that hard. but if we're hiring for a more senior role, it'd be really weird if i commented "hey, this access pattern is gonna be really slow in prod, and i'm pretty sure there's a linear-complexity algo for this kind of search—wanna pair?" on a code review for a senior dev and got back "slow in prod? nah, it only takes 10ms to return on my box, and the code's really straightforward so i'm not sure what you mean by complexity".

I think it depends on the coding questions being asked. I actually do believe software engineers should be able to understand most easy/medium leetcode style questions (hard leetcode, not so much) but a lot of companies, especially FAANG, have emphasized them too much to the point that there is an entire sector of the economy developed around passing these interviews like there is with standardized tests like ACT/SAT/etc. It is also not good for the companies since you end up only selecting candidates who are good at these interviews. Anecdotally I have noticed junior engineers being increasingly difficult to work with since many of them are leetcode drones who have issues working and figuring things out on their own. They got really good at passing 'the test' but did not develop many other skills relating to technology and many times do not really have an outside interest in it beyond being able to get a job.

Oh no how dare they ask software engineers software engineering-related questions!

Imagine hiring a surgeon and he gets offended if you ask him where kidneys are

go away please 🙏

i will totally admit this post had a front-end bias in mind, and i get it doesn't really translate to other disciplines, but yeah i agree as any developer you should have a grasp on how performant your code is and whether or not it will do well under a lot of pressure. don't get me wrong - i learned this very well when working on a betting app with lots of volatile data that was way more massive in production than locally.

but yeah, just being asked "what is the the O complexity" just feels like unnecessary and i feel like you could frame the question in a much more approachable way if you're just trying to have a genuine discussion about the performance implications of the candidate's code

I wholly agree with this because I've been on interviews for .NET/SQL Server positions where my day-to-day would be maintaining a godawful CRUD app with an ASP.NET front-end, and the interviewer is asking me how I'd implement quicksort or bubblesort.

Why would I implement these algorithms when modern C# has LINQ-to-objects and I can sort any set of objects that implements IEnumerable or IQueryable by using .OrderBy() and .ThenBy()? Hell, why would I bother with LINQ in the first place? If I had any sense I'd be hitting the database by stored procedures and the procs would sort data using SQL order by clauses.

I used to think such questions were either purely irrational or an exercise in cargo-culting (i.e. a company that isn't Google interviewing candidates as if it were Google) but I've either gotten more cynical or more conspiratorial with age. I've suspect that these sort of gotcha questions are also intended to filter out anybody who isn't a recent computer science graduate and thus a proxy for discriminating social class (can afford to go to college and study CS) and age (recent college grad) that won't get the corporation crucified by the EEOC.

There are two sort of legit justifications for these kinds of interviews. One is that it has more false negatives than false positives, which is desirable when you are hiring. I don't know that that's true, but I can imagine that it may be. The other is that there is no good way of doing tech interviews but we have to do something. That's not strictly true, but might be true for the hour-long interview scale. I do know that the place that I've worked that had the highest quality engineers had an interview process that involved multiple algorithm and coding questions and had a "when there is any doubt, no" deciding policy. The people who made it through though were usually very smart (excepting myself...I think I just got lucky). The failure mode was that sometimes you got the coder who literally only new leetcode style coding and wasn't actually productive. It wasn't that common though.

I think there's something to be said for the homework style interview, but the time investment for that is too high for both the interviewer and the candidate.

this was me in my last role. i got a job where i barely passed the technical interview, but when i finally took the job and spent more time with my coworkers who interviewed me, i started to realize they were all very smart, but really bad teammates personality-wise.

which i think is just another good reason to not take a job that puts you through the ringer like that. usually it speaks to the people's personalities who are employed there.

So I'm not gonna lie, it sounds like you don't like technical interviews, and have somehow extrapolated that every hard technical interview is someone trying to punk you lol. Nothing wrong with not liking interviewing, but I don't see why you need to take the process so personal.

Actually, for the most part the people I worked with weren't a problem. I actually ended up working with some great people, some really nice people, and even a few really nice great people. The management, on the other hand, had some issues. The good part was, we ended up doing some good work, which we could reasonably be proud of. The bad part was the management issues made it less rewarding than it should have been, both emotionally and financially.