Wasting time in tech interviews

&gt; Despite a long and storied career in software development, I have few abstract problem-solving skills. I proceed through problems in increments, getting slightly better each time. The beneficial thing for you that my experience brings is that I can do it really fast. Fast enough to deliver a working piece of software in a timeframe that won’t bankrupt you.<p>&gt; Never in my entire career have I whiteboarded a solution that even remotely survived contact with software frameworks, APIs and hardware constraints. A hundred different gotchas and restrictions lay in wait. The only way through them to a resilient solution is one step at a time. So, I can’t show you anything meaningful with Leetcode challenges unless I practice them as a discrete skill.<p>This, 1000x. This whole piece nails it, but this really jumped out.<p>I succeed and excel because I actually get things done, rather than &quot;mostly done&quot;. No interview methodology ever can hope to screen for this. Or any of the other things mentioned above.<p>The process is getting worse, not better, and this piece rightly points out why.

&gt;I’m exaggerating the amount of skill that I have. Everyone is. I use the right buzzwords on my CV. I inflate the scale of my achievements and the depth of my skillset. I even add tasks and responsibilities to historical jobs that fit your requirements. You’re never going to check, are you?<p>I don&#x27;t, I&#x27;m honest in my CV and during interviews<p>I&#x27;m selling myself &#x27;as-is&#x27; e.g despite using git for longer peroid of time, but mostly via GUI, then I&#x27;m not going to call myself proficient&#x2F;experienced git user cuz I&#x27;d fail some above basics question

Back in the nineties, I worked for a big company where <i>lots</i> of people wanted to work. We had what I called &quot;resume reading parties&quot;. A half-dozen of us, managers and ICs, would sit around a pile of resumes in the middle and start reading. When we finished each one we would check either &quot;Y&quot; or &quot;N&quot; and pass the resume to our left...except two noes and the resume was put in the reject pile. Sometimes they fed us. From there would be phone screening then on-site interviews. HR didn&#x27;t like being cut out of the loop but we knew we were better at screening than they were.<p>A benefit of this process is that your resume-writing skills improve a lot. Read a hundred or so resumes and you&#x27;ll learn what catches your eye and what gets ignored.<p>Alas, nobody else does this. I used to mention this process at places I worked but people thought I was nuts. It worked, though. We rarely had a hire that didn&#x27;t work out.

I too once scoffed at grinding leetcode. I’d rather work on side projects or blog instead.<p>But after 5 years of failing to get a job offer, I finally caved. Putting in the effort to deeply understand DS&#x2F;algos and grind away leetcode led me to getting offers I liked and IMO has made me a better engineer.<p>I now have a “gold star” on my resume and am confident I can still answer most leetcode questions. I consider that time spent as a great time investment, since landing my next job will be much easier.<p>Money wasn’t my original goal when I got into CS, but it eventually became my driving force. I regret taking so long to notice this, and letting my feelings get in my way (of how it “should be”) &#x2F; resisting leetcode for so long.

I&#x27;m in the software business for over 20 years. Currently working as an architect, but still do a lot of coding daily. I believe I have a pretty good grasp on computer science concepts. Know several programming languages very well. Keep myself up to date with the latest trends.<p>I couldn&#x27;t pass a technical interview. At some point in life I gave up. I realized the only way I can get a good job is via somebody in the company knowing me, ideally them reaching out to me to work for them. For the jobs, where I passed the technical interviews, I quit fairly quickly, as they were horrible jobs.<p>So when doing interviews myself, I just chat with them about the project we have and things they mentioned on their CV. You can easily detect if they are honest in their CV and their level of competence without actually asking too many technical questions, just by having them talk about the stuff on their CV.

