Hacker News new | past | comments | ask | show | jobs | submit login

What were the words they used to decline proceeding? Do you happen to remember?



This was years ago, so my memory is fuzzy on this - not sure how much I really heard after I knew I was being told no :)

There was a decision point about halfway through the day (after being grilled by engineers) where I was going to be either cut loose or sent on to interview with more senior level people and/or HR.

"How do you think you did?"

"Eh... ok, I think. I was struggling on the data structures."

"Yes, that's what I'm hearing from $ENGINEER. There are reasons for this - maybe you are out of practice, it's been a while since college, or you don't use this knowledge in your daily work. But we do deal with this stuff at Netflix, so for this reason we're not going to move forward at this time."

I was interviewing for a position doing Scala (at that point in my career, I was doing some Scala work, and it was still a fairly new and hard skill to find). The person giving me the bad news was a Lead Engineer and a proponent of Scala, seemed a bit disappointed that I knew Scala but got tripped up by low-level implementation details of some data structure (Naturally, the solution came to me later on the plane ride home). I actually had studied for this interview - but I had studied the wrong things (I was focusing on Scala-specific knowledge, but they really grilled me on fundamentals).


Here's the thing: "But we do deal with this stuff at Netflix," is still only true for a tiny fraction of the engineers at Netflix. I currently work at a company that is not quite FAANG scale, but almost is: we have issues in our platform and systems that have forced us to adopt "FAANG-like" solutions to certain issues of scale. Almost none of the engineers at this company are doing anything at all with interview-style algorithms and data structures questions. There are a few working in a couple of areas, but for the most part engineers are working on protobuf specs and implementations around them, front-end/other client code, etc. I'd estimate less than 5% of the engineers here even touch the internals of algorithms and data structures ever, and maybe 10% of them deal with them anything close to "regularly."

The specific team you were being interviewed for might have this apply, but the claim that "Netfix" (as a whole) deals with these issues regularly is almost certainly an exaggeration (at best).

These interview questions generate poor signals and are best seen as hazing ritual/ego stroking exercises.


But the 5% ~ 10% that do are at least guaranteed to be capable of it.

And it's likely that that matters.


Capable of it or capable of learning it when it's needed? I had to brush up on linear algebra for some problems at work about 2 years ago. I solved the problem, documented everything properly, and the code has been running unchanged and without issue ever since. In the time between then and now I've definitely lost that knowledge _yet again_.


Sure, but it doesn’t matter enough that interviews should be built around this domain, especially to the extent they are around the Bay Area.

Having 0.5% of all engineers regularly engaged in working with the implementation details of data structures and algorithms does not justify putting 100% of engineering candidates through interviews centered on that topic.


Thanks, man. I appreciate your sharing this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: