The reason why good programmers also fail technical interviews is because the algorithmic/coding questions are mostly random. You can be asked any of over 1000 distinct questions, and if you haven't seen it before, almost no company will "reward" you by figuring it out on the spot. Instead they will compare you to another candidate that studied that question and gave a solution in the allotted time.<p>It's completely random chance at this point. I have friend who solved 700-800 Leetcode questions and got offers from Google and Facebook. I recently did 100 LC questions and got destroyed in the interviews. They didn't care about communication skills, asking the right questions, etc, everyone including Google, Facebook, Netflix etc expects the correct answer at the end.<p>It is what it is, and I accept it. It's stupid, it's not representative of how I work, and it's completely gamed at this point, but it's how Silicon Valley is hiring. There's no use in pretending I'm better than it, so it's just plain studying and leetcoding for 2 hours a night until I get a new job.
A long time ago I came up with an acronym that's served me well as a consultant who has to bounce from one customer to the next and run through interview gauntlets of all types: RACEMOORES:<p>R: Restate with sample inputs/outputs/diagrams<p>A: Assumptions ~ scale of inputs, uniqueness, range, variable parameters now and in the future<p>C: Complexity: runtime complexity, space complexity, etc<p>E: Edge cases<p>M: Maintainability<p>O: Overflow<p>O: Optimizations<p>R: Refactoring - DRY / SOLID / etc<p>E: Extensibility<p>S: Scalability<p>I use the "memory palace" heuristic to guide me through this, where each letter is a naked dude waving a flag on a racetrack I vividly remember from Gran Turismo back in the day. Absurdity helps it stick . I start every interview by writing this on the board and checking off the letters as I run through them. I usually stick another "O" in there for "Other stakeholders", depending on the gig.<p>This happens to work nicely when guiding/assessing interviewees through technical scenarios as well.
Hard to take advice from an article with a ton of typos.<p>The interview process seems to favor CS grads who memorize academic exercises and algorithms. It doesn't seem to take into account if you can actually produce a product and write maintainable code. I don't see the point as you can Google just about any solution during the work day, as needed, and real life work doesn't require you to write galaxy-scale algorithms within a 30 minute deadline.
This is so funny.<p>"The first advice is nice and simple: read my posts and watch my weekly videos." (Which he started two weeks ago.)<p>"Do not use the mouse! And use Vim or Emacs. Professional programmers only use keyboards and this kind of editors." (It's not 1980 any more, guys. There's been progress. The only time I use Vim is if I have to SSH into something.)<p>"Actually, there is less than 10% of changes to pass a technical interview, so don't set high expectations." (Does he mean "chances?")
The technical interviews I enjoy the most are where I write a small piece of software beforehand and we discuss the code during the technical interview. It gives me a better idea on what to prepare for because most questions are going to be about your technical decisions and ways to improve the solution. The downside is that doing a project for every job is a lot of work.
> Let me conclude with a personal quote:<p>> "The most important capacity for Software Engineers is their ability to developer soft skills"<p>Maybe those will get you hired, but attention to detail helps you keep your job.
I don't like the terminology 'fail'. It implies a mental model like an examination, where there's a clear link from effort, to performance, to reward.<p>A job interview is more like a date. It's two parties with a limited amount of time trying to gauge if they will be compatible. And, like a date, you shouldn't feel personally deficient if you end up being a poor fit. You should be aware that the other party may already have someone in the sidelines because, if you're popular, so may you. If the other party makes you jump through hoops you find silly, maybe that just means you're a bad fit, at which point you should feel confident to withdraw as an equal participant. If you pretend you're a better fit than you are, it won't work in the long run.<p>Crucially, you also shouldn't feel you're owed a reward just for being a good catch. If you are that good, it won't matter.
I got the most out of mock interviews: friends, colleagues, and when I ran out of people sites like PracticeCodingInterview.com, Gianlo.co, and Pramp.com. Just having a stranger judging me helped me up my game.
Also remember that many great opportunities will not have as their only states litmus test the usage of VIM. Not even most people that prefer that environment would use it as a litmus.
I'm starting to think the best way to prepare is to pay a coach to train you up and give feedback. The interviews dont have much to do with reality, if you want to be good at leetcode style whiteboarding you need to get advice from someone who knows how it works on the inside. (yeah I'm bitter)
Hired many, realised as long as they can do basic coding, I am not bothered about them solving complex problems. I need to identify their team and people skills first.
Best interview is the 3 week probation period, prev job and ask general questions on what you did that only someone who actually did that role would know.
I read a theory that says that these impossible interviews were designed so that companies can say they couldn't find any qualified stateside candidates so that they could get more H1B visas. It just kinda caught on because everyone wants to imitate FAANG.<p>When I started in 1997, it was a 30-60 minute walk in. Now I understand multi-day interviews are the norm. Madness.