&gt; You’re never going to check, are you?<p>I&#x27;m definitely going to ask probing questions about the tech. And the more familiar I am with it (and the more relevant it is to the job), the more detailed and discerning I will be.<p>It works too. The outcome is usually either, the interviewee is rattled and straight up admits that they don&#x27;t know as much as their resume claims; or, we get to have a pretty in depth conversation about what the interviewee has actually done<p>The former is fine with me. I think most developers understand it&#x27;s better to come clean early. When interviewing with me, that&#x27;s the right call, because if I think you don&#x27;t know you&#x27;re stuff, you&#x27;ll fail, but if you admit that you aren&#x27;t so familiar with $technology, then I&#x27;ll shift my questions to something else.<p>The latter is ideal though, since it segues well into the actual job requirements, and the interviewee gets real insight into what they are walking into.<p>The person who wrote this article is a-typical. I&#x27;ve interviewed people with github accounts, but most of the time they are full of college course work or cloned open source repos, so they aren&#x27;t really worth investigating too deeply. But someone with an active open source project on github and a popular blog seems like an easy interview, but I&#x27;ve never had the opportunity to speak with anyone like that.

Interviewing gets discussed a lot here. Very little actually gets improved. If you want a (1) high paying job (2) and want to work on products that scale to millions, there&#x27;s just no way you can escape leetcode style interviews. I&#x27;ve 2 decades of experience and have resisted it for sometime, but eventually gave in. These companies have way too many candidates to filter, so unless you&#x27;re one of those inventors of popular frameworks like Tensorflow&#x2F;Pytorch, you&#x27;ve to go through the grind. And with the popularity of blogs&#x2F;tutorials&#x2F;coaching classes the bar is only increasing. 2 medium problems in 30 mins is not a joke unless you&#x27;ve solved the same problems before or solved hundreds to quickly decipher the patterns. All this really breaks the back of staff&#x2F;sr. staff level folks who rather choose to stay where they are even if that means lesser pay.

I recently went through an interview process where to advance to the technical interview I would have to learn Go. I know a ton of languages. Haven’t done much with Go. Could I learn it? Sure, I could. But… I am not going to learn a new language where I am comfortable enough to do an interview just so that I have a chance to work for your pre-A round company. I am especially not going to do it when I have 2 job offers sitting on the table that I am currently considering. If you’re a startup founder recruiting other devs, don’t ask them to learn a whole new language on spec so they can interview with you. I’m sorry. You’re just not as hot as you think you are.

While I do understand where this view is coming from, I think it&#x27;s also a major waste of time to complain about it.<p>Let me put it this way - you are not entitled to a high-earning FAANG job. It&#x27;s really that simple. It&#x27;s a free market, and companies can select the way they recruit their people. You feel like it&#x27;s a waste of time to learn Leetcode questions? Then don&#x27;t do it. Case closed.<p>I say this as someone who failed multiple algorithm questions because I did not invest enough time to be good at them.

To be honest I looked at github - there&#x27;s barely any activity, projects have little if any descriptions, the professional experience has been 12 years of mix of project management and customer support, some 2 years of freelance and contract devops work. Medium posts are mostly crypto related. Now compare that with LinkedIn about section, and there&#x27;s an entirely different picture.<p>It could be that the reason you are getting the interviews is the Linkedin profile (especially as often companies encourage interviewing people with atypical background), but maybe you fall short of the image you are projecting? The form of the interviews might not help highlight your skills, of course, but it&#x27;s probably not the only factor.

&gt;I’m exaggerating the amount of skill that I have. Everyone is. I use the right buzzwords on my CV. I inflate the scale of my achievements and the depth of my skillset. I even add tasks and responsibilities to historical jobs that fit your requirements. You’re never going to check, are you?<p>I don&#x27;t think everyone does this. I certainly have never done this. I&#x27;ve never had an issue getting interviews using an honest accounting of my work experience, and I know as an interviewer I use the candidate&#x27;s resume as the basis for forming my questions to ask them. I would expect others to do the same. Filling your resume with things you didn&#x27;t actually do just makes the interview harder.

