I will f(l)ail at your tech interviews, here's why you should care

<i>If the point isn’t to finish the task and you just want to assess their problem solving, wouldn’t you still naturally rate the person that breezes through it over the person that has to clunk through it solving it? This means this will be biased towards someone who HAPPENS to have dealt with this same problem (or memorized it).</i><p>After a few leetcode interviews this is now my technique. I just braindump style memorise problem &#x2F; solutions from neetcode.io videos without attempting to solve them outright. Sure it might be enlightening to grind through the problem solving aspect, which I&#x27;ve tried before, but you&#x27;re probably going to miss the mark trying to find the optimal solution, and memorisation is far more effective in practice, especially when faced with a unhelpful interviewer.<p>I&#x27;ve been told that this is a mark of a &quot;bad&quot; software engineer (even here on HN) for taking these shortcuts. While yes being a decent software engineer matters, I just don&#x27;t see how these hazing ritual style interviews have a bearing on you as a developer. Memorising leetcode to pass interviews is just an application of opportunity cost.

I was way more likely to succeed the faang tech interviews coming straight out of university than I do now after working for 10 years.<p>But I do think I&#x27;m a way better software engineer now than back then. So something is broken with that interview process.

The issue is we don’t actually recognize that there are two very different careers that fall under the “software” umbrella.<p>One is developing hard software, software that needs to be performant on a hardware level. Like operating systems, low level libraries, embedded software, databases. The ability to quickly identify and apply data structures and algorithms leetcode style is very important in hard software.<p>The second is soft-software, which needs to be performant on the organizational budget&#x2F;timeline level. This type of software engineering is more about glueing together hard software in the right way to solve business problems. Leetcode style interviews make no sense here, because the glue is usually bash or Python and it isn’t really doing much besides orchestrating hard software and delegating work to it.

The argument seems to be that some people are worse at the standard questions in an interview setting than you&#x27;d expect because of outside factors (which I agree with) and that therefore we should use more STAR style questions. But I&#x27;m terrible at star style questions, my memory just doesn&#x27;t work that way. I also think that they are not terribly correlated with most aspects of job performance.<p>Just as there are people unfairly bad at coding questions in an interview situation I think there are also people unfairly bad at star questions in an interview scenario.

The more you try to decrease false positives, the more you get false negatives, this is something taught in any intermediate Statistics class. Different people may have different opinions on what rate of false positives is acceptable but only ignorant can claim that you can eliminate false negatives &quot;for free&quot;, without getting hit with more false positives.<p>The example given in my stats textbook was going on an expensive cruise and, as you ride to the port, you realized that you might have left an iron on (that was an old book, people used irons to make their clothes smooth). If you turn back then you miss your ship and take a loss on your whole cruise. But if you don&#x27;t and the iron is actually on then you lose your house. So, do you want to take the false negative (the iron is off and you lost few grand you paid for the cruise) or the false positive (the iron is on and lost few hundred grand you paid for the house but, as a consolation, you enjoyed a cruise)?<p>Apparently businesses do not suffer from their preference to false negatives and there are not many (or any) companies with an easy interview process, which are also attracting many applicants, so the avoidance of false positives does not seem irrational.

A good senior developer should be able to go out to lunch with a candidate and determine if they are a good fit. No need for coding tests. No need to sit in a small room and work out problems on a whiteboard or chat about your most difficult problem at your last job. Just get lunch. Any good developer can evaluate another developer after a few minutes of conversation, and you can tell if it&#x27;s a reasonable cultural fit. Just lunch. That&#x27;s all you need.

This year my employer started using Hacker Rank as a &quot;step in the interview process&quot;. During the first dozen or so of interviews, most candidates ended up running out of time and &quot;failing&quot;. Well it turns out, if you look at the data for that particular question from HR most candidates also failed. It was a terrible prompt with too much code to write. In our subsequent rounds, we told the recruiters to change those questions out, and regardless of someone passes let us review with them. We told our recruiting team if someone refuses to do let code&#x2F;HR, that&#x27;s okay if they have some code they&#x27;re willing to share and discuss instead.

You write that you can’t do an O(n) search in 30 mins? Bro that’s just a single for loop.

As someone who is good at technical interviews, I am really confused by the assertion that they are checking if you have memorized the solution. In my experience, the problems have been either A) easy and I’ve never seen them before, where the goal is genuinely to solve it on the spot (“write a function to validate what a sequence of moves is a legal tic-tac-toe game”), or B) impossible to solve on the spot but I have the answer memorized because I’ve solved the problem many times in the past as part of the experience listed on my resume (“Dump a valid PyTorch training script for a simple MLP from your memory without consulting documentation” “Here is an obscure CMAKE error, explain what discontinuation caused it”)<p>How common in practice are these questions like “find the median of a list of sorted lists” that are both too obscure to get memorized in the course of day to day work, yet common enough that you could, if you wanted to waste time, memorize the solutions to all of them?

Technical interviews are usually just made up, no science, no system, just a vague guess as to what to ask.

The intractable problem is there is a vast, opposed gulf between &quot;interviews that are measurable, that HR can use later as collateral against anti-discrimination lawsuits&quot; and &quot;interviews that are effective at hiring a person for a role&quot;.

We need solutions, an alternative<p>I actually haven’t seen algorithm questions a lot lately, so that’s progress, but even building something live can trip you up<p>Reality is that 45 minute speed trial would be given several days in sprint planning<p>We should simulate the sprint ceremonies and repository management more than code. Make their commits break because of a poorly documented linter they have to get around. That will fix their code along the way

My brother and I came up with an interview process for help desk positions many years ago. It was sort of an open-book exam. He set up a computer and a network printer. I believe he purposely misconfigured something with the networking of the network printer, possibly one other issue too.<p>They had 1 hour, utilizing any resource on the internet they wanted, to correctly configure the network printer. If they completed it, great, if not, he&#x27;d go through and see what their troubleshooting process was, what they researched, etc.<p>This type of interview worked really well for hiring help desk staff, but obviously hiring a software engineer and evaluating them is much more difficult.

Hiring in many companies ranges from suboptimal to fully broken but in the (macroeconomic) situation when each opening gets lots of candidates it is unlikely to change, unfortunately.

<i>I have some idea who I’m connecting&#x2F;interacting with and how they communicate. I have some knowledge of the problem space, how we got here, and why we are solving this. It is unlikely this is the first time hearing of this issue. I know the team and&#x2F;or technologies which will likely support the solution. I know the broader org goals and direction that might affect choices. I have safety to ideate, iterate, and draft solutions.</i><p>This is basically “hire me and you’ll see”. Well, the perspective of an employer is that 80% of candidates say so and only 20% of them are worth anywhere near their desired comp. I understand the sentiment, but learn to show yourself before the marriage even if that’s no use afterwards.