> ## Content Index > Fetch the complete content index at: https://not-your-language.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # Technical Interviews Suck For Everyone - URL: https://not-your-language.ghost.io/technical-interviews-suck-for-everyone/ - Published: 2026-09-21T17:27:08.000Z - Updated: 2026-09-21T17:27:08.000Z - Description: Why technical interviews don’t accomplish their stated goal, why I refuse to do typical live coding exercises, and some ideas on how we can improve. - Author: John Darrington - Tags: technical interviews, software engineering, hiring, jobs, Newsletter, #Migrated-1790028270694, #Import 2026-09-21 22:04 I have 15 years of experience and I just failed a simple bug-hunt technical interview. Typically when told about the technical exams I am very firm with what I do and do not do. I have ADHD, and along with that comes rejection sensitivity and anxiety. Live-coding exercises exacerbate these two to such a degree that I have yet to feel like I was successful in any live coding exercise. I tend to choke up and get so nervous that I’m consistently second-guessing myself and seemingly forget basic computer science concepts. I have 15 years of experience, I have various published papers, repositories, and conference talks. I have solid references and contacts from every position I’ve worked. So, why was I asked to complete a live coding exercise in the first place? Did they not review my public output? Did they not call my references? Watch any of my tech conference talks? I don’t know of any software engineer position that requires that you live-code your work in front of a studio audience who are allowed to only watch. At worst we might be under a serious time constraint to deliver code, but they’re not going to ask to share your screen to see if work is getting done. If this is the case for the majority of positions, **why are we using an interview technique that is miles away from what the job actually entails?** ## Building Trust In my opinion, the point of job interviews is an exercise in building trust. The candidate typically wants to find an employer that is pleasant to work for, has fair compensation, and allows for career progression and growth within their market. The interview offers the candidate a window into the company that can help answer these needs. The employer wants to find an employee who can perform the job to their satisfaction and is low-risk (there are a lot of things employers feel are risky, so many that we’ve had to create protections against discrimination etc.) An employer wants to ensure that the time they’ll spend training the employee will be worth the investment. Employers also want to have a high degree of confidence that the candidate can perform the job adequately. However, software engineering is a massive discipline and needed skills vary from writing code to critical thinking skills and pattern recognition. How do you break down such a large discipline that you can adequately judge someone’s skill level within an hour? **You can’t.** That’s it, that’s the thesis of the article. There is no way on God’s green earth that an hour long live interview can give you an adequate picture of someone’s ability as a software engineer. Even if someone “aces” the interview the most you can know is that they can solve Leetcode, bug-hunt, or simple coding exercises. This also completely disregards the non-neurotypical individuals like me, for whom live-coding is an absolute disaster due to circumstances generally beyond our control. What’s even more frustrating is that I’ve yet to meet a senior engineer who believes live-coding exercises to be that beneficial - yet they still participate and perpetuate the practice. I think this happens because in a typical interview process it is the only point at which anyone technical is brought in to review the candidate. Without any other tools available, or maybe just not able to take the time, there is no other way for the technical reviewer to build trust in the candidate. When only one out of x interviews (typically 3-4) is with a technical individual, I think they often feel like they have to play gatekeeper. Other times technical personnel get no say in the interview process and it’s entirely HR driven - and HR cannot understand software engineering as a discipline (at least not typically). Either way, the person giving the technical interview is oftentimes just as frustrated as the individual taking it. Given the option between no method for building trust in a candidate and a crappy one - we’re consistently picking the crappy one. We need to do better. ## How To Be Better #### #1 - You’ll Make Mistakes My first and biggest piece of advice is this: you’re going to make hiring mistakes. It is inevitable that you misjudge someone’s technical skill, cultural fit, or work ethic during the hiring process. No matter how skilled an interviewer or how revolutionary the process, you will make mistakes - both in favor to the candidate and against them. Don’t be so risk-averse that you create a gauntlet of programming challenges which only a select type of person can accomplish. #### #2 - Do The Legwork Candidates have often spent a large amount of time curating what they present to the company. They provide references, links, code examples, and other artifacts to help you judge their abilities. They’ve done a bunch of the work for you, and if you use none of it - or only quickly glance down the resume - then you’re doing them and your hiring time a massive disservice. You should not only follow up on the artifacts they’ve provided but attempt to find some on your own. This requires some internet sleuthing. Sometimes it as as simple as reaching out to an adjacent reference at the same place of business. You’re doing this to build a better picture but to also validate that what the candidate presented was an accurate view of themselves. I’ve found that 90% candidates who present a large amount of unbiased or near unbiased artifacts for review have done so accurately. Those that are inflating their abilities and worth on paper often fall apart at the even a cursory second pass. If they still get through, refer to the first piece of advice. #### #3 - Be The Cheerleader Not The Gatekeeper Your mindset going into a technical interview decides how successful it is in achieving the goal of building trust in a candidate. When you approach the interview as an antagonist, or a gatekeeper who’s default decision is a “YOU SHALL NOT PASS”, then all your interactions with the candidate will take on that energy. You create an unfair power dynamic in which you are actively seeking to make the candidates task difficult. Live-coding exercises, where you sit with hidden knowledge of the only set of acceptable answers, puts you in a position where any help or encouragement is patronizing and unhelpful. It’s true that in a real job you might let juniors flounder with an answer for a bit. You’re doing so not to judge their ability, but to help them grow and build the mental muscles necessary for development. Setting up a scenario in which the candidate flounders while you playe “warmer colder” with the answers does nothing but frustrate both sides. How can we do better at this? Again we build on the advice before us - do the legwork. The most effective interviews I’ve seen typically revolve around actual work problems that are in the process of being solved. Approaching the candidate with a real scenario relevant to work and coming in as a colleague instead of instructor, you can turn the time into a brainstorming and pair programming sessions rather quickly. You will have to revisit your technical interview often as circumstances change. You will have to make sure you approach each candidate the same way and you will have to stretch to build a grading matrix which is fair to everyone. ## Conclusion Has AI made technical interviews more difficult? Can’t they just have a screen reader/listener hear your problem regurgitate the answer? Absolutely. Do you know how quickly a good engineer can spot someone simply reading back answers? You probably know because you’ve already done it once or twice. Don’t let AI scare you away from pursuing better interview practices. Cheating has always existed - refer back to the first piece of advice again. I never want to feel like I did when I failed that technical interview. I never want to make any candidate feel that way. I will take the time to be a fair interviewer, do the legwork, and to work with candidates - not against them. Will you?