I&#x27;ve said this before, but I&#x27;ll share it here. This is my current interview process for any front end dev, regardless of level, including the thinking that goes into it. The whole thing is designed to take 2 hours or less. Note: We provide either a physical laptop if onsite, or an AWS box pre-set up for this.<p>1. Here&#x27;s a project with a back end API server, it&#x27;s a repository already cloned to disk, and includes a README.md with very detailed (local) deployment instructions, that one can copy+paste. Thinking: Validates the individual&#x27;s ability to read, and synthesise<p>2. Run the API server - this in turn provides a swagger API, that allows users to see the available APIs in their browser, and instructions to do so. The machine has various chrome plugins, Postman, curl, etc pre-installed. Thinking: Validates curiosity, and basic understanding of the modern(ish) web.<p>3. The candidate is to create a new project (framework of their choosing). They have the time of their choosing to implement an impossible to complete task (which we share). They have to create &lt;something&gt; that can trigger various APIs to insert, update, and remove data from a database. We provide the sample data in text files such that copy+paste is possible. Thinking: Validates if and how they reach out for assistance. Helps us understand where the candidate likes to spend the time of their choosing while working on a solution. Encourages a conversation about difficulties, frustrations, what could have gone better, and feedback.<p>This entire process is designed to ensure that we actively interview the candidate with something &quot;real&quot;. It allows us to understand the real level of a candidate based on their efforts (i.e write tests, don&#x27;t write tests). This is not perfect - but it&#x27;s the best we could get. I&#x27;d love feedback.

&gt;given me a take-home coding assignment of at least 30hrs of work<p>It&#x27;s absolutely astounding to me that people must entertain these at a sufficient rate that companies still try to pull this free labor nonsense. One company I interviewed with provided a take-home assignment and said to bill them for the hours; I found that to be a fair offer, although due to other circumstances limiting my available time, I declined to continue the interview at that point.<p>If the take-home assignment is expected to take a few hours, maybe it&#x27;s worth considering. Any longer, and they can look elsewhere for free labor. That time is much better spent sending out more applications, networking, leetcoding for FANG interviews, working on personal projects, or simply taking a walk outside.

I have more than a decade of experience in SWE and a resume that boasts big tech names. If you hired me based on my GitHub, I would not have a job.<p>Truth be told, I haven’t used public git since undergrad (for assignments). I don’t do extra curricular projects. Mostly because I don’t have the time to. I’ve never had it, except maybe the first year of my professional experience. All the free time I have if any, goes towards other projects that I do at work. And honestly, I am okay with that. Building a portfolio takes a lot of time, and it becomes irrelevant real fast. It is also, a waste of time.

I recently got kicked from a hiring process after a good third round call with the CTO because at some point I’d refused to do a leetcode. I hadn’t, but I had pushed back and asked why round one was a hackerank round, when it was a senior management SRE-team position. Not normally a role with a lot of leetcode. I’d only asked why it was necessary, not refused it. In that actual interview the interviewer (their principle engineer) said he’d looked at my resume as prep, wondered why HR even scheduled a leetcode and skipped the code review and asked questions instead.<p>He passed me. 2 rounds later the recruiter decided he didn’t lie I’d pushed back early on.<p>Personally I hate leetcode style challenges and seldom use them. Designing our recent hiring process for our org I included a take-home, but made sure it:<p>- time limited to 2-4 hours<p>- had the team practice and verify it’s doable<p>- clear objectives<p>- clear marking criteria<p>- any language they want<p>It came down to a somewhat typical platform eng&#x2F;sre&#x2F;DevOps type task of working with APIs, so chose our company’s public API, so it’s somewhat relevant and interesting, and asking the candidate to write something to read and process our API data.<p>The really key goal being to weed out people who:<p>- just can’t write any code at all<p>- don’t approach problems in a code-first repeatable way.<p>I learn a lot through running it, and improved the take-home in many ways based on feedback.<p>The rubric offered the option to do it in a session as a leet-code style round, no one ever asked for that out of hundreds of candidates.

Some kind of minimal helpful feedback upon request after an unsuccessful on-site is the big one for me. The hiring manager can share one sentence of filtered feedback with the recruiter, the recruiter can share that one sentence with the candidate over the phone. Five minutes per candidate all in. If you say &quot;but legal liability&quot; you have no courage.

