The items you list may not be as universal in software development as you seem to think they are. There are plenty of highly competent programmers who haven’t thought about designing a database schema in many years, or who have never deployed code to a cloud environment (at least not in the way you have in mind).

Having a set of common knowledge to interview about is in fact very useful.

Interviewing is assessing how a person would perform, not an actual day to day collaboration. There is a gap. You do not talk like you would to a colleague. You have a limited time and it's more one-sided to even the playing field. It's worth preparing for to overcome the gap.

It's like a dance. Your are supposed to lead deriving the solution, interviewer is supposed to follow closely and judge your performance.

If you expect to ace an interview just like that then you also need to be lucky not accidentally getting asked to stuff, which you always need to Google an answer to, basic algorithms and patterns, which you usually kind of know but could slow you down during the precious 40 minutes you have to show off your skills.

And lastly, people do prepare for these. If you do not do that, you might simply make a slightly worse impression than someone who did.

That being said, I mostly did not prepare for the coding interviews. I focused on the design and behavioral interviews.

I would never change the way I speak to someone just because they're interviewing me. If you're interviewing me it's with a view to working with me on your team a few months later. You would surely want to see the real me, not some constrained version. Maybe it's an age thing, but I'm comfortable enough with my skills and my knowledge that I don't feel the need to put on an act. And remember that you're interviewing the interviewers as much as they're interviewing you.

Also, I would also be quite surprised if Google didn't allow candidates to Google information during the interview...

> Also, I would also be quite surprised if Google didn't allow candidates to Google information during the interview

I did a Google onsite several years ago (probably 7 or 8 years ago at this point). Each interview was just me in a room with a whiteboard and a person sitting at a table across from me with a notepad. No computer present.

I suppose I could have dug out my phone and Googled, but that feels unprofessional to me, moreso than if I had access to a computer.

Also the part I got stuck on was coming up with the trick needed to solve the problems. Most I was fine, but one in particular would have taken some decent searching to find something equivalent if I just Googled, and would have taken some time to grok the answer. Also that guy was not very forthcoming with hints or information when I asked him, so I doubt he'd have appreciated a Google search.

I don't remember the exact question, but it had to do with converting a 3D city model into a 2D skyline by drawing a single line. I got stuck on trying to visualize how to deal with partial overlapping models and irregular building shapes and ran out of time.

Did you pass the interview?

I did not, no.

Their loss. Better luck next time!

I might not have been clear. It's not an act. You are not usually guiding your peer trough your thought process our loud step by step. That's inefficient. Yet that is what you should do to maximize the amount of information passed onto the interviewer. It's just a different setup to which most people need to adjust to.

You just described a CRUD app.

At FAANG, most people are not doing any of these things. Think of people working on EC2, Ads or Maps.

I only worked at multiple FAANG and I never had to design a database schema or make data available via API.

Google publishes many APIs. I know, because we consume them. My company in turn publishes APIs that are consumed by other companies. You're probably right that most people working at FAANG are not allowed to touch a database or set up deployments, however.

As a sibling commenter pointed out, you just described a CRUD app. Web/mobile applications.

It's not hard to do those.

And I suppose for most business cases out there, writing data to the DB and reading it back later is all it takes.

However, there's plenty of other problems where the skillset you mentioned falls short.

For instance, you talked about designing a database schema. Do you know how to design and build a database itself from the ground up? What if that DB has to be distributed, with thousands of writers? How do you ensure consistency and consensus? (These are all solved problems).

Think about Linux kernel developers. Do you think DB schema design is an especially relevant skill for them to have?

Can you come up with a compiler, or your own programming language?

Try building your own text editor, with features like syntax highlighting, undo/redo etc (it takes clever algorithms).

I'm not claiming I can do all of that; just mentioning that the whole scene is much more interesting beyond the horizon.

I once worked on a system that included a SQL-ish interpreter (starting from an ANTLR-based parser and all the way to distributed plan execution). I don't remember discussing it in interviews in the last five years. Even at places such as Dremio or Imply. In all fairness, I _once_ got an offer when one interview in the process included sketching an ANTLR grammar for a calculator in a plain text editor.