Cakes have existed for centuries and I'm sure most people on HN have made cakes at least once in their life.

But put them in a room and say "Make us a 2 layer red velvet cake" with no access to a recipe, and you're not going to get a red velvet cake. It's an easy recipe that most people easily recognize with just a glance, and anyone could make it if they have a recipe on-hand or make red velvet cakes with abnormally high regularity. But most people, even if they're great chefs otherwise, will fail.

Recognizing that a concept exists and implementing a relatively complex concept are different things.

That's absolutely not the case. Many working pastry chefs (I just asked the two that I know) can do exactly what you're asking.

This strikes me as an analogy that does not work in your favor.

To know how to make a novel cake (not a recipe you've memorized), you need to have a good understanding of how the different ingredients interact. You probably even have a good sense of why they're there.

Those seem like exactly the qualities you'd want to look for in a cake maker. Sure, they'll probably be going from recipes in their day to day job. But they'll be able to tweak them intelligently too.

Most tech companies aren't looking for people to reimplement a dozen new variations of quicksort everyday. I mean, some companies really do need people who have countless algorithms ready to go in the back of their mind and the ability to apply them to new and interesting situations all the time, just like some people do need bakers who never need to consult a recipe and can devise new cakes for important events on a whim.

But most restaurants are looking for someone who knows how to cook and use the tools in the kitchen. A chef who doesn't specialize in cakes will still probably be fine if you give them 5 minutes to look up a recipe and make one. In the same way, the overwhelming majority of tech job openings are in need of programmers with some degree of specialization and the ability to know how to look up what they don't know and the experience/knowledge to know how to put that info to use.

The state of programming interviews for the past few decades has been to find people who've memorized all the "recipes" of CS. Most of the jobs, though, are about using some Javascript flavor of the month library and making it work with some other popular library and writing a bunch of interface code. Someone on the team might have to write an implementation of breadth-first search in their toy language, in which case they look up "bfs" on wikipedia and just rewrite the algo given.

Companies are testing employees on how to make cakes when their job will be all about making burgers to order.

But an algorithm or more generally algorithmic thinking is not a collection of rote memories. It's concepts that can be applied broadly. Much in the same way that I'd expect a pastry chef to be able to cook a 2 layer red velvet cake because they know that a red velvet cake is just chocolate, and a 2 later cake is just 2 one layer sheets with icing between. Someone who understands a relatively small set of fundamentals well will be able to perform as well or better than someone who spends weeks memorizing every cake in the dictionary.

I disagree. I don’t know based on what you are making claims, but based on my anecdotical experience knowing fundamentals help low level coders to pass interview but has little to do with performing well. Based on my experience (currently responsible for a huge chunk of a major gaming platform, with hundreds millions users), inflexibility, emotional immaturity, inability to think outside of the box, inability to listen and admit failures, lack of emphaty, not understanding basics of sales(to sell own ideas) are major things that contribute to a bad performance reviews. Our strongest engineers will not pass google interview without preparation (me included) and it is telling. Especially given the fact that we have higher profits per employee than google (we know what we are doing)

>Especially given the fact that we have higher profits per employee than google (we know what we are doing)

I'm dubious of this claim. Google/Alphabet has a PPE of ~$150,000. Activision-Blizzard has a PPE of ~$33,000, EA had ~$95,000, and Ubisoft ~$15000. I think the only possible major game studios who could meet your claim are Epic or maybe Valve. Unfortunately, those numbers aren't public. So I'm going to assume you work on Steam, since Epic's new platform is likely too recent to have lots of users, and also I don't think it was competently designed.

(the other thing is that this metric isn't particularly meaningful. Google invests a huge amount in unprofitable things with the goal of profits 5 or 10 years down the line. Google devotes thousands of engineers and billions of dollars to things it knows aren't profitable. That doesn't make Google more or less competent, it just implies different priorities than one that's entirely driven by immediate returns).

>Based on my experience (currently responsible for a huge chunk of a major gaming platform, with hundreds millions users), inflexibility, emotional immaturity, inability to think outside of the box, inability to listen and admit failures, lack of emphaty, not understanding basics of sales(to sell own ideas) are major things that contribute to a bad performance reviews.

All of these are important, but they only become important once you have the baseline level of competence. If you have two equally competent people, then yes indeed the softer skills like flexibility, creativity, humility, and communication skills start to matter, and eventually they matter a lot. But those are only good things if you assume a baseline level of competence.

Consider two options. One is that you screen solely for competence. You get only competent engineers along a wide range of interpersonal/soft skills. Some can grow into leadership roles, some can't (or at least it takes longer). But even the most convincing, best "salesperson" has great engineering talent. Then the alternative: that great salesperson is a bad engineer. The ideas they promote aren't always good ones, sometimes they're bad. That's not just "not good", its actively harmful.

>Our strongest engineers will not pass google interview without preparation (me included) and it is telling.

What does it tell? You seem to be suggesting that Google is optimizing badly, and that's possible. But that is by no means the only conclusion. Here's an alternative: "The most profitable things are not always the most technically challenging". Every once in a while you'll see people on HN commenting about how they wired up a shopify store that provides some significant passive income. That's not challenging. It would take an average engineer a week to do, if that. It's still profitable. But that doesn't make you qualified to work at Google (or Valve).

Maybe there’s a problem with which computer science is being taught if it’s so difficult for so many people to derive those solutions from fundamentals, and instead have to resort to brute force pattern memorization through Cracking the Coding Interview and Leetcoding.

There are literally tv shows and contests where they do exactly this.

I don't understand your comment. Was the parent suggesting BFS (or the like) is an exceedingly difficult concept to grasp? And if we're going to claim understanding BFS is like understanding zero, then wouldn't that just mean it's just as silly to complain about a question on BFS as it is to complain about a question on zero?

And it's not like it took people with PhD's years to come up with BFS. You see people make a similar argument about Dijkstra's algorithm, when he picked it as an example of a particularly easy problem to solve.

I hope you are not going to be asked to implement consensus alg on the whiteboard. Took less time to invent than 0, but good luck writing it.

I also use 0 every day. Do you use the BFS every day?

Absolutely! I don't write the algorithm every day, but I interact graphs, trees, and other such structures on a daily basis in my job, and traversing them is something that I work on. Every time I run `rm -r` for example!

I'm not asked to implement BFS every day, but the concept of a tree traversal is incredibly common.

Even more explicitly, a lot of my recent work has been involving automated refactoring tooling, so there's lots of work with abstract syntax trees and control flow graphs, which are trees or graphs, and therefore need be traversed.

Ok, here is the question for you. I’m from gaming company, so it is relevant: given a matrix of 0s and 1s where 0 is a wall and 1 is an empty space, write function that finds path between provided coordinates. It should be suitable for real time game, no gooogling. Go

I'm not clear what your point is. Sure you can come up with questions that are difficult or obscure.

Yes I can probably implement a sufficiently fast maze solving algorithm, depending on exactly the environmental constraints (for ezple, given the problem as stated I'd assume something like a* using a precomputed mat heuristic would be fast for most mazes of reasonable size, I promise either didn't google that).

But I wouldn't expect someone to answer that in an interview. Hell, I don't ask dynamic programming questions because I think they're too obscure and tricky (in the riddle way). My most common interview question involves a problem I've faced multiple times at work, has multiple valid solutions, and which I had to implement myself in various flavors before eventually coming across a relatively obscure standard library implemention.

Although before I was able to identify that implementation, I had to solve the problem 2 or 3 times, see the different flavors, and identify the common themes and the theoretical underpinnings.

I don't expect a candidate to do that without help, and most don't. But it sure sounds like you think that I'm somehow a bad engineer for asking a question that tests on the job skills I've needed, and the ability to break a problem down into component parts and implement them cleanly.

But oh no, it uses an algorithm. It's a terrible question and I should just ask a question about software engineering that doesn't use any algorithms. Because obviously people will always be able to identify the standard library implemention (no candidate I've interviewed ever has, in fact). So colore dubious of this whole argument about whiteboarding questions being a bad test.

BFS as a name isn’t a difficult concept to grasp either.