The author is in DevOps, which seems like it should have its own interviews process distinct from general SWE. Seems like putting such folks through the Leetcode gauntlet would be a mismatch in expectations.

I had a github profile once, but a conflict with the Go team lead to my account being blacklisted (flagged). So I deleted 150+ repos from it and the account. I host my own gogs and recently gitea instances now and there is little public code there. The public code is not representative and I won&#x27;t give you access to my private code.<p>I also won&#x27;t do pre-noon interviews.<p>If you start pressuring me I&#x27;ll revoke the application.<p>You can be lucky I even applied to your company, despite all the bs buzzword requirements you have posted you have no clue about what they mean.<p>I am very angry at current hype driven job ads. And yes I wager they&#x27;re more of an ad for the company than actual job ads.<p>From some ads where I sent my application to I have never even heard back, which means they probably sold my info.<p>Even reading all those job ads is tiresome. Most don&#x27;t even write if they&#x27;re ok with 100% remote. Most don&#x27;t even write if it&#x27;s ok to not work 100% full time. Most don&#x27;t write how much they&#x27;re willing to pay. Most job ads are just a waste of time spicked with bs trendy buzzwords.<p>I&#x27;m so pissed at the whole state of everything.

Context: I am myself a tech lead &#x2F; team manager and at the moment I try to recruit a more senior developer.<p>My way to assess candidates differ from the style the blog describes, but of course I do some kind of technical screening. From my point of view, this blog, obviously, just describes the view of the candidate. And maybe this person is quite good at his job. But you have to consider, that you get a lot of candidates who can&#x27;t get things done. I screen candidates who want to do a PhD in computer science but write code like we are 20 years or more in the past. I get candidates with a degree in computer science who do a little programming task that won&#x27;t compile at all.<p>What I want to say is, don&#x27;t underestimate the sheer number of people who apply (or get brought in by recruiting companies) who, to be honest, cant develop software that&#x27;s a little more complex.

I think an ever bigger evil is companies who do not calibrate their Leetcode type tests to their hiring needs. I was given a take-home test few years ago by a well-to do medical software company based out of Verona, WI. Their programming test had a question from past ICPC.<p>Typically Olympiad questions takes well-to-do teamwork &amp; few hours of brainstorming - not a 30min timed test you give with a proctor watching your monitor

In my experience, interviewing for engineering teams is an afterthought that comes from how little interviewers are included in designing the interview process they have to use. When I approach each opening like a software project with a kickoff, buy-in from everyone working on the project, assignment of tasks, etc, you get more investment from the interviewers. You also get higher quality candidates making it past the recruiting stage, because the recruiters better understand what to look for. Without that, I think most engineers view interviewing as something that takes them away from their &quot;real&quot; job.

Interviewing in tech is a mess especially with the self-aggrandizing questions.<p>Besides the questions, you get interviewed by recruiters. The recruiter, very likely a person that has never done anything technical, been in a technical team, delivered products&#x2F;features under tight timelines...<p>Companies do not want their engineers and product people spending time interviewing prospects, so they throw recruiters at the problem and end up frustrating and wasting the time of other engineers. Like, it&#x27;s your problem, not ours.<p>If a recruiter reaches out and I&#x27;m interested, I ask to talk to someone technical.

It seems like companies do this because the stakes are so high to them. That is, if you hire this person and they fail, they will somehow do serious damage to the company. If you do this at a large enough scale, then you are putting the company in serious danger.<p>How do you de-risk this? My take would be to focus on getting &quot;good enough&quot; candidates in and then if they don&#x27;t work out, be able to fire them easily. It&#x27;s tough to normalize that. It&#x27;s legal in states that have at-will employment but it seems that there are still taboos to doing that.

