Hacker News Reader

Typical FANG employee... Hates whiteboard interviews until they get into FANG, then thinks that anyone outside of FANG is actually delusional about their skills and must whiteboard to prove themselves worthy of handling the incredibly challenging world which is FANG-engineering.

More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...

Why are you so upset that somebody considers themselves smarter than you? Serious question.

Nope, not upset. Just trying to make OP aware of their contradictory behavior.

OP might be smarter than me, who knows. I don't really care, I feel pretty good about my intelligence level even though I know there are plenty of folks smarter than me out there.

What I am is annoyed at the elitism that OP shows. I work at a FANG, have worked at a couple SV unicorns too. There is plenty of work happening here that is not as challenging as OP makes it out to be. I've seen a lot of people with the attitude OP has and I think it makes for a toxic and unwelcoming environment.

As someone who has used complex algorithms research in my work, I agree white boarding has some carryover to some FANG work. But my experience is that there is vastly more boring CRUD work to do and you must generally fight with others to get the interesting/challenging algorithmics work. No need to filter out a ton of qualified people because they can't perform a tiny fraction of the work happening here.

I think your biases have caused you to misread my original comment and attribute to me some beliefs with which you disagree.

> vastly more boring CRUD work

I don't do CRUD work and no one even close to my group does that. Are you a web programmer by chance? We work on systems software. If you've dealt with that I think you might agree that there isn't a lot of grunt work involved. Maybe when it comes to writing some tests but even then it can be fairly technical and require a lot of systems-level knowledge.

FWIW, I'm not saying I'm personally smarter than anyone. I got lucky and got a job working with the smartest, most dedicated and focused people I have ever met in decades of work. They're smart, and working with them requires some combination of extreme personal sacrifice, intense focus, and a deep and wide knowledge of software, hardware, CS theory and language issues.

Interesting that you decided that the OP:

1. Is upset

2. Interpreted the parent comment as being smarter than OP

Serious question: where did you infer these things from?

> Is upset

Nobody is going to write such a rant if they're not upset.

>> Typical FANG employee... Hates whiteboard interviews until they get into FANG, then thinks that anyone outside of FANG is actually delusional about their skills and must whiteboard to prove themselves worthy of handling the incredibly challenging world which is FANG- engineering.

> Interpreted the parent comment as being smarter than OP

>> More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...

???

>but it's not too much to ask to prove that you can think on your feet and solve hard problems if that's what the job is.

Because the most common say to day issue is needing to think of an algorithm on the spot...

You hate it because you know that's not true. Yet you're using it.

Not every day, but my experience is at least every month-quarter. And since you're not primed like in an interview context these ideas need to be inside your wheelhouse to spot them within a business context. I would not describe myself as particularly technical for my org and in the past year I've made use of the following at work:

-Depth first search

-Binary Search

-Topological Sort

-Dynamic programming in a graph context

-Union Find

-Merkle Trees

-Fenwick (binary indexed) trees

Maybe I'm in an unusually technical area but it doesn't feel that way talking to my colleagues.

Yes, and there's plenty of times in my work where I've put algorithms to good use.

But out of all those algorithms how many could you regurgitate onto a whiteboard given 5 minutes to do so?

Knowing the use of each algorithm is good enough. You don't need to know the implementation until you want to use it. And nowhere in your day to day work is this going to be with no internet access or reference.

So why do interviewers suggest this is the case? Why aren't they just happy with you describing how a Merkle Tree can solve a particular issue. Why do you need to write that down?

Should companies set their hiring bar to match the average difficulty of problems they encounter, or should they try to find people who can solve their difficult challenges?

Is your view of programming that good programmers spend the majority of their time writing boilerplate code or doing grunt work?

Your average software developer isn't going to be solving the most difficult problems.

My view isn't that good programmers spend the majority of their time writing boilerplate code. But my view also isn't that the average programmer _isn't_ doing that.

I'd expect way more demonstrated knowledge for an interview in a higher level role than an mid level developer role. But the higher you go the less you actually need to demonstrate that. Why?

> Because the most common say to day issue is needing to think of an algorithm on the spot...

Are you trolling? Everything that you do as an engineer is coming up with an algorithm.

Algorithm is how you solve a problem, how you think about constraints and requirements.

You're being pedantic. You know what I mean.

There's plenty of algorithms I know and I can see relevant business contexts to use them in. Do I know all of their implementations off the top of my head to regurgitate onto a whiteboard? No, because I don't need to. When the time comes I will just look that up. The easy part is the implementation. This isn't a school exam testing your memory.

When was the last time somebody asked you to implement some text book algorithm?

All the FAANG interviews I had were about some leetcode problem where you had to be familiar and use some algorithm, not write it from scratch.

> Sure, I hate it too(on either side of the table), but it's not too much to ask to prove that you can think on your feet and solve hard problems if that's what the job is.

