I've just interviewed for Google and Meta. In total I went through 8 individual coding interviews.
With an exception of one, which was a bit too much like a puzzle, I think the assignments were completely fair examples of what I might experience on daily basis. Not at all tailored to people doing competition style programming, which was what I expected after being exposed to HN for years.
I have to say I enjoyed both preparing for the interview as well as the interviews themselves. And I believe that overall the interviewers were able to grasp how I would code.
If you have to prepare for the interview, doesn't that suggest the assessment isn't representative of day-to-day programming skills? In fact, it suggests the exact opposite.
With zero preparation, I could go to an interview with you right now and tell you anything you wanted to know about designing a database schema, how to get any kind of data out of that schema, how to make that data available via an API, how to cache the data and perform permissions checks, how to deploy code to a cloud environment, how to set up a build pipeline, or any other question you might want to ask about the day-to-day process of developing and deploying web applications. I can answer those questions because I already work in the industry and I broadly know what I'm doing.
However, I probably couldn't pass a FAANG interview without months of prep work, precisely because whiteboard interviews bear almost no resemblance to the reality of software development.
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.
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.
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.
As someone who has done the interview rounds at FAANG and many dozens of other companies in SV - you either work in algorithmic work or got lucky with your questions.
The questions that are asked have little to no basis in my daily work as an engineer. Same is true for the hundreds of other engineers I’ve worked with who have gone through the same hoops that I have.
> I think the assignments were completely fair examples of what I might experience on daily basis.
In my experience, you have a lot more than an hour to do it in the real job. And while perhaps 1% of SW folks will deal with in on a daily basis, most will not. I certainly have gone years without needing to use graph algorithms (including even DFS/BFS). And I've needed a BST only once in a decade - and I didn't need to code it, just needed to understand the data structure and complexity to know that "binary_search" in C++ was a superior option than using a map for my use case (even though the complexity is the same).
Some context: At work I recently solved a problem where I had to build a graph (DAG), and do some queries on it mildly efficiently[1]. I did it quickly thanks to wasting time on Leetcode, but no one knew how quick, and people were impressed that I "got it done in less than a day". The reality in most SW work is that whether it takes you a day or an hour to solve this problem, the overall rate of progress will not be impacted.
[1] Mildly efficiently because for the first POC pass, I didn't memoize, and then I got lazy and decided I'd optimize it only after getting a real world data set and seeing if it was slow. It wasn't, even for a decently large data set. The reason? Business logic dictated that the max distance between two nodes did not exceed 8, so from a complexity stand point, you're not increasing the work N-fold by not memoizing, but it's just changing the constant factor.
Somehow, I suspect that in half of the FAANG interviews, had I coded this and argued that the complexity didn't change, I would not get a pass.[2]
[2] Not trying to be cynical: I did argue this for a different problem in a Google phone screen - I had been asked to write some code + data structures to handle an Manager/Report relationship, and the interviewer pointed out my data structure was less than optimal. I countered with "In most companies, the number of employees a manager has under him/her is usually bounded by a small number." Surprisingly, the interviewer gave in.
But, I don't think those are vultures. They are bald eagles. I'm not sure if owls scavenge, but I do know they primarily hunt. Eagles both hunt and scavenge. Vultures primarily scavenge.
Yeah. I might be generalizing a bit, even though I made sure to emphasize that it is my isolated experience.
On the other hand I felt like a sample of 8 different interviewers from different offices and backgrounds felt representative. If it is true that the interviews are overwhelmingly negatively received, what is the probability that I would get more than half of reasonable interviews? Let alone 7/8.
You're overlooking the fact that you're just one person. Each one of us reacts differently under such conditions and only a minority (which is likely small) happen to excel at this.
The interactions and power dynamics between people differ wildly from person to person. While an interviewer might be the kindest person in the world for candidate A, they might be a total bully for candidate B. I was bullied constantly throughout school snd, whatever cues prompted those kids to pick on me are probably still there, but adults are a bit more subtle, because they can hurt you in other ways. And this is on top of the day-to-day variations, because they might be hungry and the current interview is sitting between them and lunch or maybe they just got slapped down by their boss and want to punch someone or whatever. Based on my own experience, out of the typical 5 rounds of in-person interviews that I went through many times for FAANG companies, one or two ended up being a total shitshow each time, where the interviewer was condescending at best and I don't think they realised it or cared. I was told several times "how easy / trivial" the problem is and that "they're sure I'll have an easy time solving it based on my CV". Maybe the worst ones are when the interviewer smirks at me when they spot dome issue and I can't cope with that.
Now add to this a long streak of never ever getting an offer after dozens of such interviews in spite of putting myself through training sessions and mock interviews over and over. I'm sure I'd get in eventually, if I just kept trying, but do I want a job where I'll be asked to interview people in a similar manner? Even if I refuse to interview people as part of my job, will I really thrive in there? I'm certain this process permeates in one form or another throughout the company culture in various internal management, decisionmaking and promotion processes, but that's a separate discussion.
> Even if I refuse to interview people as part of my job, will I really thrive in there? I'm certain this process permeates in one form or another throughout the company culture in various internal management, decisionmaking and promotion processes, but that's a separate discussion.
Are you sure you want to work at a FAANG company? You sure you would be happy? What motivates you to try so hard?
Bingo! I now know I don't, but it took me years to come to this conclusion. When I started this career, everyone around was telling me that getting into one of these companies will lead to meaningful and challenging work which is complete nonsense. I now know that a large number of people who join these companies are unable to find any meaningful work there.
Anyhow, several years ago, I added a disclaimer to my public profile on LinkedIn which states that I refuse any form of live / timed coding assessments during interviews and I'm not going to make any exceptions on it.
The interview results need to be reasonably repeatable and comparable to assess interviewer skew and bias.
The result is that the interviews themselves inevitably end up being somewhat predicable. And what is predicable you can prepare for, giving you predictably better results.
If you are top 0.1%, sure you will nail them without much prep, but most of the candidates would spend some time preparing.
You mentioned that it is not about Competitive Programming/leetcode stuff but a daily real world work. So how do you prepare? Just continue doing your daily work?
You prepare by making sure all your bases are covered. In my daily work discussions, for example, I tend to be very hand-wavy about concurrency, calling everything “locks” and hoping people understand that I can dig down into the details when needed. When I’m interviewing I don’t want to just hope, so I review my concurrency primitives to try and make sure I won’t put my foot in my mouth.
With an exception of one, which was a bit too much like a puzzle, I think the assignments were completely fair examples of what I might experience on daily basis. Not at all tailored to people doing competition style programming, which was what I expected after being exposed to HN for years.
I have to say I enjoyed both preparing for the interview as well as the interviews themselves. And I believe that overall the interviewers were able to grasp how I would code.