SWE interviews (at FAANGs at least) don’t care about library specifics though. As long as you know the syntax and how to write algos/data structures, you can make it through.
There is a strong argument that being good at that isn’t required for most SWEs (including at FAANG), but it is something that having library/framework references doesn’t really help with.
> There is a strong argument that being good at that isn't required for most SWEs (including at FAANG)
Algos/data structures are used as a proxy for problem solving and how fast someone can learn. Plus every decent CS program will have a few courses on it.
Also, internal codebases are, well, internal. You won't get a nicely formatted Stack Overflow response on how X works if X is deep in the Google Source tree.
> Algos/data structures are used as a proxy for problem solving and how fast someone can learn.
Problem solving, yes. How fast someone can learn, absolutely not. If you've never heard of dynamic programming there's absolutely no way you're going to come up with that in an hour. If you've never heard of binary trees you aren't going to think that one up in an interview. (Of course, you should already know basic data structures, but my point is a lot of these things aren't something you'll come up with if you haven't heard of them before.)
I had a FAANG interview question applying statistics to a unbounded input. It took me a while to understand what the question was really asking, followed by some shock because it was something I'd never even imagined before (since I haven't needed to do much statistics in my line of work) and I didn't have the faintest idea where to start. With some hand-holding I figured out some basics, but I'm pretty sure that interview was part of the reason that "the hire signal was not strong enough". Now, let me take a walk for 15 or 30 minutes to consider solutions to something I've never imagined, and I'll probably come up with a reasonable solution on my own, and also be able to extend it for the rest of the interview. That might measure my ability to learn. But expect me to solve it in five minutes so we can go on to the deeper questions? Yeah, not really. So this interview didn't measure my ability to learn, it measured what happens when you give me something I've never imagined before and expect a solution in five minutes.
(What's a little frustrating is that I'm not really sure how to expose myself to the problems I've never imagined but which FAANG interviewers are likely to ask. I'm not sure that leetcode would do it, although obviously it'd be a place to start.)
> If you've never heard of dynamic programming there's absolutely no way you're going to come up with that in an hour.
Dynamic programming problems are really terrible for interview signal though.
Firstly, it's mostly an aha moment or two trying to realize the relationship between the elements. Not really lots of signal there.
Secondly, the code is trivial in 99% of cases. Just set up an initial (likely multidimensional) array, some for loops to iterate in the right order and then apply the formula. Returning the right array element at the end.
Also terrible signal, since the initial fizzbuzz question during phone screens or whatever should've caught an inability to code.
That said, yeah, the algorithms bit of interviews are the bits that are scary to me, since they're the biggest dice rolls. Everything else just has normal levels of unexpected events that you learn to deal with during your job. However, I write proper algorithms once or twice year and, even then, just trivial ones.
I've coined a term for these FANGA interviews: Epiphany Lottery.
You need to come up with the correct answer in less than 2 minutes, twice, within 45 minutes. Because it runs twice, you will only have 15 minutes to write up the code to handle all the edge cases your solution can't cover for. There is simply no time, nor expectation, for the candidate to reason about a problem and actually work out a solution.
Fwiw... My go-to interview question has about four hard spots where people get stuck. I don't really care so much where you get stuck, so much as that you demonstrate good thinking and deploy strategies for getting unstuck once you hit your limit, wherever it might be. And, yeah, points are given for actually getting unstuck.
Strategies I want to see are along the lines of 'draw a picture' or 'work a small example, carefully, in full detail.' People who do these kinds of things /usually/ solve the 'hard part' they got to, and I give them a good review, wherever that was. People who don't manage to get unstuck tend to either a) not use simple problem solving strategies and/or b) get overly attached to an initial wrong idea.
(and I totally agree: taking a walk is totally a valid problem solving strategy, though it isn't easy to incorporate into a time boxed interview...)
Are you explaining this to the interviewee. Otherwise it's a guessing game for what you want and creates unnecessary stress. If you planning to put people on-call (working under stress and time constraint) on their first day(no prior knowledge of the problem they may encounter) then its fine.
While I'm a decent programer, I perform terrible under these situations. When I get stuck I need to take two steps back (go for a walk, explain it to a coworker/rubber duck).
> Of course, you should already know basic data structures
That's partly what the whiteboards are screening for. Any decent CS program should teach them.
> I had a FAANG interview question applying statistics to a unbounded input. It took me a while to understand what the question was really asking, followed by some shock because it was something I'd never even imagined before (since I haven't needed to do much statistics in my line of work) and I didn't have the faintest idea where to start. With some hand-holding I figured out some basics, but I'm pretty sure that interview was part of the reason that "the hire signal was not strong enough".
Yeah, if you are asking something weird (as an interviewer) you should be expected to explain it.
It sounds to me you had the right approach (figuring out what the problem is and getting help from the interviewer). Ultimately, it's completely possible you simply stumbled upon a bad interviewer who assumed his specialty question was well known.
> What's a little frustrating is that I'm not really sure how to expose myself to the problems I've never imagined but which FAANG interviewers are likely to ask
> Algos/data structures are used as a proxy for problem solving and how fast someone can learn.
A piss poor one if you ask me. The truth is that it’s a skill where you need to internalize what various low level data structures buy you to know when to reach for them.
Most of the code I saw at Google was boring ass proto transforms based on business logic. Knowing when to use a map vs an array was about as complex as it got for 95% of the positions.
Additionally, knowing the algorithms/ds (as all Googlers are supposed to) did not help for that normal work. A bunch of folks I worked with in the open source world produced better structured, better tested, and more performant code than many of the internal folks but they couldn’t join Google because of the algo/ds bar.
There is a strong argument that being good at that isn’t required for most SWEs (including at FAANG), but it is something that having library/framework references doesn’t really help with.