That's a big IF.

> think on your feet and solve hard problems > if that's what the job is. > That's a big IF.

My experience with FAANGS is that their bar is universal. Even if you're going to a team which somehow won't require solving hard problems collaboratively under pressure, ability to do so is the bar for working at the company.

As the person you're replying to says, they use the interview style that gives them signal about this. And in general, unless one work at a FAANG and understands the roles, how does one think they have the correct perspective on how FAANG ought to be hiring for their roles?

so there is no glue code at FAANG? Or you have overqualified folks doing, and getting bored, and jumping ship between FAANG every 1.5 years...

There is a lot of glue code at FAANG, but there are a lot of cutting edge libraries and services that you need to understand before you know how to properly glue them together. That is very different from mostly gluing together well documented standard public libraries.

From an efficiency standpoint, it is probably a lot cheaper to hire smarter users of those libraries than to ensure all new libraries can be used by less smart engineers. Especially since many smart engineers who can write great libraries doesn't necessarily have the ability to document those libraries well, so by removing the need for great documentation they can get a ton of such engineers that other companies with lots of mediocre engineers cannot find a good use for.

There are also a lot of developers working on the internal payroll, HR activity scheduler, communications apps, among others. I still remember an interview when someone was expounding about the wonderful opportunities to work on the site that Google employees use to book yoga classes and other offerings.

That said, I understand that in the interest of fairness and allowing equitable access to the highly lucrative RSUs, it's important to give interviews equally rigorous to candidates for the AdWords team as those who end up pushing protobufs all day.

There is no "this engineer should only touch glue code" and "this engineer should work on the really hard cool stuff". For category A, if something is expected to be extremely tedious drudgery, usually vendors/contractors are used rather than full time employees.

It’s perfect code with 105% test coverage and there are amazing meetings and everyone is as smart as they think they are.

So if I'm understanding your cynicism correctly, the code at FANGs sucks and so the solution is to lower the hiring bar?

Not at all. Just pointing out that a high bar for hiring still leads to shit code. And that's fine, its called growing pains.

Sure there's some of it, but not in my group and it's not something I'd be tasked with hiring for. Occasionally there's some infrastructure related task but I'd prefer someone on the team who actually has to use that stuff be the one to work on it.

We don't have a lot of glue code because we don't glue things together. We write the things other people glue together. That's why this is fundamentally different than 90% of anything I've ever done.

I also don't mean to say that all FANG work is like this. I could see some roles at, say, Google working on Android where it very much would be the kind of gluey work I've done before.

For a long time I am considering anything coming out of F an anti-pattern and an example of bad engineering.

There's glue code, but nobody wants to work with people only capable of doing glue code.

I'm honestly curious to know. Can you say more about what your current work entails?

HPC programming library. It has to be fast, correct, secure and has strong compatibility guarantees so design decisions can have never ending repercussions.

Previous to this job I laughed at the goofy CS questions asked in interviews. "I've been doing this 30 years and never needed A* or a graph algorithm." I have to retract that statement now. Not that the modern coding interview isn't a little overdone, but there is a point to it.

There's also the question of dedication. When you work on a very driven team you have to show a similar level of drive or you're just going to get burnt. I'm not saying the level of work/life balance is fair or the way it should be, but it's the way it is and it has taken me quite a bit to get used to. It's a toxic environment on many levels. That said, it's by far the most impactful job I've ever had. I'm immensely grateful for the opportunity to contribute 0.0000000001 pct to some amazing work.

How did you transition between the previous state you describe and when you found success getting into your current role, in terms of prepping to do that sort of testing, as well as motivation?

I'm very close to 30 now, and have been burnt out enough times that it's a struggle to imagine how I could care about tech enough to attempt to re-transition into almost only caring about sort of climbing that ladder.

I got divorced, lost almost everything, and had to do it or accept living on sustenance net pay for the rest of my life. I really didn't want to do this. I had a cozy gig in my past life, but I couldn't make it on the engineering salary in my town.

I don't come from a CS background. I'm a EE. I just happened to get an embedded job right out of college and kept getting more and more software work. The only algorithms I'd dealt with were linked lists, circular buffers, and synchronization.

Burn out is a constant worry. I still question if my chosen path is even worth it. If I didn't still have hope of having a child someday... I don't know. I don't think I could find the motivation to keep going.

I don't try to climb the ladder. I hit a level I'm more than happy with and now I just need to try to stay on. I find I'm much more compatible with my team because I'm not trying to make the next level. I can share advice freely with the younger folks because I'm not trying to block them. On the contrary, I want my teammates to go far and kick ass.

I'll also add that the first couple of years of my code reviews were a bloody mess. It's frustrating to have people who constantly out-think you and provide better ways of doing nearly everything you come up with. I was lucky to get my foot in the door and then built my skills up even more with a lot of pain and extra hours put it to get things right. I'm a better programmer now than I ever was, but I still have so, so much to learn and practice.