What I don&#x27;t get is when they ghost you, but with positive feedback! I was talking to a guy not long ago, everything was a fit, I&#x27;d done exactly what they wanted in my previous job, had team management experience, and so on. The HM&#x2F;founder says I sound great and we should talk again.<p>So he goes on holiday.<p>Then his HR lady goes on holiday.<p>They get back, apologize for the delay, and want to proceed.<p>Nothing happens. No response...<p>He&#x27;s probably right about homework too. I can&#x27;t tell if they are actually testing for you already having a solution on the shelf that you can slightly modify for them. Regardless, if someone did a homework assignment for me, I would make sure they got feedback. If it wasn&#x27;t good enough I would think really hard about what I said about the conditions (don&#x27;t spend too much time, it&#x27;s ok if it isn&#x27;t perfect) before dumping them. At best it is just a kind of fizzbuzz: if they can stand up a k8s thing in a few hours, they are likely not making this up or even copy pasting it.<p>End of the day software has some odd ideas about what evidence is. Just about every other profession is just a CV, some chat, a light grilling, then a response. If the person is making it up they&#x27;ll get found out and dumped out soon enough. Software somehow manages to do both: several interviewers have told me they dumped out a guy after a brief stint, then tried the whole Leetcode&#x2F;homework&#x2F;tech chat thing.

Avoiding the p1ssing contest is very important, as well as ensuring we don&#x27;t have egotistical a-holes interviewing.<p>In a role we&#x27;re currently interviewing for, we intentionally ask deep-dive style questions. We first explain our approach by telling the candidate we don&#x27;t necessarily care about the answer; we seek to assess aptitude, rather than ability, and so we ask the candidate to be as vocal as possible to display their reasoning. So far, it has helped us narrow-down the pool to two promising candidates. Of course, we also mention in the interview that, &quot;we&#x27;d make liberal use of google, and we understand that most other people would too&quot; - but some of our better interviews have turned into pleasant, fruitful technical discussions, and not just a back-and-forth &quot;pub quiz&quot;. Just my $0.02.

I gotta agree here. I don&#x27;t do leetcode challenges. There was one point in my life where I began studying them to pass these filters, but I rather be doing anything else than leetcode...so I stopped. I&#x27;ve never been unemployed so its easy for me to decline jobs when they present me with these challenges. If I were ever out of a job and struggling to get a job I am pretty sure that would change my tune. Until then I reject those companies.<p>Now thats not to say I won&#x27;t do coding assignments, but I weigh those pretty heavily. If the employer seems pretty amazing I&#x27;ll do them, if they seem meh then I decline.<p>On the flip side, I&#x27;ve had interviews where they asked me no technical questions and no coding challenges. That is an enormous red flag to me.

High tech interviews are as much a personality test as a test of intellect. What do people do when they buy a car? They kick the tires, bounce it on it&#x27;s shocks to see how it responds, get in and hit the gas hard, take it fast around a few corners. If the interview was about what you&#x27;re supposed to know it wouldn&#x27;t be too stressful, would it? No, they want to hit you with some curveballs from multiple people and see if you fly off the handle or handle it with grace and humor. Humor especially. If you can make people smile or laugh you have a much better chance. That&#x27;s been my experience. I&#x27;ve failed every interview where I got angry, even if I didn&#x27;t express it. They could tell.

Reading the comments on these kinds of HN posts stresses me out. Not for me, but for <i>you</i>.<p>I wish I could just give you all a big hug and a pep talk.<p>The demand for software engineers is expanding faster than new engineers are minted. There are lots of excellent, well-paying jobs going unfilled out there and with persistence one of them is yours. If you fail a tech interview, it&#x27;s ok. It happens, and all too often it&#x27;s a blessing in disguise. Well-designed tech interviews bring your strengths to the surface and you will do well. Otherwise it&#x27;s just a crap shoot and sometimes you win anyway.<p>Chin up. You <i>will</i> make it.

I have found most software developers cannot write software…at all. Most interviewers seem to find people that can actually write software grossly incompatible.<p>Knowing this I try to cut through all the bullshit and immaturity by focusing on leadership and measures. Software is exceedingly immature and biased, but it doesn’t have to be that way.<p>I interviewed at a FAANG this year and it was one of the worst: leet code nonsense and false assumptions about performance that don’t survive reality. They might pay well, but the interview made it feel like a dead end hourly job flipping burgers.

