You're missing the point. The article is commenting on how every company is using FAANG practices even when it doesn't apply to them. Quote: "Because make no m

You're missing the point. The article is commenting on how every company is using FAANG practices even when it doesn't apply to them. Quote: "Because make no mistake, that technical interview - that one-shot coding test we do. That's it. If in the heat of the moment you make a mistake or don't pass, absolutely nothing else matters. FAANG (and sadly everyone else who has copied their half-assed hiring practices) will not hire you. Nothing overrides it: you could be a Nobel laureate and it wouldn't make one iota of difference." > Being able to produce a maintainable solution for a business problem and being able to communicate that solution to others is what is important. > > If what he says is true, then why aren't Google et al. hiring mediocre developers? FAANG interview questions do not constitute a "maintainable solution for a business problem" for most businesses. Unlike the author, I'm more willing to give FAANG the benefit of the doubt in their hiring practices but even then I'd give a very generous guess that only something like 20% of FAANG employees actually use the same skills in the interview in their everyday work. Sure, Google might be able to save money if an engineer can come up with a way to reverse-index a volume of Britannica with a memory constraint of 4MB but other businesses won't if only for the fact that they don't have the organizational infrastructure (QA pipeline, canary version rollout, etc.) to properly verify the correctness of such hackery nor sufficient business clout to cushion possible outages that come with the territory of building your own libraries. For most businesses, hiring an engineer experienced with Elasticsearch would provide them with the business value they are looking for. Unfortunately, said engineer who spent the last 4 months debugging their ES cluster's split brain problems did his whiteboard interview in a Python-like pseudocode and couldn't handle memory swapping properly. So it was an unanimous no. > If you are in a role where you are not doing coding day to day, then you need to evaluate that role and ask yourself, is code still right for me? I used to be in this "code everyday" mentality but I realized that a better mindset is to "solve problems/puzzles everyday". Someone who works on yet-another-CRUD-app on a daily basis is definitely coding everyday but is this activity leading to growth? On the other end of the spectrum we have someone who solves ICPC World Finals problems in that 20 minutes they have waiting for breakfast to be served; honestly more impressive than the CRUD guy hands down but consider that: - beyond something linear like lists, stacks, queues, there is very little opportunity to build a data structure class on your own. I've found my data structures knowledge useful in _reasoning about_ (not implementing) data structures other people wrote: the DOM is a tree, DB tables are trees, regexes are graphs, indices are look-up tables and/or hashes. - I've had to work with DP in my day job once and only once so far (out of 8 years working) and that was a very special circumstance at that. And, guess what, DP didn't really save the business in that situation. Communicating and cooperating with the non-engineering departments did. - Not to mention that sometimes life is just yak-shaving, as the article points out. I've made PRs with nothing but logs only so that three days later I can PR a one-line change (four, thanks to the linter) that would fix a performance problem I tracked down for three weeks. Or soldier through Jenkins and Maven so you can finally migrate your outdated CI pipeline.