Thanks for your reply. I'm sorry you had to go through that, truly, divorce is a traumatic experience unlike any other, but it does bring some solace to know I'm not the only one who's either been in or is in some sticky situations. Unfortunately I haven't been as lucky in finding something early on to build on. I was about a year and a half into my first position after diploma, and was laid-off, then terminated from my next 3 months in, then again, then again, then again. The only light in that dark being a decent python oriented thing in a research department. Reflecting on that, I might have been in over my head, too cocky as well, with really nothing to base it on other than a passing capability with programming and intense motivation to produce good results. But I was also in the wrong places that I wasn't well-suited for; a constant learning process that has taught me a bit about myself. Looking at the future seems rather bleak, as I'm sure you've felt many times, and I'm pretty much just counting on getting lucky at some point.

I am curious though, what were the more mechanical aspects of how you made that transition? Did you have a plan to practice algorithms in a certain way and then wait till you were contacted by the right recruiter? How did you go about it? Did you more simply just try and do 1 problem a day and then build that up, or did you find useful projects to apply more obscure algorithms to, that might be more interesting and motivating?

Mechanical aspects... I grabbed Cracking the Coding Interview. I started doing online coding tests. I started studying modern C++. I was fortunate that I had a relatively easy, 40 hour day job at the time so the nights and weekends weren't too bad. It took a few months. I interviewed with Amazon and it opened my eyes to how much I didn't know(Also, I am so incredibly glad I didn't get that job). I kept studying. I kept interviewing. I tried to think of things I would be expected to know. As an older engineer with a lot of Linux driver experience I had to refresh my knowledge of the Linux kernel's various subsystems. It was a lot of work. It helped that I've been at this game a few decades though so it wasn't like this stuff was exactly new. The algorithm stuff was, but I'd done a fair amount of Linux stuff, C++(but C++ pre 11), lots of C and Python... I wish I could say I still remember a lot of what I learned.

As far as interviews go, I think I tend to interview pretty well when it comes to social skills. Problem solving is tough. I had to do a lot of whiteboard practicing. I probably over practiced this part because, in my experience, you're not really writing tons of code on the whiteboard. Yes, you need to write some, but it's typically short snippets or pseudocode.

I remember telling my interviewers that I didn't think I was a good fit for the job. It seemed more 'CS' than I could handle. I don't know why they went with me. I know the company was rapidly growing at the time so I probably just got lucky. Not what you want to hear, I know.

Thank you! That is a very interesting world indeed.

But, just focusing on the algorithms part of it, I never could answer how exactly a specific algorithm worked, but I've had to use many algorithms in my "normal" job. I just know "oh this needs a modified DFS, or A*, with custom heuristics, or a priority based permutations generator". I cannot answer how any of this works in detail on the fly, but I know where to look. Isn't that sufficient? I certainly would fail a FANG interview, but have gone toe to toe or even better when pow-wowing on some real problems with googlers. Wouldn't consider myself any inferior because I don't know how a specific algorithm works in the interview. Just my two cents

Is it sufficient? Depends on your interviewer and other factors. I personally wouldn't fail anyone for not knowing absolute specifics(unless they claimed to know as much). I would expect some 'algorithmic thinking' and basic familiarity. The interview is also based on a fair bit of luck. In my case, I was asked about virtual memory, and I had literally just days before done a deep dive through the Linux VM subsystem. If they asked me a week before I wouldn't have gotten the job.

When I started interviewing, I couldn't even do tree traversal. It just wasn't something I was familiar with, and never directly used in decades of coding. I don't blame Amazon for passing on me then.

> gone toe to toe or even better when pow-wowing on some real problems with googlers

I don't think making blanket statements like this is a good idea. Sure, you might be able to code better then them, but can you think of a new solution which is better than the current best practice based on some practical consideration(behavior of your HW, caching behavior, some niche use case, etc)? I think a lot of people are great coders in many ways but that's not always the skill folks are looking for. We don't necessarily crank out a lot of code, but it has to be really good code. You also are expected to come up with self-driven innovations and ways to push the industry forward. It would be nice if there was just a set of problems someone handed me and had me solve, but that's really not what they're paying me for.

That's fair. I think we are saying the same thing, it is just about what you know at that moment, rather than your true capabilities.

Also, my statement was not blanket statement, nor that I wrote more code than others. I was referring to a very specific set of problems that I was working on and not generalizing that I'm better than all googlers. There are many people who are way smarter/better than I am. I'm just saying not being in FAANG does not mean one is not good enough.

I think the interview processes put a bar on if one willing to put in the amount of specific kind of work needed to get in or not. In its own way, it is a good filter (for them)

Mostly reversing binary trees obviously