He is absolutely right! I&#x27;ve wasted a lot of time of my live that I&#x27;ll never get back. I could have spent with family, friends, which some have passed away.<p>It got extremely hard for me between issues with IR35, Brexit and the pandemic. 4 stage interviews in multiple places with long take home tests; some which I didn&#x27;t even sleep to deliver as quickly as possible.<p>Some interviewers had nothing much on their public profiles, either GitHub or personal sites. An absolute lack of respect.<p>Https:&#x2F;&#x2F;GitHub.com&#x2F;heldrida

The thing I hate the most is that 80% of the time you will be kicked out of the interview process before you even talk to the person you will be working with.<p>Your GitHub doesn&#x27;t matter Your resume to a degree doesn&#x27;t matter If you can answer the questions and solve the problems that matters<p>...but what matters most is if you have a good attitude and can do the job you are being hired for and it&#x27;s pretty rare someone hires you based on <i>gasp</i> the job they expect you to do.<p>Show me someone who can write merge sort from scratch and I&#x27;ll show you an unemployed programmer.

I really hate the discourse around tech interviews. Every blog post is exactly the same: that leetcode isn&#x27;t an indicator of real skill, that the whole landscape is terrible, and everything is completely awful and no one knows how to hire anyone.<p>We need good data based approaches to tech interviews to move the discourse forward; I really like triplebyte&#x27;s talks and blog posts on how to hire, and what they mainly point out is that a good interview process provides a decent signal on how successful an employee will be.

