> and its not an optimal solution.

Therein lies your problem, and you can see it writ large on everything Google does. Because they're so dominate at so many things (search, video hosting / streaming, etc.), anything that doesn't fall under "optimal solution" and "immediately profitable" goes to the waste bin near immediately.

There are entire websites dedicated to how fast Google kills a project that could have been really great with a year or two of love and care.

They've come to expect overnight success because it's been so dramatic for the past two decades. This blinds them to a lot of opportunities, and it comes, pretty much, from the top down and has filtered into nearly everyone.

> “google missed an opportunity to hire someone who might approach things a bit differently”.

That isn't what they want. See above. Optimal solutions, instant / near-instant profitability.

As a counterpoint to this, I interviewed at Google and was sure I had flunked. On every one of the follow-up questions, I didn't produce a working solution, let alone an optimal one.

I still got the offer.

Truthfully I do attribute much of it to luck. From what I have heard, most people had more difficult questions than I did, often with more strict interviewers. It's a high variance process for sure. If I were to interview for the same position now, I would most likely not pass the interviews.

Congratulations. I hope you enjoy working there. A close friend of mine used to work there in a very high position and they left after about a year or two, but left for what I consider to be pretty ridiculous reasons.

I'm not quite sure how much I could share without revealing their identity, but essentially they were sat down and told to work on their appearance. They had enormous technical chops (probably in the top 10 people in the entire world at what they do), but at least 60 lbs. overweight, no sense of style or fashion, etc., and as unfortunate as it might be to hear it... when you reach Director-level / C-suite positions, you need to physically project that OR you have to be so absolutely dominant at what you do that they cannot ignore you. They aren't that dominate.

A shame really, but they went off to work for a private startup and seem to be quite happy anyway.

I did okay in my interview with google but was passed over. The truth is they are always interviewing, so I think being hired has more to do with the timeframe of your interview than anything else. It's very similar to how the military drops many "requirements" of a soldier when what they need are bodies.

At some points, google is spinning something up, and at those points they need more devs, so they hire more of the interviewees. I think the rest of the process is basically random, based on the gut feelings of an entire team of random people.

I think you're a bit full of yourself here. There are objectively correct ways to search a graph, and it sounds like your solution was nowhere close.

You didn't get rejected because you "did not say the word graph", you got rejected because your solution was very wrong.

Software engineering is not just about knowing syntax, CS degrees include a Data Structures & Algorithms class for a reason.

> There are objectively correct ways to search a graph

Objectively false.

Years ago I was talking to some sort of CS professor who had been specializing in networking. He mentioned that within an organization you typically see network's being mapped out with dijkstra, but between them (with BGP for example) you actually see packets routed the long way around. He claimed service providers did this because it allowed them to charge their competitors more money when they had to use their network. Although, a more charitable interpretation is perhaps that a service provider will naturally want its own traffic to have the best experience and will send their competitors traffic the long way so that they don't over saturate the network of their primary customers.

Perhaps the best of all worlds would be mapping your network such that your primary customers get the optimal path using dijkstra. Then you figure out how to get your competitor's traffic routed as fast as possible without dropping your primary customer's packets. Maybe something a genetic algorithm might be good at figuring out?

There are some objective things in this world. The optimal way travel from point a to point b in a graph is one of them. However, this is the optimal way to travel, not the objectively correct way to travel.

I once traveled home from work using the backroads in a move that cost me probably 30 extra minutes. Roads are a graph. I followed the objectively non-optimal path. However, the way the clouds were that day formed something like 20 rainbows. Which I got to gawk at the whole way home. Objectively non-optimal, but not objectively incorrect.

The path is still optimal, but the weight of the edges are not speed or distance but a complex utility function that best represents the needs of the business.

It's also not about thinking creatively all the time. When I did interviews at a FAANG, there were many interviewers whose questions ranged from understanding basic CS to inventing new algorithms in specific circumstances. Generally, the second set of questions rarely had optimal solutions that took longer than O(n), and the first set of questions had answers that come out of a CS textbook.

In other words, the first set of questions is about doing normal tasks in the normal way, and the second set of questions is about solving relatively simple problems in a way that scales up massively.

When you are doing something that has a well-known optimal solution, your colleagues will expect it to be done in the well-known way. They don't want to have to read through your "creative" code to determine that you are just doing a graph search in a different way than they are used to. Engineering at a place like Google isn't about doing cool things: it's about doing things that are kind of cool in a way that a mediocre CS grad from a high-ranked school can understand and extend your solutions.

In my interview for my current job, I was asked to implement an algorithm that finds the edit distance between two strings. This is a classic algorithm, one that I had learned and implemented about a year before in my algorithms class, and loved for its utility, but I could not remember a specific little detail!

However, neither did my interviewers! So we worked together trying to re-derive the algorithm from the problem, the expected output, and the rough idea of how it worked. We did not succeed, but we did demonstrate an ability to work through things together, an ability to stand up and point out incorrect things, an ability to reason through a problem, etc. I got the job.

I would have hired you on the spot based on your slime mold experience!