Ive been trying to negotiate interview processes (I have 15+ years experience, staff&#x2F;principal level). Been relatively successful getting adjustments at smaller startups (approximately 10-20 engineers).<p>It seems anything larger I run into push back. Perhaps maybe the size of the company may be a key indicator? Maybe as a company scales you can’t be dependent on hiring managers knowing how to hire good people so you rely on filter mechanisms that are cheap and lazy.

Contrary to the OP I think Leetcode questions are useful to test the abilities of candidates, including their understanding of Big O complexity.<p>What I don&#x27;t understand is why there isn&#x27;t a standardized (proctored) test that companies could rely on, instead of re-testing each candidate themselves.<p>Couldn&#x27;t FAANGs put resources together to establish an independent testing institute? Wouldn&#x27;t that save everybody a lot of time and money?

&gt; You won’t read my code because reading code takes 10x more time and effort than writing it.<p>&gt; Particularly in DevOps, my specialism. There is no test for debugging SSL certificate chains in production at 3am.<p>&gt; We can’t replicate having no answers as to why production is down at 6pm on Christmas Eve or how we will stay at our desk until it’s fixed.<p>So, I’m getting the sense that this person enjoys devops. I wonder if they are trapped between engineering and ops - good at both, but not great at either.<p>if this person wants to work at a larger tech company, maybe this person should apply to be an SRE?<p>They have very valuable skills and the pay for SRE often exceeds the pay for engineers. I’d not expect an SRE interview to be as focused on whiteboarding, but have a much deeper understanding of a systems toolchain, eg how to use Linux tools to diagnose a network issue.

If you are as skilled as you say you are, getting through a few challenging questions in a technical interview should be a breeze. Also, don’t discount the feedback that your interviewers don’t like your personality. If you have heard that more than once, that may be the crux of your problem.

&gt; I’m not going to use Google before your very eyes, either. Obviously.<p>I have the hardest time convincing interview candidates that I in fact want to watch them use Google to solve a problem. It turns out that many people are ineffective at finding and reading documentation.

As an employer, we are always trying to improve our technical interview. At this point in time we&#x27;ve found the best approach is to look at the ticket board and think &quot;If I had a new developer, what could they work on?&quot;. Then come up with a single real world question and ask the candidate this during the interview. The question should allow for a junior or senior to give an answer where the depth of the answer would likely vary much like the feedback on a hypothetical peer review would. We try to avoid anything requiring too much business domain knowledge. You should be able to explain the scenario to someone off the street (non-developer). We then have a face to face (or screen share) discussion about the problem, any questions or scoping and the approach that could be taken like any real developer would if they were given this as a ticket.<p>As an example:<p>---<p>We have an existing job management system to track and update the progress of warranty repairs (e.g. whitegoods). Sometimes parts need to be ordered to complete a repair. If we wanted the job system to book and track parts orders into third-party warehouse management systems; how would you address the following?<p>- Credential management<p>- Data types and their life cycles<p>- Sources of truth e.g.<p><pre><code> - Customers who have purchased whitegoods are the source of truth for new jobs - Our staff operate the job system and our clients (manufacturers) are the source of truth for parts - Tradespeople operate the job system and are the source of truth for new parts orders - Warehouse staff operate the WMS and are the source of truth for stock levels </code></pre> - Required&#x2F;Optional API calls and their triggers<p>- Fault tolerance and monitoring<p>- Compensate for variations&#x2F;shortfalls in existing WMS APIs (in some countries we use a 3PL)<p>WMS: Warehouse Management Software<p>3PL: An external company who operates a warehouse and dispatches items on your behalf. These companies may do so for multiple tenants and have established staff, processes and WMS.

There are also job descriptions that do not state whether it is a remote job or where on the planet you are expected to work. City, state, country? Anything? You go to their website and also no address or clue of where the company is.

Personally, I just remember getting bored talking with AWS and Google reps, then just sort of wandered back to focus on something more interesting. Understanding corporate cultures is similar to ecology: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Competitive_exclusion_principle" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Competitive_exclusion_principl...</a><p>There should come a point in your career when you realize “Process” people have a different set of priorities, and being secure enough to not make decisions in simulated peril is wise. ;-)

This topic (whiteboarding in tech) is so common and SO boring! I work in an engineering org with ‘real’ engineers (mech eng, electrical, chemical eng etc) and I’m on a multidisciplinary team. No one tested my code on a whiteboard on the way in. They trusted the fact I have a CS degree from an elite U.K. university and numerous other software qualifications. Whiteboarding is just a bizarre fetish for people who want to felate Silicon Valley wankers. Screw this sh1t

&gt; I’m exaggerating the amount of skill that I have ... I inflate the scale of my achievements and the depth of my skillset. I even add tasks and responsibilities to historical jobs that fit your requirements. ...<p>&gt; If you want better candidates filling roles, ... Check the candidate’s portfolio.<p>Why wouldn&#x27;t a candidate&#x27;s portfolio be fake too? Someone else&#x27;s work, plagiarized with minor edits &#x2F; refactorings to make it look unique, for example<p>Why would it be off limits to cheat on GitHub but ok in one&#x27;s CV

hot take: OP is confusing memorizing &quot;how to debug SSL certificates&quot; with problem solving skills

&gt; A company recently wanted me to choose an application, terraform an infra for it (including CI&#x2F;CD pipelines) and have the whole thing launchable from zero in a single line. They estimated this piece of work at four hours. Four hours if I copied and pasted the lot from Github, perhaps.<p>Oh boy. Yeah, that&#x27;s the issue I see with most of those &quot;take home&quot; exercises<p>(and then of course they take the candidates that spent 20h on it instead of 4h)

One important reason for coding questions I haven’t read in the comments is the need to avoid the interviewer’s personal bias. I’ve seen a lot of people say they can feel someone is a bad interviewer but how do you quantify that? Large corps need to protect themselves.<p>They also need to make candidates feel like they were tested using the same criteria as other candidates.

The best &quot;coding test&quot; I saw recently was a company that just asked &quot;send us some technical writing (white paper, blog, whatever) you did about working a problem, if you don&#x27;t have anything you can legally send us, just write a short essay about something cool.&quot;<p>The funny part was that they linked to it and called it a coding test.

It is not a waste of hiring team time if we avoid hiring a candidate that doesn&#x27;t meet our standards. We try very hard to find good candidates, but it doesn&#x27;t mean we will stop interviewing if the candidate pool runs dry. We&#x27;ll just have to spend more time looking for quality applicants.

&gt; If you want better candidates filling roles, you must stop being lazy and relying on Leetcode or lazy CV parsing. Check the candidate’s portfolio. Pose realistic questions.<p>Lets be honest. What you want is easier questions. Vague questions that can be discussed and argued one way or the other.

Nice blogpost but you&#x27;re just in the wrong industry. It&#x27;s really your own fault if you don&#x27;t get offers thrown at you daily with the skillse you have. Stop messing around with solidity and this rotten industry and start writing real software.

Leetcode is great. If you can&#x27;t solve a couple of easy LC questions, I would question your problem-solving skills.

I also learned lately if they wish to record the interview, it most likely is for their benefit to prove their &quot;interviewing&quot; other candidates. I had an experience earlier this year with a famous&#x2F;popular &quot;equity firm&quot; that when I refused and asked if they were recording beforehand, went on a tidbit about how they needed too&#x2F;it&#x27;s normal.

End of the day hiring the wrong person is worse than hiring no one. So I’m willing to forgive companies for how much scrutiny they have.<p>Sure some it’s kinda performative, but I’ve been on teams where HR was just letting anyone in and it screwed a lot up.

Gatekeeping ceremony is strong with the IT.

I feel like 95% of people are friends or family anyway. 5% are hired off the street.

TL;DR<p>&gt; There is no test for debugging SSL certificate chains in production at 3am

Just don&#x27;t bother with amateur companies. Sometimes it means doing the FANG leetcode grind. Lesser of two evils IMO

I can&#x27;t relate to these articles anymore, honestly...<p>I get it, interviewing sucks, Leetcode sucks and FAANG-level interviews are tailored for a very specific skillset.<p>And while Leetcode problems are a horrible proxy, there are a few caveats to be aware of:<p>- In terms of acquired skill level, I guess we all agree it&#x27;s harder to gain context on a new codebase and debug production issues at 6am. However, we do this repeatedly, every time we switch jobs. Contexts are different, business, issues and tech stacks are different. Yet, we always succeed. Leetcode should be the same: just a crap you have to shove down for a few months before interviewing and then forget about. It&#x27;s not pleasant, but, if you can debug prod issues with ease, a few relaxed months doing some closed-form problems that repeat themselves over and over should be _doable_.<p>- Not all companies require technical interviews based on Leetcode.<p>In the end, the weight of: effort put in vs. company reputation vs. salary will end up dictating what you will be able to (or want to) apply for and work hard for.<p>I personally am on your boat: hate leetcode, suck at it 100%, but, I&#x27;ve accepted that there are many, many great companies which have fair and representative interview processes and still allow you to do meaningful work. You know, the companies you&#x27;ve never heard about on the internet in your local area or city? Yep, those ones.<p>I believe that this kind of &quot;self-pity&quot; or claiming that the entire industry sucks, is broken, needs Leetcode is a bit too much. Sure, some very high stakes companies do it, but, again, those will attract the engineers who have the willingness, perseverance and skill to power through those problems (plus system design too!!) and get the job. It&#x27;s a skill. The more conscious effort you put into it, the better you will become.<p>The real issue is then losing sight of the forest for the trees: the real work begins once you are hired. I don&#x27;t know if this process truly finds _better_ candidates in average... But, imo, it doesn&#x27;t need to: there will be extremely smart people who will simply stay away out of these types of processes and that&#x27;s totally fine, as it keeps the talent pools balanced and creates super cool and interesting work environments and projects centered around &quot;the other 99%&quot; of companies.

&gt; You won’t read my code because reading code takes 10x more time and effort than writing it.<p>When I first read this I assumed sarcasm and moved on, but later it seemed odd as the tone of the article isn&#x27;t very sarcastic overall.<p>If this wasn&#x27;t sarcastic then I disagree 1000%. Code should be much easier to read than write. The only code I&#x27;ve come across that I&#x27;d put as harder to read than write is a few cases of just terribly written code. They were the exceptions, not the standard.