Working at Netflix(brendangregg.com)
brendangregg.com
Working at Netflix
http://www.brendangregg.com/blog/2015-01-20/working-at-netflix.html
288 コメント
I also met with this same woman who talked about both the stock price and firing people. She also said something to the effect of "just because you have a job now doesn't mean you will have one in six months" and made a comparison to players being traded in professional sports. I remember feeling very put off by her. I too did not understand what the point in this bit of bravado was. It sounds like it's her standard candidate speech though which is just weird. The other thing that put me out was the first person who interviewed wasn't wearing shoes and insisted on sitting indian style with his feet pointed out to wards me. I am no stranger to a casual work environment but that is just gross. Lastly on the way to a conference room on the second floor I walked a fair amount through the office and what was notable to me was that I didn't see anybody smiling or even anyone who looked like they might be enjoying what they are doing. Ultimately I didn't get an offer because the job turned out to be a different description than the one I had interviewed about on the phone. I think that says it all.
> Lastly on the way to a conference room on the second floor I walked a fair amount through the office and what was notable to me was that I didn't see anybody smiling or even anyone who looked like they might be enjoying what they are doing
Please don't ever make this assumption. I referred an acquaintance from school to my workplace (he was a great project partner, and I was the first of us to get hired after graduation, so why not?), and apparently when he passed through everyone was just... doing work. That was a telltale sign that everyone was grumpy to him.
I had to explain that we basically don't work at all on Friday afternoons because we're too busy drinking, we play pingpong religiously, frequent out of office events on the weekends, and in general it's just an enjoyable crowd. Random conversations happen all the time.
But nope, that one time he came through the office, everyone looked unhappy. Because they were working, I guess.
Please don't ever make this assumption. I referred an acquaintance from school to my workplace (he was a great project partner, and I was the first of us to get hired after graduation, so why not?), and apparently when he passed through everyone was just... doing work. That was a telltale sign that everyone was grumpy to him.
I had to explain that we basically don't work at all on Friday afternoons because we're too busy drinking, we play pingpong religiously, frequent out of office events on the weekends, and in general it's just an enjoyable crowd. Random conversations happen all the time.
But nope, that one time he came through the office, everyone looked unhappy. Because they were working, I guess.
[...] frequent out of office events on the weekends [...]
That sounds ... very strange. Weekends aren't generally speaking "office hours", and more importantly also not "working hours". Having an "out of office event" in my world is when you're doing work, i.e. it's during normal working hours, but you're not at work.
Having frequent work-related "events" on weekends sounds like a total bummer.
That sounds ... very strange. Weekends aren't generally speaking "office hours", and more importantly also not "working hours". Having an "out of office event" in my world is when you're doing work, i.e. it's during normal working hours, but you're not at work.
Having frequent work-related "events" on weekends sounds like a total bummer.
Depending on the work culture, out of hours event is a minefield. At the very least, you should have an opt-out possibility and not looked down upon if you do opted-out.
Totally voluntary. Work just pays for them. A number of people opt out and no one judges them.
I had to explain that we basically don't work at all on Friday afternoons because we're too busy drinking,
This also sounds like a major bummer -- aside from the fact that does smacks (way too heavily) of bro culture, it's incredibly off-putting to anyone who doesn't drink (or who does, but thinks drinking in the office -- or drinking heavily in the afternoon on any kind of a regular basis -- is basically pretty stupid).
This also sounds like a major bummer -- aside from the fact that does smacks (way too heavily) of bro culture, it's incredibly off-putting to anyone who doesn't drink (or who does, but thinks drinking in the office -- or drinking heavily in the afternoon on any kind of a regular basis -- is basically pretty stupid).
If people are either happy or working then that's actually a problem. You don't apply to a company to spend Friday afternoon drinking beer, but to work, right?
The point is that it's not either/or. People who are working can be mistaken for people who are unhappy, simply because they're busy. It's an assumption that should be avoided.
First of all don't tell people what the should or shouldn't think. Not only is it condescending but its ridiculous. Also this wasn't an assumption it was an observation. This wasn't people with their head down working, this was eye contact I made with many people in different states of being at work and none of them could muster a friendly smile. That's completely different.
> First of all don't tell people what the should or shouldn't think.
But it's okay to tell them what to do?
But it's okay to tell them what to do?
I scowl fiercely and curse a blue streak when I'm coding. Doesn't mean I'm not having fun :-)
Not only gross, but wildly disrespectful in many cultures.
Anything can be wildly disrespectful in some culture
Being that its Netflix whose office is in California, it is American work culture we are talking about so yes this is considered disrespectful.
I find the "standard (American) work culture" wildly disrespectful. I mean, expecting people to wear standardized clothes and having them clock in and out? Are we in prison?
>I mean, expecting people to wear standardized clothes and having them clock in and out? Are we in prison?
Um, neither of those are true in any companies I worked at in the US except for a job in high school as a cash register attendee.
Um, neither of those are true in any companies I worked at in the US except for a job in high school as a cash register attendee.
Work culture varies hugely from company to company. If that's considered ok at Netflix that's their choice, if the the guy doesn't like it just don't work there.
There are a finite set of cultures. "Can be" isn't a particularly productive claim.
I would argue that Netflix has it's own culture, a company culture. Perhaps if the commenter was really put off by this he would not be a good fit and it would not work out for either of them. I know there are a lot of protected characteristics you can't use to make hiring decisions but this does not seem like one of them - seems like Netflix hires form all sorts of cultures and only people who are not offended by other cultures choices.
The owner of the company I work for rarely wears anything besides flip flops and his feet are kind of gross. But who cares? It doesn't impede our ability to build cool stuff, make money and have plenty of fun. It sounds like you might be just as stuffy if not more so than the people you observed on your walk through Netflix.
I would have quite enjoyed the opportunity to try a recommended interview tactic here: "Mimicing the interviewers body language".
I have a question about your choice of words re the person who insisted on sitting with their feet towards you.
Did you suggest that you would feel more comfortable if they sat differently?
This doesn't make any difference for me personally but I understand why some people would prefer that the person not sit like that. However, if you did not express an objection with regards to how that made you feel, I don't think "insisted" is a fair choice of words there.
Did you suggest that you would feel more comfortable if they sat differently?
This doesn't make any difference for me personally but I understand why some people would prefer that the person not sit like that. However, if you did not express an objection with regards to how that made you feel, I don't think "insisted" is a fair choice of words there.
One of the meanings of "insist" is "persist in (doing something)". That's presumably the meaning intended by grandparent.
A common usage for "insisted" (in American English, at least) is "did so with no apparent consideration of the effect," in a generally passive-aggressive context.
"He insisted on chewing with his mouth open, I mean, ew. Gross."
The offender is generally expected to read non-verbal, and often non-expressed, communication of the offended's opinion.
"He insisted on chewing with his mouth open, I mean, ew. Gross."
The offender is generally expected to read non-verbal, and often non-expressed, communication of the offended's opinion.
Maybe that in itself was a test to see of people had personality or just put up with anything without much protest.
If so, seems like kind of a BS test to me. Job interviews are stressful enough without that kind of social experiment nonsense. There are a set of expected behaviors in an interview that don't necessarily reflect how a person would act in day to day life.
True. But all kinds of people play little power games. They know you probably won't say anything, unless you don't care and call out the emperor. Tough to say though, but someone selfaware should know this projects some kind of power 'play' and would avoid that manner.
Your suggestion that this is my fault for not objecting to the way my interviewer chose to conduct themselves in a professional setting is a joke. You must either work for them or be the person who was crass enough to behave like that. As another commenter said, that is a correct use of the word "insist." Look it up.
There is no talk of blame or fault. All the poster is doing is presenting an opportunity that you could have taken, and hopefully you may attempt if a future situation occurs, that could have improved your experience. People cannot see inside your head and that is why we communicate
The person conducting an interview is in a position of power. The interviewee shouldn't have to ask him to stop behaving inappropriately. It's the same reason prison guards get arrested for consensual sex with inmates.
Same experience with that chief talent officer. I think it was supposed to be a pure sell interview, but it ended up being super tacky and uncomfortable. She went on and on about how much money they had. She went on and on about firing 51% of the people every year - which is not only unsustainable, but not supported by any kind of evidence of routinely culled NF engineers looking for work in the Bay Area. She was so busy congratulating herself and being smug I don't even know why I was in the room. The rest of the interviewers were great.
In the following days, they followed up with an offer that wasn't an offer - they would make an offer only if I said yes, but otherwise they weren't going to make an offer. They had the hiring manager call me a bunch of times. They tried to get me on a sell call with the ceo. They disparaged the other companies I was talking to. Meh. Also, they were title crazy - everyone in management I spoke to was either a director or a vice-president or a chief of something.
"She went on and on about firing 51% of the people every year"
Wait, what? Slow down a sec and elaborate more about this please
Wait, what? Slow down a sec and elaborate more about this please
Netflix models employment like a professional sports engagement, where performance is regularly reviewed in context and persons who no longer contribute to the "team dynamic" are "traded", i.e., fired, to go find a "team" in which their contributions are a better fit.
Everyone knows this because Netflix released a big presentation about it a while ago. They keep "top performers" only as long as they are top performance from Netflix's perspective, and then dismiss them with a "generous severance".
It's definitely an interesting way to do employment.
Everyone knows this because Netflix released a big presentation about it a while ago. They keep "top performers" only as long as they are top performance from Netflix's perspective, and then dismiss them with a "generous severance".
It's definitely an interesting way to do employment.
Sounds like contractors. Why not just admit it and fire everybody?
I agree that it sounds like contracting. They're trying to normalize it, I think. Most people won't be contractors because contractors have to pay extra taxes, buy their own benefits, and have no job security. Netflix takes care of these first two and makes the last one softer by giving a "generous severance" while the ex-employee finds a new home (I'm not sure on the specifics of how that works; maybe a NF employee who has been "traded" can offer detail (though he's probably contractually forbidden from doing so)).
yes but 51%? that's a ridiculous number.
Netflix has a history of trimming unneeded employees as soon as they are deemed unneeded.
Just a random addition. Someone in this thread posited that this was "Patty" as mentioned in this blog post I read today.
http://consultingadultblog.blogspot.com/2010/10/unreasonable...
I just thought it was incredibly interesting how a person can be so polarizing. This person acts like she walks on water!
http://consultingadultblog.blogspot.com/2010/10/unreasonable...
I just thought it was incredibly interesting how a person can be so polarizing. This person acts like she walks on water!
[deleted]
This person's actual ID needs to be called out! if not on HN - make anon reviews on Glassdoor with the actual name of this person.
Please don't start a witch hunt on the basis of a handful internet comments. We should be better than that.
Not necessary, because this person and her views are quite well known: http://firstround.com/article/The-woman-behind-the-Netflix-C...
What's basically clear is that the candidates complaining here a) didn't do their basic f-ing homework, and b) are seriously misrepresenting Netflix views on letting people go.
Not I agree with that part of Netflix culture (and it would pretty much be illegal in most Western countries), but there is a clear logic behind it, and I seriously doubt they skipped that part in the interview.
What's basically clear is that the candidates complaining here a) didn't do their basic f-ing homework, and b) are seriously misrepresenting Netflix views on letting people go.
Not I agree with that part of Netflix culture (and it would pretty much be illegal in most Western countries), but there is a clear logic behind it, and I seriously doubt they skipped that part in the interview.
What's basically clear is that the candidates complaining here (...) are seriously misrepresenting Netflix views on letting people go.
You can assume the posters here are being malicious, or that they're honestly telling what they understood from the interview. If the latter, then I'd argue it's Netflix fault for failing to leave the right impression.
You can assume the posters here are being malicious, or that they're honestly telling what they understood from the interview. If the latter, then I'd argue it's Netflix fault for failing to leave the right impression.
How is it a witch hunt? Labor is supposed to be a market, no?
Naming the person opens them up to personal harassment (which happens way more than people think).
Potential employees don't need to know her name to make an informed decision about whether or not apply to Netflix.
Potential employees don't need to know her name to make an informed decision about whether or not apply to Netflix.
They can make an informed decision about whether to bother showing up to the interview if they find themselves scheduled with her.
Wow, I had nearly the exact same interview process. Super aggressive to nearly combative recruiter (felt like I was being argued with the whole time), fizzbuzz question, left in a conference room alone for an hour for lunch, a few more questions then done.
I got an offer but turned them down because their recruiter was so crazy aggressive it made me feel that Netflix would be a very unhappy place to work.
From what I've heard from ex-employees (one a recruiter) the hiring/salary/firing process there is not well organized. People often make more than managers or more senior employees and large layoffs every year for the 'bottom 10%' make for some weird social dynamics.
As much as I respect and admire their technical processes there I'm not convinced it's really a good place to work.
I got an offer but turned them down because their recruiter was so crazy aggressive it made me feel that Netflix would be a very unhappy place to work.
From what I've heard from ex-employees (one a recruiter) the hiring/salary/firing process there is not well organized. People often make more than managers or more senior employees and large layoffs every year for the 'bottom 10%' make for some weird social dynamics.
As much as I respect and admire their technical processes there I'm not convinced it's really a good place to work.
Can you share the name of the recruiter? Just curious if that person is still working at Netflix.
I've been a happy Netflix employee for over 4 years and have never experienced a 'large layoff' event. All the layoffs I've witnessed were not a surprise for the people affected.
Senior engineers usually make more money than their direct managers, but I fail to see how that's an issue.
I'm guessing RayVR met with Patty who left Netflix 2 years ago. My interview with her was different but I guess it would depend on your background and what she was trying to determine. In my case it was mostly to see if I was going to be a good cultural fit since I was at the time working for Yahoo which had a completely different culture. To me that was an entirely reasonable thing to do. Actually the whole interview process was great, and it was one of the major reasons I chose Netflix over other companies.
I've been a happy Netflix employee for over 4 years and have never experienced a 'large layoff' event. All the layoffs I've witnessed were not a surprise for the people affected.
Senior engineers usually make more money than their direct managers, but I fail to see how that's an issue.
I'm guessing RayVR met with Patty who left Netflix 2 years ago. My interview with her was different but I guess it would depend on your background and what she was trying to determine. In my case it was mostly to see if I was going to be a good cultural fit since I was at the time working for Yahoo which had a completely different culture. To me that was an entirely reasonable thing to do. Actually the whole interview process was great, and it was one of the major reasons I chose Netflix over other companies.
I'm dmuino's manager.
The day after I took over the team, my director sat me down and said "I don't know if you've looked yet, but most of your engineers make more than you do. That's because they're incredibly valuable. Your number one job is to keep them happy."
In the last two years of managing this team, I've consistently gotten paid less than the top engineers on my team.
Totally OK with it.
The day after I took over the team, my director sat me down and said "I don't know if you've looked yet, but most of your engineers make more than you do. That's because they're incredibly valuable. Your number one job is to keep them happy."
In the last two years of managing this team, I've consistently gotten paid less than the top engineers on my team.
Totally OK with it.
By far the best part of being a self-employed contractor is never to have to deal with HR, ever. Ever never.
Also remember that HR are not your friends, they don't work for you, they don't understand your job, or you as a person; they work for the company; their job is to:
- make sure the company doesn't overpay for "resources" (a "talent buyer" if you will)
- make sure said resources, once hired, stay in line and don't make waves of any kind, and terminate them as needed, as silently as possible.
We tend to think of HR as an adult version of the nice and benevolent elementary school teacher who first helped us understand the world; the reality is they are more like cops. Bad cops usually.
Also remember that HR are not your friends, they don't work for you, they don't understand your job, or you as a person; they work for the company; their job is to:
- make sure the company doesn't overpay for "resources" (a "talent buyer" if you will)
- make sure said resources, once hired, stay in line and don't make waves of any kind, and terminate them as needed, as silently as possible.
We tend to think of HR as an adult version of the nice and benevolent elementary school teacher who first helped us understand the world; the reality is they are more like cops. Bad cops usually.
> Also remember that HR are not your friends, they don't work for you, they don't understand your job, or you as a person; they work for the company; their job is to:
This part is so important. Our HR department doesn't actually know anyone in the office. It becomes particularly interesting when they organize a company outing and have completely missed that there is a large percent of the workforce that does not speak the native language where I live, but they still have event hosts that will only present things in this language. They've done this 3 years in a row now.
This part is so important. Our HR department doesn't actually know anyone in the office. It becomes particularly interesting when they organize a company outing and have completely missed that there is a large percent of the workforce that does not speak the native language where I live, but they still have event hosts that will only present things in this language. They've done this 3 years in a row now.
I had a boss that was extremely good to work for, but she didn't have management experience (given the nature of the organization, this would be expected), so she leaned on outsourced HR for advice. Not only did their advice lead to me leaving much less amicably than had been (mutually, I thought) planned, but they also opened themselves up to liability that wouldn't have been there otherwise.
The "bad cop" analogy is spot-on. I've used that exact analogy—my boss (unwittingly) played "good cop", while the HR consultants played "bad cop".
The "bad cop" analogy is spot-on. I've used that exact analogy—my boss (unwittingly) played "good cop", while the HR consultants played "bad cop".
amen. there are downsides to the chaos of consulting that i don't particularly enjoy but the only time i ever spoke to HR was when they handed me my badge, and there is no such thing as a "performance review", reprimands, etc. (lots of annoying memos about corporate policies at this particular client tho). In fact, I talk to my real "boss" about once every few months, in between it is just scrums with PMs
I pretty much just go to work, chill out, and hope I can find a better gig sometime in the near future (I'm on basically an ever-renewing contract but the vendors in our system are horrible about rate increase).
I pretty much just go to work, chill out, and hope I can find a better gig sometime in the near future (I'm on basically an ever-renewing contract but the vendors in our system are horrible about rate increase).
Just a side note that the chief talent officer I met with is no longer at the company.
lol, the irony. guess she was part of that 51%!
Probably not in her list of "favorite firing" stories.
she fired herself early in the history of Netflix due to lack of money. CEO decided to keep her on part time.
It sucks when you can tell that a personality mismatch is causing the interviewer think you don't know what you're talking about. Or they could just be an arrogant ass, who knows (that if/else thing certainly raises the possibility).
About the offer you got, maybe they thought you were strong in areas that would be important to the DW team even though you didn't fit into their expectations for the position you interviewed for. I've interviewed people who were obviously talented engineers but not quite right for the position in question, and suggested them for other positions they were better-suited for. This has worked well in my experience, but who knows if that's what happened at Netflix.
About the offer you got, maybe they thought you were strong in areas that would be important to the DW team even though you didn't fit into their expectations for the position you interviewed for. I've interviewed people who were obviously talented engineers but not quite right for the position in question, and suggested them for other positions they were better-suited for. This has worked well in my experience, but who knows if that's what happened at Netflix.
The official story told often at big companies is that the interview process should be tilted towards false negatives over false positives.
The truth of the matter is you could probably get statistically similar results from a voodoo witch doctor reading chicken entrails.
Ok, maybe not, but I really get the feeling that most hiring systems are arbitrary and are less "tilted toward false negatives" and more just plain random. In the cases such as Google, they also tend to create a monoculture which probably feels right at the moment but I think really hurts the company in the long term.
The truth of the matter is you could probably get statistically similar results from a voodoo witch doctor reading chicken entrails.
Ok, maybe not, but I really get the feeling that most hiring systems are arbitrary and are less "tilted toward false negatives" and more just plain random. In the cases such as Google, they also tend to create a monoculture which probably feels right at the moment but I think really hurts the company in the long term.
I think these processes are like that Price is Right game Plinko. You're the round little disk and the interviewers are the pegs.
There are thousands of pegs on the board, and your resume predicts the starting position of your disk.
But once you hit the pegs, it's essentially random. Some pegs bounce you towards the jackpot and other pegs bounce you towards 0.
It all depends on if you have a similar background, if the person likes you, if you've heard of the question before or solved something similar, if your chosen language fits the problem domain, etc.
At the end of the day, your ability to actually do things doesn't matter much in the interview process. I've worked at 2 huge well known companies and failed at several other interviews. Hundreds of millions of people use my code every day. After nearly a decade in tech, I've never gotten a bad performance review. But I still plinko'ed into the 0 spot many times.
As I get older, I find it's easiest just to enter orgs from friend's recommendations, preferably at smaller companies. Playing the plinko game with your livelihood is an exhausting waste of time, and often represents the politicking that goes on at these huge companies when review time comes around.
There are thousands of pegs on the board, and your resume predicts the starting position of your disk.
But once you hit the pegs, it's essentially random. Some pegs bounce you towards the jackpot and other pegs bounce you towards 0.
It all depends on if you have a similar background, if the person likes you, if you've heard of the question before or solved something similar, if your chosen language fits the problem domain, etc.
At the end of the day, your ability to actually do things doesn't matter much in the interview process. I've worked at 2 huge well known companies and failed at several other interviews. Hundreds of millions of people use my code every day. After nearly a decade in tech, I've never gotten a bad performance review. But I still plinko'ed into the 0 spot many times.
As I get older, I find it's easiest just to enter orgs from friend's recommendations, preferably at smaller companies. Playing the plinko game with your livelihood is an exhausting waste of time, and often represents the politicking that goes on at these huge companies when review time comes around.
Thanks for posting this :)
As someone responsible for observability, I've got a real problem with biasing hiring decisions toward false negatives; what you're basically saying is that you're biasing the system toward the failure mode that you have the least ability to actually measure.
It's a great way to feel good about yourself and your interview process; it's also a great way to not find fault in your interview process as it becomes arbitrarily ... arbitrary.
It's a great way to feel good about yourself and your interview process; it's also a great way to not find fault in your interview process as it becomes arbitrarily ... arbitrary.
"In the cases such as Google, they also tend to create a monoculture which probably feels right at the moment but I think really hurts the company in the long term"
I would agree with you about the monoculture aspect where they tend to hire new college grads from mostly the top colleges. I thought it's a little bit too inbred, but they also buy a lot of companies and get a much broader set of employees that way. Although, they might dump a lot of the acquired employees instead of keeping them on permanently once the acquisition goes through.
I would agree with you about the monoculture aspect where they tend to hire new college grads from mostly the top colleges. I thought it's a little bit too inbred, but they also buy a lot of companies and get a much broader set of employees that way. Although, they might dump a lot of the acquired employees instead of keeping them on permanently once the acquisition goes through.
I'm not a programmer, and had never heard of the fizzbuzz question. After seeing so many people come out in favor of it in the comments, I looked it up. It is just so easy that I have to imagine people who "bomb" it are failing because they're expecting a difficult question and wind up overthinking it.
I mean seriously, this is the question as I found it:
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
And here is an answer in bash that took me literally 30 seconds:
I mean seriously, this is the question as I found it:
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
And here is an answer in bash that took me literally 30 seconds:
for num in {1..100} ; do
out=""
(( $num % 3 == 0 )) && out="Fizz"
(( $num % 5 == 0 )) && out="${out}Buzz"
echo ${out:-$num}
done
IMHO this kind of questions is asked not to determine if the candidate is good, but if he's bad. Indeed, only someone who is really bad at programming would fail it - modulo small syntax errors due to writing code on paper or white board. If the person fails, you should try to show him politely the door - or better, FizzBuzz should be used in phone screen. However, if the person succeeds, it's pointless to ask him or her a more sophisticated version of it, instead, you can ask more complicated questions (algorithms or architecture), and I think that is what RayVR is pointing: it's ok to ask FizzBuzz once, but don't waste the interviewee time asking it 50 times.
As you say, in a phone screen might be suitable place for it. And I certainly don't think there's any point in iterating on it, the only real optimization available is to eliminate the third check for 3 and 5 simultaneously. Truly rocket science.
My main problem is that, as a candidate, I would interpret being asked this question to mean that the interviewers have already undervalued me (or worse, have no idea how to value me).
One weak question in hours of interviews isn't bad, but now I'm mentally preparing for more weak questions. Making a candidate disengage is a sure way to get a bad interview, or a good interview that results in a "no thanks" to your offer.
My main problem is that, as a candidate, I would interpret being asked this question to mean that the interviewers have already undervalued me (or worse, have no idea how to value me).
One weak question in hours of interviews isn't bad, but now I'm mentally preparing for more weak questions. Making a candidate disengage is a sure way to get a bad interview, or a good interview that results in a "no thanks" to your offer.
> My main problem is that, as a candidate, I would interpret being asked this question to mean that the interviewers have already undervalued me (or worse, have no idea how to value me).
No, your main problem is just how many of your contemporaries with indistinguishable backgrounds and experience totally bombs this question.
Being offended by a simple fizz-buzz style question[1] is roughly as constructive as being offended by "Is this a good time to talk?" even when a good time to talk has been carefully scheduled.
1: I don't think many people use fizz-buzz exactly, it's too well known, but there are tons of other really quite simple questions that exercise two or three basic programming concepts, maybe throw in some basic problem solving for good measure.
No, your main problem is just how many of your contemporaries with indistinguishable backgrounds and experience totally bombs this question.
Being offended by a simple fizz-buzz style question[1] is roughly as constructive as being offended by "Is this a good time to talk?" even when a good time to talk has been carefully scheduled.
1: I don't think many people use fizz-buzz exactly, it's too well known, but there are tons of other really quite simple questions that exercise two or three basic programming concepts, maybe throw in some basic problem solving for good measure.
> Truly rocket science.
But that's the problem that FizzBuzz highlights. A bunch of people just can't do it. This isn't about the (now retracted) Sheep and Goats stuff. Plenty of the people who fail fizzbuzz are computer science graduates or senior programmers.
I don't know of any research about why people who think they can program can't do FizzBuzz. I'd love to see it though.
But that's the problem that FizzBuzz highlights. A bunch of people just can't do it. This isn't about the (now retracted) Sheep and Goats stuff. Plenty of the people who fail fizzbuzz are computer science graduates or senior programmers.
I don't know of any research about why people who think they can program can't do FizzBuzz. I'd love to see it though.
If you really bomb the entire interview series because you were asked the fizzbuzz question, it sounds like you wouldn't work well anyway. Sometimes you encounter simple problems. If you can't handle being asked to do a task because it's "beneath you", you are probably a terrible hire anyway.
Thinking that something is beneath me (which is not what I said, by the way) and feeling that the interviewers have undervalued my skillset are two different things entirely.
During an interview, I'm interviewing the interviewers as well as being interviewed. Part of that process (for me) is to see if they have correctly identified my skill level (in my opinion), so that hopefully they have the right kind of position in mind for me.
The name of a position is often meaningless, unless you know the inner workings of that organization. "Senior" is meaningless window dressing. It's how the role fits within the team that determines if it's right for me and if I will be able to have the kind of impact I want.
During an interview, I'm interviewing the interviewers as well as being interviewed. Part of that process (for me) is to see if they have correctly identified my skill level (in my opinion), so that hopefully they have the right kind of position in mind for me.
The name of a position is often meaningless, unless you know the inner workings of that organization. "Senior" is meaningless window dressing. It's how the role fits within the team that determines if it's right for me and if I will be able to have the kind of impact I want.
Try to put yourself in the shoes of the interviewer. You got to interview lots of clueless people who call themselves programmers but are unable to do the simplest task. Once you spoke with enough people like that, the first thing you want to do is weed out the people who can't program, hence the FizzBuzz question.
Now, I am sure that you, skuhn are able to do those simple things, but the guy interviewing you doesn't know it. If he asks you a simple question that you can nail in 5 minutes, and answer "sorry dude, your question is so easy I find it offending", the interviewer will think you're an arrogant douche - that's how I would feel at least. Instead, just solve the problem he's asking you and move on.
If after that he keeps asking stupid questions, well, it's a different story and you probably wouldn't fit well in that company.
Now, I am sure that you, skuhn are able to do those simple things, but the guy interviewing you doesn't know it. If he asks you a simple question that you can nail in 5 minutes, and answer "sorry dude, your question is so easy I find it offending", the interviewer will think you're an arrogant douche - that's how I would feel at least. Instead, just solve the problem he's asking you and move on.
If after that he keeps asking stupid questions, well, it's a different story and you probably wouldn't fit well in that company.
I feel like you're assigning feelings to me that don't mesh with what my comment described. I don't want to get into a personal thing, but here's my condensed point again one last time, in the hope of clarifying:
I think this question is suitable for phone screening. You should already know if someone can do the work equivalent of tying their shoes before bringing them on-site. If I was asked a question at this level during an on-site interview, I would be a little disappointed. If the entire interview continued in that vein, I wouldn't accept the position.
I think this question is suitable for phone screening. You should already know if someone can do the work equivalent of tying their shoes before bringing them on-site. If I was asked a question at this level during an on-site interview, I would be a little disappointed. If the entire interview continued in that vein, I wouldn't accept the position.
Questions like this can work in a phone screen if you have a shared virtual whiteboard. Otherwise it is painful for the interviewer to try to transcribe code as the candidate thinks of it and says it alout.
There is also the common problem where candidates google for answers or at least seem to google for answers during phone screens.
The problem with asking truly challenging coding questions during an interview is that they are often too challenging to finish in the time allotted. Frequently challenging coding questions require an ahah moment or domain knowledge. For example if an interviewer asks a candidate to invent an advanced algorithm on the spot what is being measured? If the candidate gets the answer right they might be really smart, they more likely have been previously exposed to the idea, or they got lucky. If they got the answer wrong the interviewer must judge them on their ability to communicate their thought process during their attempt - but from that the interviewer didn't learn if they can code.
You shouldn't be disappointed that interviewers don't know straight away that you aren't a charlatan. You should instead be disappointed by the fact that there is such a high number of successful charlatans in our industry.
There is also the common problem where candidates google for answers or at least seem to google for answers during phone screens.
The problem with asking truly challenging coding questions during an interview is that they are often too challenging to finish in the time allotted. Frequently challenging coding questions require an ahah moment or domain knowledge. For example if an interviewer asks a candidate to invent an advanced algorithm on the spot what is being measured? If the candidate gets the answer right they might be really smart, they more likely have been previously exposed to the idea, or they got lucky. If they got the answer wrong the interviewer must judge them on their ability to communicate their thought process during their attempt - but from that the interviewer didn't learn if they can code.
You shouldn't be disappointed that interviewers don't know straight away that you aren't a charlatan. You should instead be disappointed by the fact that there is such a high number of successful charlatans in our industry.
I've never asked fizzbuzz, but I have asked people to count the number of upper-case letters in a c-string. I feel like this is of similar difficulty, for people who claim to know C/C++.
When I asked that question, I was looking for fluency. A candidate shouldn't have to think about it. They should write c >= 'A', instead of floundering because they don't remember the ASCII value of 'A'. If asked, they should be able to iterate over the string without taking strlen first.
This is basic stuff, but you might be surprised how many people with years of software development experience on their resumes can't do it. Moreover, I found that a good performance on this easy question was highly predictive of good performance on harder questions. Not that this didn't stop me from asking hard questions. :)
When I asked that question, I was looking for fluency. A candidate shouldn't have to think about it. They should write c >= 'A', instead of floundering because they don't remember the ASCII value of 'A'. If asked, they should be able to iterate over the string without taking strlen first.
This is basic stuff, but you might be surprised how many people with years of software development experience on their resumes can't do it. Moreover, I found that a good performance on this easy question was highly predictive of good performance on harder questions. Not that this didn't stop me from asking hard questions. :)
Unrelated: In Unicode that would be a pretty difficult problem. The uppercase version of 'ß' is actually two characters "SS". There are a lot of messed up casing rules in the unicode standard. http://unicode.org/faq/casemap_charprop.html#11
Sure, casing is complicated; but determining whether a codepoint has the uppercase property is easy - just use u_isUUppercase().
Where it does get complicated is determining whether a codepoint or a digraph of multiple codepoints is a letter, and that's culture-dependent; e.g. IJ in Dutch.
Where it does get complicated is determining whether a codepoint or a digraph of multiple codepoints is a letter, and that's culture-dependent; e.g. IJ in Dutch.
[deleted]
If you can write a FizzBuzz solution in bash in 30 seconds, you are definitely a programmer. You don't have to program as a profession to be a programmer.
I mentioned that I'm not a programmer because that's typically the biggest hurdle for me in technical interviews. I don't write code for a living, nor do I want to. Yet I still get asked programming questions, but nothing remotely this simple.
> One of my potential colleagues interviewed me and gave me a fizzbuzz question.
That should have been a big clue right there that it wasn't going to go well. Based on their hiring criterion and culture, that they still do a technical interview like they were hiring junior developers is a bad sigh.
That should have been a big clue right there that it wasn't going to go well. Based on their hiring criterion and culture, that they still do a technical interview like they were hiring junior developers is a bad sigh.
Nope. At my last company I did all the technical interviews.
Now, I have no idea how HR selected them, but I got their CVs on my desk and was asked to schedule a meeting with them.
And so I did. And oh boy, there were a LOT of previous Fortune 500 Senior devs that could not write anything that even resembles a correct fizzbuzz solution in any language they like without time restriction (I had to kick a few people out after I left them alone for 30 minutes and they told me they need more time).
All their CV's looked fine though. If I interview you, I'll ask you to write code, on any level. Usually I asked interviewees for ~3 code samples on paper starting with fizzbuzz moving up in difficulty to still beeing a relatively easy ~5 minute task.
I've had one interviewee that started to laugh when I asked him for a fizzbuzz sample and he said, "well that's like asking a baker to bake a bun". he proceded to write a fizzbuzz solution down and is apparently one of the top developers at that company now.
I don't care how senior you are. If you're offended by quickly writing down a fizzbuzz solution you're not senior enough to realize how much some people suck at programming.
Obviously the actual only interview only started after they wrote fizzbuzz, fizzbuzz helped me stop wasting my time and I convinced HR to stop sending me CVs of people that played bullshit bingo in their CVs.
Sure you could blame HR on this for not filtering good enough but HR aren't developers. Although I'm not saying HR couldn't have given me better CVs...
And so I did. And oh boy, there were a LOT of previous Fortune 500 Senior devs that could not write anything that even resembles a correct fizzbuzz solution in any language they like without time restriction (I had to kick a few people out after I left them alone for 30 minutes and they told me they need more time).
All their CV's looked fine though. If I interview you, I'll ask you to write code, on any level. Usually I asked interviewees for ~3 code samples on paper starting with fizzbuzz moving up in difficulty to still beeing a relatively easy ~5 minute task.
I've had one interviewee that started to laugh when I asked him for a fizzbuzz sample and he said, "well that's like asking a baker to bake a bun". he proceded to write a fizzbuzz solution down and is apparently one of the top developers at that company now.
I don't care how senior you are. If you're offended by quickly writing down a fizzbuzz solution you're not senior enough to realize how much some people suck at programming.
Obviously the actual only interview only started after they wrote fizzbuzz, fizzbuzz helped me stop wasting my time and I convinced HR to stop sending me CVs of people that played bullshit bingo in their CVs.
Sure you could blame HR on this for not filtering good enough but HR aren't developers. Although I'm not saying HR couldn't have given me better CVs...
I've had very similar experience hiring for information security roles.
The volume of "good" CVs that landed on my desk was consistently high, but when we spoke to the candidates on their first telephone interview it became immediately apparent that they were not nearly as skilled at security as they were at writing CVs.
In the end, we inserted a 10 minute quick-fire Q&A at the beginning of the telephone interview which was as basic as "Define: Confidentiality, Integrity, and Availability" and other such trivial security knowledge. It was terrifying the number of people applying for mid/senior level jobs, or contracts with high day-rates who couldn't get past this. What was most galling was when people were obviously googling the anwswers whilst we spoke - we countered this with simple "which is better, and why" type questions so that there was too many variables to google and you also needed to defend your answer.
There were only a very small number of candidates who, when confronted with the Q&A responded in a "are you serious?" kind of way and just rattled off the basic knowledge in a couple of minutes. With these we could get down to the detail of the real interview pretty quickly.
The volume of "good" CVs that landed on my desk was consistently high, but when we spoke to the candidates on their first telephone interview it became immediately apparent that they were not nearly as skilled at security as they were at writing CVs.
In the end, we inserted a 10 minute quick-fire Q&A at the beginning of the telephone interview which was as basic as "Define: Confidentiality, Integrity, and Availability" and other such trivial security knowledge. It was terrifying the number of people applying for mid/senior level jobs, or contracts with high day-rates who couldn't get past this. What was most galling was when people were obviously googling the anwswers whilst we spoke - we countered this with simple "which is better, and why" type questions so that there was too many variables to google and you also needed to defend your answer.
There were only a very small number of candidates who, when confronted with the Q&A responded in a "are you serious?" kind of way and just rattled off the basic knowledge in a couple of minutes. With these we could get down to the detail of the real interview pretty quickly.
Why would you trust HR to forward you the CVs anyway? I had to beg and plead to get HR to send me the unfiltered resume submissions but finally got them to do so. They're completely unqualified to determine which experience is necessary or relevant (which is fine, since they're not programmers; they just shouldn't be filtering resumes).
To be completely honest, I just really didn't care enough and had other things to do.
I did that when we were ~7 people, then the company grew, we got a HR department and I kinda lost interest in the company and was just doing my job. Efficient shouting-trough-the-room to get shit done was replaced by by slow corporate processes, office politics started to happen, somebody decided that our SMB shared folders must have a number in front so they are shown in the order admin though they needed to be shown... So when they decided to optimize folder structures for mouse-heavy non-technical users, taking my ability to quickly nagivate trough the directory structure, I decided it was time to leave :)
Edit: One funny thing I forgot, they built a file-name generator in excel we had to use :)
I did that when we were ~7 people, then the company grew, we got a HR department and I kinda lost interest in the company and was just doing my job. Efficient shouting-trough-the-room to get shit done was replaced by by slow corporate processes, office politics started to happen, somebody decided that our SMB shared folders must have a number in front so they are shown in the order admin though they needed to be shown... So when they decided to optimize folder structures for mouse-heavy non-technical users, taking my ability to quickly nagivate trough the directory structure, I decided it was time to leave :)
Edit: One funny thing I forgot, they built a file-name generator in excel we had to use :)
Fizzbuzz has not been very useful for me while conducting interviews. Nearly all candidates had no problems solving it fairly quickly. But many of these candidates couldn't solve much simpler problems such as "Initialize a list or array of numbers".
Jeff Atwood has a good post[1] on why something as simple as FizzBuzz is valuable when hiring engineers at any level.
[1] http://blog.codinghorror.com/why-cant-programmers-program/
[1] http://blog.codinghorror.com/why-cant-programmers-program/
For anyone above a jr level developer position, I would assume they'd have code or other artifacts you could review. If you weren't satisfied with their approach or style, don't interview further, or ask for clarification.
If you can not find anyone at all with example code/projects, perhaps then start employing fizzbuzz on folks, but... I can't imagine it's too hard to find developers with at least a minimal portfolio that demonstrates something at least as complex, if not moreso, than fizzbuzz.
If you can not find anyone at all with example code/projects, perhaps then start employing fizzbuzz on folks, but... I can't imagine it's too hard to find developers with at least a minimal portfolio that demonstrates something at least as complex, if not moreso, than fizzbuzz.
The problem with sample code is that I have no idea if you actually wrote it. Maybe you copied it from Google, maybe your friend "helped" you. I have no idea. When I'm first interviewing you, I have no idea how honest you are. The only way I know for sure that you wrote the code is if I watch you write it in front of me.
I really like Fizzbuzz because for someone who is a good programmer, whether they've ever seen it or not, they can do it in about two minutes, and then at least I can believe that their code sample is theirs.
I really like Fizzbuzz because for someone who is a good programmer, whether they've ever seen it or not, they can do it in about two minutes, and then at least I can believe that their code sample is theirs.
I once skipped the "simple programming exercise" part of the interview process for someone who was senior, and severely regretted it when it turned out he struggled with basic programming tasks.
He had a nice code sample (pre-github era).
He had a nice code sample (pre-github era).
Yes. I've interviewed "senior software engineers with 10+ years of C++ experience" that could not tell me the difference between a char and a char pointer.
I interviewed a self-declared "biometrics expert" once.
When I see "expert" on a CV I have learned to become cynical.
I asked him about his expertise and he spoke in platitudes about it - at a sort of BBC News kind of level. I'm certainly not an expert but I know sufficient to be able to ask useful questions about it.
He couldn't tell me anything at all about biometrics. I continued to probe.
Turns out that by "biometrics expert" he quite unashamedly meant he had, at the request of a manager, bought a USB fingerprint reader from PC World and installed it so that his manager didn't have to use a password any more.
When I see "expert" on a CV I have learned to become cynical.
I asked him about his expertise and he spoke in platitudes about it - at a sort of BBC News kind of level. I'm certainly not an expert but I know sufficient to be able to ask useful questions about it.
He couldn't tell me anything at all about biometrics. I continued to probe.
Turns out that by "biometrics expert" he quite unashamedly meant he had, at the request of a manager, bought a USB fingerprint reader from PC World and installed it so that his manager didn't have to use a password any more.
>When I see "expert" on a CV I have learned to become cynical.
One has to play this game on marketing documents to be considered. For some reason "pretty good, definitely still learning" doesn't click with many HR people. You can't really blame candidates for trying to get hired by presenting themselves in an authoritative context.
I don't consider anyone an actual expert in something unless they have hard, indisputable credentials, like a long history of commits to the core project (for expertise in specific software/languages/frameworks), etc.
One has to play this game on marketing documents to be considered. For some reason "pretty good, definitely still learning" doesn't click with many HR people. You can't really blame candidates for trying to get hired by presenting themselves in an authoritative context.
I don't consider anyone an actual expert in something unless they have hard, indisputable credentials, like a long history of commits to the core project (for expertise in specific software/languages/frameworks), etc.
I completely agree that it's a sales vs. HR thing, and that the onus is on the candidate to make themselves appear as the best product on the market.
But something about "expert" really grates on me. I think it's that it is a self-anointed title in nearly all cases. There are legitimately experts in lots of different areas - if you happened to invent IDS, for example, you go right ahead and call yourself an expert. If you happen to have run a bunch of Snort rules across a prod environment for a year or two, you might be "experienced", go on, stretch it to "highly experienced" for all I care, but if you stretch it to "expert" then paint me cynical.
But something about "expert" really grates on me. I think it's that it is a self-anointed title in nearly all cases. There are legitimately experts in lots of different areas - if you happened to invent IDS, for example, you go right ahead and call yourself an expert. If you happen to have run a bunch of Snort rules across a prod environment for a year or two, you might be "experienced", go on, stretch it to "highly experienced" for all I care, but if you stretch it to "expert" then paint me cynical.
How is that even possible? Are you sure they weren't just having (to be crude) a brain fart?
Some of these stories about super experienced ("10+ years") developers not being able to answer the most basic of basic syntax or "algorithm" questions seem far-fetched to me.
Some of these stories about super experienced ("10+ years") developers not being able to answer the most basic of basic syntax or "algorithm" questions seem far-fetched to me.
Consider that most "valid" implementations of fizzbuzz are wholly dependent on awareness of the target language's modulo operator. Self-taught programmers can easily overlook that, and if a specific language is requested, it's easy to not know the syntax even if the concept is understood.
Really I don't think those sort of on-the-spot tests/trivia questions are representative by themselves. They may be a useful part of a larger investigation.
Two things to stop code sample plagiarism: choose a unique code challenge and, if you're really worried about it, give the client a laptop and tell them to bang something simple out right there and come back in 30-60 minutes to check.
Honestly, though, I've rarely depended on either code samples or code trivia to determine if someone is a good hire. If you sit and talk about dev with a person, you can tell if they're on their game or not 90% of the time. The sample/on-the-spot tests can help weed out that extra 10%.
Really I don't think those sort of on-the-spot tests/trivia questions are representative by themselves. They may be a useful part of a larger investigation.
Two things to stop code sample plagiarism: choose a unique code challenge and, if you're really worried about it, give the client a laptop and tell them to bang something simple out right there and come back in 30-60 minutes to check.
Honestly, though, I've rarely depended on either code samples or code trivia to determine if someone is a good hire. If you sit and talk about dev with a person, you can tell if they're on their game or not 90% of the time. The sample/on-the-spot tests can help weed out that extra 10%.
I've also heard of a story where an "Expert in C" (verbatim from resume) thought that the * in the sample source code was a typo.
I'm not sure how this is possible either, but the world works in mysterious ways.
I'm not sure how this is possible either, but the world works in mysterious ways.
It's possible if the person lied on their resume about actually having 10+ years of experience.
We're moving towards a code sample as screening method, but then one of the interview sessions is an intensive review of the supplied code including tradeoffs made with other possibilities, etc. If they understand the code well enough to pass that session, personally it doesn't matter to me if they actually wrote it or not - they clearly could have.
In 2002, a company I interviewed with did just that. They tore my code apart, asking me to justify myself, and I felt like I completely bombed it.
In the end they said "Okay, you pass." When I asked why, the answer was "While we don't agree with all the choices, it's basically well-written and does something interesting. We just wanted to know if you were the one who wrote it."
In the end they said "Okay, you pass." When I asked why, the answer was "While we don't agree with all the choices, it's basically well-written and does something interesting. We just wanted to know if you were the one who wrote it."
Yeah, we make it clear to reviewers that the point isn't to inject their own opinions as to how it should have been written (and certainly not "your curly brace is in the wrong spot"!) but rather to determine:
- did they likely write the code, for obvious reasons - are they aware of the various tradeoffs and choices they made, i.e. we might not agree but can they make a reasonable argument for them - this demonstrates breadth of knowledge - how are their communication skills?
- did they likely write the code, for obvious reasons - are they aware of the various tradeoffs and choices they made, i.e. we might not agree but can they make a reasonable argument for them - this demonstrates breadth of knowledge - how are their communication skills?
A lot of developers, myself included, do not perform well under a microscope. They almost can't even type when someone is watching them, making stupid mistakes and blanking on simple concepts. Luckily, the vast majority of programmers don't have to code under this kind of pressure on a daily basis. I find the most effective way to get a good sense of how someone can code is to give them homework to do that they can bring to the interview and discuss. That way they can take their time, put their best foot forward, and it won't weed out introverts or people with test or social anxiety.
I think I usually noticed when someone felt uneasy, so I left the room for a few minutes.
Test anxiety might be really bad for some people, I know. But if it's that bad that they can't explain to me how to check if "n mod m == 0" then I think there are usually deeper underlying problems in their programming ability.
And if it was really just anxiety, I'm sorry I'd rather have a false negative than hiring them.
I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties. The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code. Fizzbuzz is simple enough that you can see if it looks right in pretty much any language And it's done in 5 minutes even if that means accepting a few false positives.
Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE). And all of them failed. Hard. So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.
I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties. The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code. Fizzbuzz is simple enough that you can see if it looks right in pretty much any language And it's done in 5 minutes even if that means accepting a few false positives.
Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE). And all of them failed. Hard. So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.
This is precisely what we do when hiring at our web dev/game/app agency. We have a somewhat casual meeting to first determine if the candidate is the type of person we'd want to work with every day and then we give them a challenge to take home with them. We provide a direct line to one of our developers that fulfills a similar role to what we are hiring for and encourage them to ask questions as they are completing the challenge. It's a very telling process. We are a very collaborative team and expect people to ask questions and grow together. When candidates ask questions that would be really easily answered by a quick Google search, or take far longer to complete the challenge than it should take someone who even sort of knows what they are doing, these are major red flags. At the end we review their code and see if their solutions are well thought out and up to basic standards. I should mention the challenge is typically extremely simple... Some candidates don't make it a priority and make excuses for days or weeks on end why they aren't finished. These don't tend to be the type of people we like to hire.
It's easy to tell if they wrote it. Just start asking them questions about it. How does this work? Why did you make this design decision? What happens in this case?
I would be delighted if an interviewer asked me such questions about my code.
I would be delighted if an interviewer asked me such questions about my code.
Some interviewees talk up a big game. And some interviewers are too forgiving. "He fudged blah, but he probably meant factory pattern. Hired!"
Fizz buzz you can't skate around. Either you know how to implement something, or you don't.
Fizz buzz you can't skate around. Either you know how to implement something, or you don't.
On the other hand, when I need a new job, I am going to simply spend a week with an interview algorithms book and cram on all the little riddles and exercises that people seem to want.
I'd actually have to think for a minute on how to do fizz buzz right now, simply because it is so far remove from the actual engineering workflow.
I'd actually have to think for a minute on how to do fizz buzz right now, simply because it is so far remove from the actual engineering workflow.
> simply because it is so far remove from the actual engineering workflow.
Err, what? Fizzbuzz is NOT a riddle. It's intentionally meant to be a stupid simple test, and everyone has written stupid simple code at some point. Even as a "senior engineer" you'll have to write dumb business logic code, even if it's only occasional.
If you really struggle with fizzbuzz it would almost assuredly be a sign that you would really struggle to write quality software in a timely manner. It's also a sign that you really aren't familiar with even the basic control flow of your chosen language, which is similarly worrying.
The only part of fizzbuzz that's "removed from the actual engineering workflow" is MAYBE the modulus operation, which I'm willing to bet most interviewers probably won't give a shit if you goof on the syntax a little and write "%" when you should've written "%%".
And even then, a perfectly acceptable fizzbuzz can be written without using mod if you're not familiar with that basic arithmetic operation.
Err, what? Fizzbuzz is NOT a riddle. It's intentionally meant to be a stupid simple test, and everyone has written stupid simple code at some point. Even as a "senior engineer" you'll have to write dumb business logic code, even if it's only occasional.
If you really struggle with fizzbuzz it would almost assuredly be a sign that you would really struggle to write quality software in a timely manner. It's also a sign that you really aren't familiar with even the basic control flow of your chosen language, which is similarly worrying.
The only part of fizzbuzz that's "removed from the actual engineering workflow" is MAYBE the modulus operation, which I'm willing to bet most interviewers probably won't give a shit if you goof on the syntax a little and write "%" when you should've written "%%".
And even then, a perfectly acceptable fizzbuzz can be written without using mod if you're not familiar with that basic arithmetic operation.
> I'd actually have to think for a minute on how to do fizz buzz right now, simply because it is so far remove from the actual engineering workflow.
This type of attitude is highly suspicious.
If you're not the kind of person who thinks fizz buzz is trivial, then there are actual red flags.
This type of attitude is highly suspicious.
If you're not the kind of person who thinks fizz buzz is trivial, then there are actual red flags.
Fizzbuzz may seem natural to people with an inclination for numbers or formal schooling that forcibly crams lots of math you'll never use down your throat, but some people haven't been taught about modulus operations and some people may not be very good at division and would take a while to try to reinvent mod. Neither of those things are necessarily really big problems if that person is going to be writing business logic (though you might want to have someone check any code they write which involves money).
The idea of "fizzbuzz" is to show basic understanding of language control structures and flow. Better, more universal tests that actually use language constructs that are encountered in daily operation could definitely be devised to demonstrate the same fundamental concepts.
The idea of "fizzbuzz" is to show basic understanding of language control structures and flow. Better, more universal tests that actually use language constructs that are encountered in daily operation could definitely be devised to demonstrate the same fundamental concepts.
You don't have to leave it at just reviewing online code, but it's generally a 1st level filter. If someone has already written moderately advanced stuff online, have them write something at that level. If they can't do that, they wouldn't be able to do fizz buzz either.
> I would assume they'd have code or other artifacts you could review
90% of the code I've written, and all the clever stuff, is copyright of and property of corporations. There's no way I'd jeopardise my current job by showing someone else that code
90% of the code I've written, and all the clever stuff, is copyright of and property of corporations. There's no way I'd jeopardise my current job by showing someone else that code
Sure, but you ask it or something like that very early on, long before the person even walks in the door. If you're wasting valuable interview time with FizzBuzz on anything other than an entry level position, you're doing it wrong.
Every single 'code interview' question site/blog covers FizzBuzz problem ten times a year. Tests like this are a giant waste of time.
I've interviewed people who didn't know their way around a loop.
I would love to exist in a world where everyone could fizz buzz flawlessly.
I would love to exist in a world where everyone could fizz buzz flawlessly.
They would be a waste of time, if every job seeker took advantage of such sites / blogs.
That's assuming you respect Jeff Atwood's opinions at all.
I've had senior developers, who came from a large respected companies, bomb fizzbuzz.
I'll stop asking fizzbuzz when people stop failing it.
I'll stop asking fizzbuzz when people stop failing it.
I really like Fizzbuzz because for someone who is a good programmer, whether they've ever seen it or not, they can do it in about two minutes. I usually use it as my first question on the phone screen.
And you know what? More than 1/2 the people that claim to be doing a job writing code right now can not do it. If you can't write a simple loop in your preferred language, I have to wonder how you are doing coding right now and being successful.
And you know what? More than 1/2 the people that claim to be doing a job writing code right now can not do it. If you can't write a simple loop in your preferred language, I have to wonder how you are doing coding right now and being successful.
I think part of the key with giving FizzBuzz is telling the candidate that any working solution is AOK and meaning it, in other words the dumbest brute force loop is a successful answer. My suspicion is that more candidates than one would expect get hung up worrying about giving some sort of clever answer to impress the interviewer that they bobble it up a bit.
That said, for FizzBuzz proper, one should have dozens of solutions memorized for these situations, but for similarly easy questions the candidate might not have come across that might end up being a big deal.
That said, for FizzBuzz proper, one should have dozens of solutions memorized for these situations, but for similarly easy questions the candidate might not have come across that might end up being a big deal.
> My suspicion is that more candidates than one would expect get hung up worrying about giving some sort of clever answer to impress the interviewer that they bobble it up a bit.
I've definitely felt that pressure as an interviewee. It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.
The most fun technical questions I've had start with making a functional algorithm and then massaging it to meet whatever time/space complexity requirements are asked for. Sometimes it results in a complete rewrite and that's ok, the real world works like that too.
I've definitely felt that pressure as an interviewee. It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.
The most fun technical questions I've had start with making a functional algorithm and then massaging it to meet whatever time/space complexity requirements are asked for. Sometimes it results in a complete rewrite and that's ok, the real world works like that too.
> It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.
I almost always preface whiteboard coding sessions with "I'm going to write some dumb, slow code and then we can make it faster if you want. Sound OK?" I've never had anyone disagree with this, but if they tell you they want you to go straight to the clever solution, hey, now you know what they're looking for.
I almost always preface whiteboard coding sessions with "I'm going to write some dumb, slow code and then we can make it faster if you want. Sound OK?" I've never had anyone disagree with this, but if they tell you they want you to go straight to the clever solution, hey, now you know what they're looking for.
Even still, sometimes it helps just getting a solution down in order to step back and figure out the clever solution.
Plus, you can "scale up" the interview to harder questions so you can test the candidate without making them feel bad by bombing a touch problem at the very start of the interview.
Well, that is just it. Certainly 100% of the people I have ever worked with, even the bad ones, can write a for loop and an if statement. I mistrust the process more than I mistrust the people, though I suppose maybe the same bad people and endlessly interviewing.
50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?
I don't quite buy the whole fizz-buzz story, though I don't have an adequate explanation for what could cause these kinds of failure rates. Something seems very off.
50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?
I don't quite buy the whole fizz-buzz story, though I don't have an adequate explanation for what could cause these kinds of failure rates. Something seems very off.
>50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?
Not 50% of working programmers, but of the programmer applicant pool. The applicants who can find jobs quickly aren't in the pool very long, and so it's dominated by the fakers and those who otherwise shouldn't be there. ... Which should make the reported phenomenon a little more believable.
Not 50% of working programmers, but of the programmer applicant pool. The applicants who can find jobs quickly aren't in the pool very long, and so it's dominated by the fakers and those who otherwise shouldn't be there. ... Which should make the reported phenomenon a little more believable.
Fizzbuzz is incredibly useful to quickly smoke out people who have lied or faked or exaggerated their way into the interview.
However, that's all it's good for, which means it should be a single pass/fail question. Asking the candidate increasingly specific iterations of fizzbuzz would be a waste of time.
However, that's all it's good for, which means it should be a single pass/fail question. Asking the candidate increasingly specific iterations of fizzbuzz would be a waste of time.
> I honestly could tell that the interviewer giving me the fizzbuzz questions wasn't clicking with me personally. That's fine, and I completely respect that it's a valid reason not to hire someone.
No, it really isn't. You should have a set of hiring standards that you strive to make as objective and quantifiable as possible. The interviewer should also be doing everything he or she can do to minimize their own personal bias entering into the evaluation of you as a candidate.
Hiring people you get along with, i.e. people like you, is usually a quick path towards a homogeneous team of straight, white males from privileged backgrounds.
No, it really isn't. You should have a set of hiring standards that you strive to make as objective and quantifiable as possible. The interviewer should also be doing everything he or she can do to minimize their own personal bias entering into the evaluation of you as a candidate.
Hiring people you get along with, i.e. people like you, is usually a quick path towards a homogeneous team of straight, white males from privileged backgrounds.
I recently redesigned our department's hiring process for software folks and one of the things I did was change our standard 2 person interview panels to be a larger group at once.
The primary reason is so that everyone is seeing the same thing, including these sorts of personality conflicts. If Bob thinks the candidate is horrible due to some weird hangup and they were interviewing solo, the team would have to believe Bob. But if everyone else saw the interaction, they'd know that Bob was just being a cantankerous coot.
The primary reason is so that everyone is seeing the same thing, including these sorts of personality conflicts. If Bob thinks the candidate is horrible due to some weird hangup and they were interviewing solo, the team would have to believe Bob. But if everyone else saw the interaction, they'd know that Bob was just being a cantankerous coot.
A more scalable solution to this is pair interviews.
The first company I worked at for 4 years made use of this, in addition to meeting in person, at the end of the day, to make a decision.
Benefits of the pair interview: Two different opinions on the candidate for the same "experience". If either interviewer had poor tendencies, they'll be curtailed a bit because they know someone else is there to witness them.
If both interviewers are in agreement, that's a pretty strong data point.
When it came time for "review" at the end of the day, we started with an around the room "thumbs up/down". No hiding behind an anonymous email to the recruiter/manager. If it was unanimously up...offer. Unanimously down? Obvious no hire. If it was mixed, we'd go around to all of the thumbs down, and ask, "Are you on the fence, or are you 100% vehemently opposed to this candidate?" If they said, "NO WAY JOSE", we'd ask them to give their reasoning. Then, we'd ask if anyone had a positive enough experience to argue in favor of the candidate. If not? No hire. If yes, we'd then go around the room and ask all of the interviewers to give a full description of the interview. You'll note that this part gives the full data, but takes the most time, but could be avoided (an optimization) if it was going to be ultimately fruitless.
This was by far the best hiring decision making process I've been a part of. No process, is perfect, but I feel this was pretty fair.
Oh - lastly, if a candidate was particularly hard to decide on, and we went around the room, and some people were for them, and some were against, and it ended up in deadlock - we ended the meeting and it was up to the ranking members of the team to decide (i.e. managers.) This meant that after one round of debate, we wouldn't keep wasting the company's dime trying to force consensus, and instead moved the decision to the people who the company had already decided it wanted to make decisions. So, if democracy worked...great, but this was a business, and we had get shit done, so lacking clear consensus, the burden was reduced.
After typing this out, I really, really whole heartedly respect this process - compared to much of what I've seen in the Valley.
The first company I worked at for 4 years made use of this, in addition to meeting in person, at the end of the day, to make a decision.
Benefits of the pair interview: Two different opinions on the candidate for the same "experience". If either interviewer had poor tendencies, they'll be curtailed a bit because they know someone else is there to witness them.
If both interviewers are in agreement, that's a pretty strong data point.
When it came time for "review" at the end of the day, we started with an around the room "thumbs up/down". No hiding behind an anonymous email to the recruiter/manager. If it was unanimously up...offer. Unanimously down? Obvious no hire. If it was mixed, we'd go around to all of the thumbs down, and ask, "Are you on the fence, or are you 100% vehemently opposed to this candidate?" If they said, "NO WAY JOSE", we'd ask them to give their reasoning. Then, we'd ask if anyone had a positive enough experience to argue in favor of the candidate. If not? No hire. If yes, we'd then go around the room and ask all of the interviewers to give a full description of the interview. You'll note that this part gives the full data, but takes the most time, but could be avoided (an optimization) if it was going to be ultimately fruitless.
This was by far the best hiring decision making process I've been a part of. No process, is perfect, but I feel this was pretty fair.
Oh - lastly, if a candidate was particularly hard to decide on, and we went around the room, and some people were for them, and some were against, and it ended up in deadlock - we ended the meeting and it was up to the ranking members of the team to decide (i.e. managers.) This meant that after one round of debate, we wouldn't keep wasting the company's dime trying to force consensus, and instead moved the decision to the people who the company had already decided it wanted to make decisions. So, if democracy worked...great, but this was a business, and we had get shit done, so lacking clear consensus, the burden was reduced.
After typing this out, I really, really whole heartedly respect this process - compared to much of what I've seen in the Valley.
We do this at my current company. The tiebreaker stuff is slightly different, and every candidate that gets a vote of confidence actually ends up chatting briefly with our CEO as the very last bit, which is more of a cultural fit thing than anything else. I agree that it's good to have a potential counterpoint to odd personal interactions.
Interviews are clearly stressful situations for a majority of candidates, even if their technical chops are without question. This ends up manifesting in ways that can come off as personality defects / lack of fit. I can think of a few times where the person I went in with came out with a specific point in spacetime that was wrinkled for them - a comment they thought was off, something about their behavior - and more than half of the time I've noticed comments the candidate made, or compensating factors, that reasonably explained these wrinkles. A lot of the time, I'm trying to balance the things I care about asking with paying attention to my co-interviewer so I can provide objectiveness down the line.
So far, it's worked out well. No lemons yet.
Interviews are clearly stressful situations for a majority of candidates, even if their technical chops are without question. This ends up manifesting in ways that can come off as personality defects / lack of fit. I can think of a few times where the person I went in with came out with a specific point in spacetime that was wrinkled for them - a comment they thought was off, something about their behavior - and more than half of the time I've noticed comments the candidate made, or compensating factors, that reasonably explained these wrinkles. A lot of the time, I'm trying to balance the things I care about asking with paying attention to my co-interviewer so I can provide objectiveness down the line.
So far, it's worked out well. No lemons yet.
Panel interviews are usually a bad idea since they intimidate many candidates.
I would have been working in a three person team (including me). This results in spending a TON of time with your teammates, usually more time than your family. Not liking someone is a reasonable filter in this case.
I happen to work on a three person team right now and I like my two colleagues. It does not conform at all to your forecast for (straight, white, privileged, men). Sorry. I think this is based on the assumption that people like others that are like themselves, which in fact is not very true. I prefer to be around people that are very different from me.
I happen to work on a three person team right now and I like my two colleagues. It does not conform at all to your forecast for (straight, white, privileged, men). Sorry. I think this is based on the assumption that people like others that are like themselves, which in fact is not very true. I prefer to be around people that are very different from me.
> I think this is based on the assumption that people like others that are like themselves, which in fact is not very true. I prefer to be around people that are very different from me.
Unfortunately, it is uncontroversial that most people show preferences for people similar to themselves when choosing friends, romantic partners, and employees. Nobody, that I've heard, is saying that this applies to every single person, so there's no reason to say that it can't be true because you don't follow it.
http://www.sciencedaily.com/releases/2011/09/110922093313.ht... for a random paper
Unfortunately, it is uncontroversial that most people show preferences for people similar to themselves when choosing friends, romantic partners, and employees. Nobody, that I've heard, is saying that this applies to every single person, so there's no reason to say that it can't be true because you don't follow it.
http://www.sciencedaily.com/releases/2011/09/110922093313.ht... for a random paper
[deleted]
After my interview with Netflix, I felt smarter. Didn't end up working there, but met new people & we shared strategies for achieving higher performance.
[deleted]
Then he asked me to do it one more time. I wasn't familiar with the python syntax for if-else shortcut (e.g., x = 100 if y is True else 0) and so couldn't rewrite it to his liking. This lack of familiarity with this python trick resulted in feedback at the end of the interview that I did not have a deep enough understanding of computer science.
Precious.
And of course, an entirely different take could be made from your response -- precisely because you do have a solid grounding in CS, you've probably chosen to spend your time with languages with (for want of a better term) more "powerful", and arguably more standard constructions than what Python affords for this kind of a logical switch -- namely, a ternary operator -- which if Python had it, would probably look a lot like this:
So if you were interviewing for a senior-level, Python-specific position I can see why they'd expect you to know the if-then-else trick. But if it's a secondary language for you, then the feedback that interviewer gave you definitely seems more than a bit off-base.
(DISCLAIMER: No, I don't think Python is a flawed language because it doesn't have a ternary op, or that it should have "stronger CS fundamentals" or any of that. It's just a side aspect or a different, larger point I was making).
Precious.
And of course, an entirely different take could be made from your response -- precisely because you do have a solid grounding in CS, you've probably chosen to spend your time with languages with (for want of a better term) more "powerful", and arguably more standard constructions than what Python affords for this kind of a logical switch -- namely, a ternary operator -- which if Python had it, would probably look a lot like this:
x = y ? 100 : 0
So if you were interviewing for a senior-level, Python-specific position I can see why they'd expect you to know the if-then-else trick. But if it's a secondary language for you, then the feedback that interviewer gave you definitely seems more than a bit off-base.
(DISCLAIMER: No, I don't think Python is a flawed language because it doesn't have a ternary op, or that it should have "stronger CS fundamentals" or any of that. It's just a side aspect or a different, larger point I was making).
Someone else mentioned the fact that
I'd like to bring up that while it's a matter of opinion the older ugly ?: syntax is much less readable even when you memorize it. I never use ?: syntax ternary expressions in languages that have them because I always have to look it up. That's why a number of languages prefer python-like versions or forms which emphasize to an even larger degree the fact that its just an if-else as an expression to an even larger degree(so I'd question that it's standard, I'm not 100% it's older either as I think the LISP version is closer to the python version).
CoffeeScript
Scala a = if (n == 12) "twelve" else "not twelve"
Rust
default_result if condition else alternate_result
I'd like to bring up that while it's a matter of opinion the older ugly ?: syntax is much less readable even when you memorize it. I never use ?: syntax ternary expressions in languages that have them because I always have to look it up. That's why a number of languages prefer python-like versions or forms which emphasize to an even larger degree the fact that its just an if-else as an expression to an even larger degree(so I'd question that it's standard, I'm not 100% it's older either as I think the LISP version is closer to the python version).
CoffeeScript
s = if condition then "yup" else "nope"
abs := x > 0 ifTrue: [ x ] ifFalse: [ x negated ]
Scala a = if (n == 12) "twelve" else "not twelve"
Rust
let y = if x == 5 { 10 } else { 15 }; // y: i32
fac x = if x==0 then
1
else x * fac (x - 1)
When first learning python (Shaw's The Hard Way maybe), it suggested this idiom as python's ternary operator:
This is parallel to the standard C one. I'm surprised no one has mentioned it, but I guess that makes sense because it's not very explicit about what it's doing, which goes agains the spirit of python. Probably not very common for python programmers to use.
boolean and true_branch or false_branch
This is parallel to the standard C one. I'm surprised no one has mentioned it, but I guess that makes sense because it's not very explicit about what it's doing, which goes agains the spirit of python. Probably not very common for python programmers to use.
That is pythons 'ternary operator', you can nest it:
x = 11 if False else ( 12 if False else 13)
print x
=> 13
You can actually just use the 'or' to shortcut this whole thing, because or returns the first true value.
x = False or (True or False)Or you can write it all out on multiple lines
This also removes ambiguity in the case where you might want to assign to x some falsey thing like None or [] or zero:
if cond1:
if cond2:
x = 12
else:
x = 11
else:
x = 13
This also removes ambiguity in the case where you might want to assign to x some falsey thing like None or [] or zero:
>>> y = None
>>> x = False or ( y or False )
>>> x
False
>>> print [bool(f) for f in [None, 0, 0.0, [], ()]]
[False, False, False, False, False]
>If you really do want to test the falsey behavior, IMHO it's much, much clearer to branch on bool(the_maybe_falsey_thing) rather than just the_maybe_falsey_thing.
Maybe if you never program in python. Otherwise it makes absolutely no sense to do so because its obvious that every value is evaluated for its boolean value.
Maybe if you never program in python. Otherwise it makes absolutely no sense to do so because its obvious that every value is evaluated for its boolean value.
Right. But at no point was I saying that Python ought to have a ternary op, or that it doesn't have an analogous construct.
"If hiring is broken, what else is broken?"
I've seen quite a few articles on HN recently where what we call "candidate experience" during the hiring process was a theme. Whether this writer chose to list "Recruiting" as the first topic because of chronology (recruiting was first experience with company) or to emphasize the importance is unknown, but candidates today seem to assume that a broken hiring process is indicative of flaws in culture and how the company values employees.
Companies that simply play the numbers game and don't consider improving candidate experience are running the risk of reducing their brand as an employer, regardless of how the public regards their products or services.
I've seen quite a few articles on HN recently where what we call "candidate experience" during the hiring process was a theme. Whether this writer chose to list "Recruiting" as the first topic because of chronology (recruiting was first experience with company) or to emphasize the importance is unknown, but candidates today seem to assume that a broken hiring process is indicative of flaws in culture and how the company values employees.
Companies that simply play the numbers game and don't consider improving candidate experience are running the risk of reducing their brand as an employer, regardless of how the public regards their products or services.
It's important for candidates not to over-emphasize the smoothness of the hiring process.
I almost didn't work for a company because my experience during an internship was that HR, payroll, and other departments that were not part of my day-to-day job were painful and bureaucratic. I was talked into the job anyway, and it was without a doubt the right decision for me. I learned an enormous amount, worked with some terrific people, and helped ship a very successful product. You could argue that the ancillary stuff reflected company issues that ultimately led to the company's demise. But I would certainly not have passed up the 3 years I spent there even if I'd known that in 3 years I'd end up looking for a new job. And that's not least because so everyone I worked with did the same thing, and now I'm still working with many of those same people on much of the same technologies.
What was important about the candidate experience? It was clear that the team was interested in working with me and developing me as an engineer, and that they were very bright and working on important problems. That trumped basically everything for me.
I almost didn't work for a company because my experience during an internship was that HR, payroll, and other departments that were not part of my day-to-day job were painful and bureaucratic. I was talked into the job anyway, and it was without a doubt the right decision for me. I learned an enormous amount, worked with some terrific people, and helped ship a very successful product. You could argue that the ancillary stuff reflected company issues that ultimately led to the company's demise. But I would certainly not have passed up the 3 years I spent there even if I'd known that in 3 years I'd end up looking for a new job. And that's not least because so everyone I worked with did the same thing, and now I'm still working with many of those same people on much of the same technologies.
What was important about the candidate experience? It was clear that the team was interested in working with me and developing me as an engineer, and that they were very bright and working on important problems. That trumped basically everything for me.
Because we spend so much time at work and because a bad workplace is such a miserable experience, I think candidates should pay close attention to negative signals, even if they could turn out to be anomalous. Of course, when things go wrong it's certainly important to pay close attention to how that is handled. Basically everything that happens during the interview and recruitment process should be treated as signal even though some of it will be noise.
For employers evaluating a candidate, "if it's not yes it's no" - I would suggest job seekers to have the same attitude. (Unless your current job already sucks.)
For employers evaluating a candidate, "if it's not yes it's no" - I would suggest job seekers to have the same attitude. (Unless your current job already sucks.)
It's chronological, although I did want to emphasize this issue in recruitment.
First impressions count.
It's hard to know what a company is really like without knowing some insiders. Searching on the Internet may find opinions pointing every which way. And then, you meet their recruitment team, and get your first -- and maybe last -- firsthand exposure to the internal workings of the company.
Hiring the right staff is obviously very important. So any issues with the hiring process that cannot be fixed is deeply worrying. Does the company not value hiring? Why can't it be fixed? Who will my co-workers be? What else is broken? etc.
I regret that I didn't walk out during the misaligned interviews, to save everyone's time. I did eventually tell recruiters not to contact me anymore, but that seemed to make them more interested, and I was handed to a different team. (In the end, I picked Netflix anyway, and am very happy I did.)
Netflix recruiting was awesome, and I think other companies can do the same. Don't put up with recruiting problems -- help fix it. It may be your company's first and last impression.
First impressions count.
It's hard to know what a company is really like without knowing some insiders. Searching on the Internet may find opinions pointing every which way. And then, you meet their recruitment team, and get your first -- and maybe last -- firsthand exposure to the internal workings of the company.
Hiring the right staff is obviously very important. So any issues with the hiring process that cannot be fixed is deeply worrying. Does the company not value hiring? Why can't it be fixed? Who will my co-workers be? What else is broken? etc.
I regret that I didn't walk out during the misaligned interviews, to save everyone's time. I did eventually tell recruiters not to contact me anymore, but that seemed to make them more interested, and I was handed to a different team. (In the end, I picked Netflix anyway, and am very happy I did.)
Netflix recruiting was awesome, and I think other companies can do the same. Don't put up with recruiting problems -- help fix it. It may be your company's first and last impression.
I've dealt with many companies large and small (retained recruitment, tech) that have admitted early on to flaws in their hiring process. Typically, I find it's someone in engineering all the way up to the CTO that admits the process is broken, and they generally want to circumvent internal HR processes to get the candidate to their potential boss and co-workers as efficiently as possible.
HR typically wants to control as much of the process as possible, which often means an HR screening first. This tends to turn off engineers considerably, as it's deemed a waste of time, so the first step in the process is perceived negatively and that negative first impression is hard to overcome. The clients I've represented that have the smoothest process are those that use HR to facilitate and provide answers to questions, but to try and limit involvement beyond that.
HR typically wants to control as much of the process as possible, which often means an HR screening first. This tends to turn off engineers considerably, as it's deemed a waste of time, so the first step in the process is perceived negatively and that negative first impression is hard to overcome. The clients I've represented that have the smoothest process are those that use HR to facilitate and provide answers to questions, but to try and limit involvement beyond that.
Do Netflix's interviews have any trick questions (e.g. manhole covers) or coding questions that have nothing to do with the job (e.g. Write a function that can detect a cycle in a linked list)?
I would never interview at major tech' companies because from what I've read of their interview process, it is all about knowing random Computer Science trivia and studying a book of trick questions.
I like more traditional corporations/business who give you questions actually applicable to the job and your experience. Silicon Valley interviews are pretty insufferable, due to their pseudo-intellectual elitism.
Companies should take their interview, and then give it to what they consider their most successful employees. If the employees wouldn't be "hired" then the interview process is completely broken.
I would never interview at major tech' companies because from what I've read of their interview process, it is all about knowing random Computer Science trivia and studying a book of trick questions.
I like more traditional corporations/business who give you questions actually applicable to the job and your experience. Silicon Valley interviews are pretty insufferable, due to their pseudo-intellectual elitism.
Companies should take their interview, and then give it to what they consider their most successful employees. If the employees wouldn't be "hired" then the interview process is completely broken.
I feel your pain on coding questions which have nothing to do with the job, but this can be difficult.
We recently tried to identify such a question, with a scope such that the candidate should take about an hour and a half to complete - where complete also implies documentation, tests, etc. We couldn't find an appropriate question which would be something that would be highly indicative of the specific work they'd be doing that a) Didn't require a ton of domain knowledge (we don't expect people to have that domain knowledge coming in) or b) Would be too specific to particular technologies such as which ORM type library one is using, which type of DB, what libraries, etc.
Typically when I've seen examples of these questions where they are fully relevant they're in a space that's tightly defined - you're using say RoR, MySql, etc and candidates are expected to be proficient in those. That's not us.
We recently tried to identify such a question, with a scope such that the candidate should take about an hour and a half to complete - where complete also implies documentation, tests, etc. We couldn't find an appropriate question which would be something that would be highly indicative of the specific work they'd be doing that a) Didn't require a ton of domain knowledge (we don't expect people to have that domain knowledge coming in) or b) Would be too specific to particular technologies such as which ORM type library one is using, which type of DB, what libraries, etc.
Typically when I've seen examples of these questions where they are fully relevant they're in a space that's tightly defined - you're using say RoR, MySql, etc and candidates are expected to be proficient in those. That's not us.
Can I ask for your thoughts on the cycle in a linked list question?
I asked someone that today, and it didn't go very well. I gave him the hint to start with writing code to print out all of the children of a node, then when that stack overflowed, he was able to make progress.
Do you think there are senior generalists engineers who would be great who could struggle with that question? Its hard for me to put myself in those shoes but I believe it could be possible.
The goal of that question from my perspective is to watch them solve a problem that requires recursion. I've always found that people who do well on that stuff tend to get stuck less designing software in general.
I do worry that it cuts out people who would actually be good.
I'm very interested to hear thoughts on this from others.
I asked someone that today, and it didn't go very well. I gave him the hint to start with writing code to print out all of the children of a node, then when that stack overflowed, he was able to make progress.
Do you think there are senior generalists engineers who would be great who could struggle with that question? Its hard for me to put myself in those shoes but I believe it could be possible.
The goal of that question from my perspective is to watch them solve a problem that requires recursion. I've always found that people who do well on that stuff tend to get stuck less designing software in general.
I do worry that it cuts out people who would actually be good.
I'm very interested to hear thoughts on this from others.
For what it's worth, the solution to that question was an open question in computer science for over ten years, so I would guess that people who get it quickly in an interview are more likely to have heard the answer before than successfully invent the tortoise-and-hare algorithm on the spot.
Further reading on that question in this old thread: https://news.ycombinator.com/item?id=7953725.
In practice, what happens is that we both acknowledge that if this was a real work problem, step 1 is to google it. I then tell the candidate that i'm not going to judge them on the algorithm they use, just their ability to work through the problem. This isn't a whiteboard problem, it's done on a machine.
It's never happened to me yet with this type of problem, but i'd be really impressed if I did run into someone who has the optimal algorithm for this memorized and can code it on demand in an interview. I'd certainly want to check that they haven't spent all of their time just memorizing algorithms and they can still do other things of course.
If this did happen i'd want to validate that they really understand the solution and aren't just spamming it out by rote, but if they've really got a few algorithms in the bank like this i'll just consider this box checked and move onto other considerations.
all I really want to know is if the candidate has the "horsepower" to deal with these sorts of problems, many people don't. someone who can code optimal solutions to these things on demand obviously does.
That said, obviously this is much easier for someone who's dealt with trees and graphs and such a lot before, so it's not ideal. I'd certainly be interested in a better way.
It's never happened to me yet with this type of problem, but i'd be really impressed if I did run into someone who has the optimal algorithm for this memorized and can code it on demand in an interview. I'd certainly want to check that they haven't spent all of their time just memorizing algorithms and they can still do other things of course.
If this did happen i'd want to validate that they really understand the solution and aren't just spamming it out by rote, but if they've really got a few algorithms in the bank like this i'll just consider this box checked and move onto other considerations.
all I really want to know is if the candidate has the "horsepower" to deal with these sorts of problems, many people don't. someone who can code optimal solutions to these things on demand obviously does.
That said, obviously this is much easier for someone who's dealt with trees and graphs and such a lot before, so it's not ideal. I'd certainly be interested in a better way.
Would you accept with full credit an answer like this?
Iterate through the list adding its nodes to a set. If a node is already present when we go to add it, then stop, since we've found a cycle. Otherwise if we reach the end there is no cycle. With a hash set which has O(1) insert and membership check, the algorithm takes O(n) time and space since.
Note that I mean we're adding the nodes themselves to the set, not the element stored by / pointed to by the nodes. This may mean storing a pointer to the node in the set, or some other kind of object identifier.
I think this solution is fair to expect from anyone, including the caveat about node identity. Plus a candidate who already knows tortoise and hare should be able to come up with this when asked to solve the problem another way ("what's the simplest, most naive solution you can think of?"). I am not sure that I would expect anyone to come up with solutions beyond this one and the O(n^2) solution during an interview. I think those solutions correspond to knowledge that everyone should have in their working set. "Have I seen this thing before" is a pretty simple application of data structures. The O(n^2) solution trades off storage to track whether a node has been seen with determining it on demand in duplicate each time by traversing the list from the beginning repeatedly.
(If solutions are fair game that involve modifying the list, such as reversing it, or assuming that list nodes can be marked as seen, then make sure the boundary of what's allowed is clearly communicated. Make sure that the candidate does not neglect to consider a category of solutions by mistaking it as out of bounds. Candidates who are asked to design an algorithm to process a data structure cannot usually modify that structure to make the problem easier, so if this is something that you want to encourage, then you might tip the candidate in that direction by asking them to write the definition of their list node, and encouraging them to implement the node however they want as long as it meets your definition of being a linked list. Conversely if this is out of bounds, it might be best to provide the definition of a list node.)
Anyway, it seems like a fair simple interview question along the lines of a medium difficulty FizzBuzz, if the answers above give full credit. I don't think effective software engineers would be tripped up by this. One area of concern might be people looking for overly fancy solutions without trying "er... can I just track what nodes I've seen in a set?", but finding simple solutions is part of being a good engineer. I think there are better questions than this one: (1) it's too easy to memorize all the answers (2) it's already well known by this point (3) I have not heard of a good way to build on the question to make it challenging and interesting for high performing candidates. This might be an OK intro question before moving onto a harder one. I've never asked this in an interview - just going by instinct.
Iterate through the list adding its nodes to a set. If a node is already present when we go to add it, then stop, since we've found a cycle. Otherwise if we reach the end there is no cycle. With a hash set which has O(1) insert and membership check, the algorithm takes O(n) time and space since.
Note that I mean we're adding the nodes themselves to the set, not the element stored by / pointed to by the nodes. This may mean storing a pointer to the node in the set, or some other kind of object identifier.
I think this solution is fair to expect from anyone, including the caveat about node identity. Plus a candidate who already knows tortoise and hare should be able to come up with this when asked to solve the problem another way ("what's the simplest, most naive solution you can think of?"). I am not sure that I would expect anyone to come up with solutions beyond this one and the O(n^2) solution during an interview. I think those solutions correspond to knowledge that everyone should have in their working set. "Have I seen this thing before" is a pretty simple application of data structures. The O(n^2) solution trades off storage to track whether a node has been seen with determining it on demand in duplicate each time by traversing the list from the beginning repeatedly.
(If solutions are fair game that involve modifying the list, such as reversing it, or assuming that list nodes can be marked as seen, then make sure the boundary of what's allowed is clearly communicated. Make sure that the candidate does not neglect to consider a category of solutions by mistaking it as out of bounds. Candidates who are asked to design an algorithm to process a data structure cannot usually modify that structure to make the problem easier, so if this is something that you want to encourage, then you might tip the candidate in that direction by asking them to write the definition of their list node, and encouraging them to implement the node however they want as long as it meets your definition of being a linked list. Conversely if this is out of bounds, it might be best to provide the definition of a list node.)
Anyway, it seems like a fair simple interview question along the lines of a medium difficulty FizzBuzz, if the answers above give full credit. I don't think effective software engineers would be tripped up by this. One area of concern might be people looking for overly fancy solutions without trying "er... can I just track what nodes I've seen in a set?", but finding simple solutions is part of being a good engineer. I think there are better questions than this one: (1) it's too easy to memorize all the answers (2) it's already well known by this point (3) I have not heard of a good way to build on the question to make it challenging and interesting for high performing candidates. This might be an OK intro question before moving onto a harder one. I've never asked this in an interview - just going by instinct.
Yes, someone who can code the solution you describe on demand would be a flying colors pass for me.
I agree with you that there are probably better questions. As you say, I'm looking for a medium difficulty fizzbuzz. I also agree with you that this is not going to be challenging and interesting for high performing candidates.
Incidentally, if someone has managed to memorize the solution to this and other algorithm problems I would consider that a pass. just the ability to do that is enough. there's enough code involved that they have to understand the problem pretty well to memorize it, and its the ability to understand that i'm interested in. (Barring some extreme outlier with super memory but bad other skills, but I'll have to detect that with other questions).
I agree with you that there are probably better questions. As you say, I'm looking for a medium difficulty fizzbuzz. I also agree with you that this is not going to be challenging and interesting for high performing candidates.
Incidentally, if someone has managed to memorize the solution to this and other algorithm problems I would consider that a pass. just the ability to do that is enough. there's enough code involved that they have to understand the problem pretty well to memorize it, and its the ability to understand that i'm interested in. (Barring some extreme outlier with super memory but bad other skills, but I'll have to detect that with other questions).
The problem I see with your question is that you have a bias towards a solution.
"The goal of that question from my perspective is to watch them solve a problem that requires recursion"
I wouldn't use recursion for my solution. It takes up stack space for no reason. If I'm going to be allowed to use more space, I'd just loop through the list, add them to a set, and check if I've already seen it. No recursion, but extra space. Is it more space than another stack frame? Depends on the type of set I'm using. But at least I know I won't blow up the stack (maybe the heap :-)
Since you are asking for opinions from others, I'm going to assume you wouldn't be upset with me solving it this way. So am I less of an engineer because I didn't immediately go for recursion?
With that said, everyone has a baseline - answers they expect to see. But everyone has to keep an open mind.
My company is trying to come up with a corpus of questions and answers to those questions at the junior, normal, and senior level. I've voiced my opinion that it is a slippery slope. If you get someone who isn't a skilled interviewer, and the interviewee doesn't use one of the prescribed 3 answers, what happens to that candidate? Granted it is one data point in the loop, and not the only data point. But as I stated, it becomes easier to be "lazy" during the interview.
"The goal of that question from my perspective is to watch them solve a problem that requires recursion"
I wouldn't use recursion for my solution. It takes up stack space for no reason. If I'm going to be allowed to use more space, I'd just loop through the list, add them to a set, and check if I've already seen it. No recursion, but extra space. Is it more space than another stack frame? Depends on the type of set I'm using. But at least I know I won't blow up the stack (maybe the heap :-)
Since you are asking for opinions from others, I'm going to assume you wouldn't be upset with me solving it this way. So am I less of an engineer because I didn't immediately go for recursion?
With that said, everyone has a baseline - answers they expect to see. But everyone has to keep an open mind.
My company is trying to come up with a corpus of questions and answers to those questions at the junior, normal, and senior level. I've voiced my opinion that it is a slippery slope. If you get someone who isn't a skilled interviewer, and the interviewee doesn't use one of the prescribed 3 answers, what happens to that candidate? Granted it is one data point in the loop, and not the only data point. But as I stated, it becomes easier to be "lazy" during the interview.
>So am I less of an engineer because I didn't immediately go >for recursion?
No, not at all. a stack is a stack, whether it's the call stack or one you maintain in code.
Its not the recursion that's important to me, it's holding a problem of moderate complexity in your head in order to be able to come up with a solution. Problems that lend themselves to recursion seem to present a bar that some engineers struggle with, and others find easier, in my anecdotal experience.
I know I said recursion is important all over the place, clearly my thinking is sloppy on this and needs to improve.
I have this idea that there is a class of problem, that lends itself to recursion, that separates the wheat from the chaff in some ways. maybe that's nonsense.
What I really want to test for is the ability to juggle abstractions while working through code problems. there's probably a better way to do it.
Thinking about this corpus of questions and answers, I guess the common idea of fixing broken code might have a bit more merit because it removes the risk of an interview focusing too much on judging the approach and turning it into a trivia contest (have you seen this before and do you remember how to do it).
No, not at all. a stack is a stack, whether it's the call stack or one you maintain in code.
Its not the recursion that's important to me, it's holding a problem of moderate complexity in your head in order to be able to come up with a solution. Problems that lend themselves to recursion seem to present a bar that some engineers struggle with, and others find easier, in my anecdotal experience.
I know I said recursion is important all over the place, clearly my thinking is sloppy on this and needs to improve.
I have this idea that there is a class of problem, that lends itself to recursion, that separates the wheat from the chaff in some ways. maybe that's nonsense.
What I really want to test for is the ability to juggle abstractions while working through code problems. there's probably a better way to do it.
Thinking about this corpus of questions and answers, I guess the common idea of fixing broken code might have a bit more merit because it removes the risk of an interview focusing too much on judging the approach and turning it into a trivia contest (have you seen this before and do you remember how to do it).
You are trying to measure what?
I'm going to assume your answer is "on the job performance". If not, this is going to be a difficult conversation, and I'd ask why you are trying to measure for something you aren't going to be paying for.
The best predictor of on the job performance is ... on the job performance. Everyone but the most junior person has experience. Look at that.
All of these exam type questions usually rely on knowing a trick, or being recently well versed. I TA'd a graduate course in Algorithms. That's rather relevant, I would think, since you aren't offered that if you don't have ability. Yet you know the last time I've done, say, dynamic programming? It's been awhile. I know about it, I know when to decide whether to pull it out, but ask me to do it, in a high pressure interview (all interviews are high pressure), and well, I'll probably fail. I'm working on other things like Bayesian inference. Bet you'd fail doing that stuff, even though it is just simple multiplications and such, when you get down to the implementation. Unless, of course, you are working on that sort of stuff right now.
I find the situation in SV somewhat ridiculous. To go out and interview means a lot of prep. Google recommends spending a month reviewing algorithms before applying. You know, I have an actual job, and I have open source side projects, and I have a family, and hobbies, and an old dog I want to spend all my time with. It is trivial to find out my skills by looking at what I have done and asking me questions about it. Have me give you a 1-2 hour tech talk, for example (I like public speaking, most don't so that is not a universal solution). Have me write some code with you, if you must. I work at a very high level, but I am not necessarily 'clever' at seeing the right trick in 10 seconds under pressure in an interview.
Also, how important is that sort of thing, really? For some jobs it is, undoubtedly. If you want me to write a load balancer for your cloud infrastructure, there are some algorithms I need to understand. Even then, not knowing something now is not evidence I can't do the job. I can learn - it's how I've done everything up to now. I can learn your thing too. More importantly (to my mind) - am I a hard worker? Can I mentor others? Can I lead a team? Can I put a schedule together, and recognize when that is appropriate and not appropriate? Can I make a budget? Can I talk to clients? Do I meet my deadlines? Do I solve problems - not implement the cards in this sprint - but see friction of some sort at work and engineer a solution? Do my peers like working with me? Do I get shit done? Is my code maintainable, readable, modular, commented? Can I write? Can I teach? Can I work with the CEO?
I've been to so many interviews where they don't even try to learn any of that latter stuff, where they show no interest in what I have done, where they don't try to figure out if I can do the actual job they are doing, but are deeply interested in if I can program a smart pointer, from scratch, to some arbitrary set of requirements. It is all just deeply puzzling to me.
I'm going to assume your answer is "on the job performance". If not, this is going to be a difficult conversation, and I'd ask why you are trying to measure for something you aren't going to be paying for.
The best predictor of on the job performance is ... on the job performance. Everyone but the most junior person has experience. Look at that.
All of these exam type questions usually rely on knowing a trick, or being recently well versed. I TA'd a graduate course in Algorithms. That's rather relevant, I would think, since you aren't offered that if you don't have ability. Yet you know the last time I've done, say, dynamic programming? It's been awhile. I know about it, I know when to decide whether to pull it out, but ask me to do it, in a high pressure interview (all interviews are high pressure), and well, I'll probably fail. I'm working on other things like Bayesian inference. Bet you'd fail doing that stuff, even though it is just simple multiplications and such, when you get down to the implementation. Unless, of course, you are working on that sort of stuff right now.
I find the situation in SV somewhat ridiculous. To go out and interview means a lot of prep. Google recommends spending a month reviewing algorithms before applying. You know, I have an actual job, and I have open source side projects, and I have a family, and hobbies, and an old dog I want to spend all my time with. It is trivial to find out my skills by looking at what I have done and asking me questions about it. Have me give you a 1-2 hour tech talk, for example (I like public speaking, most don't so that is not a universal solution). Have me write some code with you, if you must. I work at a very high level, but I am not necessarily 'clever' at seeing the right trick in 10 seconds under pressure in an interview.
Also, how important is that sort of thing, really? For some jobs it is, undoubtedly. If you want me to write a load balancer for your cloud infrastructure, there are some algorithms I need to understand. Even then, not knowing something now is not evidence I can't do the job. I can learn - it's how I've done everything up to now. I can learn your thing too. More importantly (to my mind) - am I a hard worker? Can I mentor others? Can I lead a team? Can I put a schedule together, and recognize when that is appropriate and not appropriate? Can I make a budget? Can I talk to clients? Do I meet my deadlines? Do I solve problems - not implement the cards in this sprint - but see friction of some sort at work and engineer a solution? Do my peers like working with me? Do I get shit done? Is my code maintainable, readable, modular, commented? Can I write? Can I teach? Can I work with the CEO?
I've been to so many interviews where they don't even try to learn any of that latter stuff, where they show no interest in what I have done, where they don't try to figure out if I can do the actual job they are doing, but are deeply interested in if I can program a smart pointer, from scratch, to some arbitrary set of requirements. It is all just deeply puzzling to me.
I understand what you mean about ridiculous SV interview practices. And your point that all we should really be measuring is on the job performance is an important one.
All I'm really going for is to ask someone to write some code live, on their laptop with their tools, so I can watch how they debug, how they think through things, etc. I want the problem to be hard enough that the person has to model execution in their head and that it's challenging to do so.
I have found that there are people who can code decently well but get badly stuck when the complexity hits a certain level. I'm trying to not hire them in senior positions.
For example, I had a recent project where we were analyzing user data and producing a bunch of edges representing potential connections detected between users, as a way of sniffing out fraud rings.
One feature associated with this was a banning UI, allowing loss prevention types to navigate through the graph, select groups of users according to certain criteria, and generally look for patterns that are evidence of fraud rings manually, to supplement the automatically generated analysis.
There are a lot of front end people who will go into brainlock on this kind of thing. I need to make sure I have some people around who don't.
When making senior hires, I want people who can write code for this sort of thing without making a huge mess or just getting stuck for weeks.
Presenting a real sample from a problem like this needs way too much context though.
I'm going to keep thinking about how to precisely define the type of task that i'm really talking about here. My fuzzy definition about ability to model execution of X complexity in one's head is obviously weak and probably flat out wrong.
All I'm really going for is to ask someone to write some code live, on their laptop with their tools, so I can watch how they debug, how they think through things, etc. I want the problem to be hard enough that the person has to model execution in their head and that it's challenging to do so.
I have found that there are people who can code decently well but get badly stuck when the complexity hits a certain level. I'm trying to not hire them in senior positions.
For example, I had a recent project where we were analyzing user data and producing a bunch of edges representing potential connections detected between users, as a way of sniffing out fraud rings.
One feature associated with this was a banning UI, allowing loss prevention types to navigate through the graph, select groups of users according to certain criteria, and generally look for patterns that are evidence of fraud rings manually, to supplement the automatically generated analysis.
There are a lot of front end people who will go into brainlock on this kind of thing. I need to make sure I have some people around who don't.
When making senior hires, I want people who can write code for this sort of thing without making a huge mess or just getting stuck for weeks.
Presenting a real sample from a problem like this needs way too much context though.
I'm going to keep thinking about how to precisely define the type of task that i'm really talking about here. My fuzzy definition about ability to model execution of X complexity in one's head is obviously weak and probably flat out wrong.
The best questions have levels. Speaking to recursion specifically I had Flood Fill as a question the last time I interviewed. I solved it with recursion as it's the more ... "elegant" method. Then the interviewer asked about other ways to solve it, which went to iteration. After which we could briefly chat about stacks, bounds checking, etc.
So when it comes to "junior, normal, senior" they dont have to be different questions, in my opinion. Opened ended questions give flexibility for the candidates inclination and complexity in answering. Depending on how the candidates doing add increasing complexity, discuss improvements, or try again with a simpler setup. Something like Word Count can go many different ways; If they like C talk about char and buffers and syscalls. If they like javascript, well then you can make fun of their tail call recursion.
So when it comes to "junior, normal, senior" they dont have to be different questions, in my opinion. Opened ended questions give flexibility for the candidates inclination and complexity in answering. Depending on how the candidates doing add increasing complexity, discuss improvements, or try again with a simpler setup. Something like Word Count can go many different ways; If they like C talk about char and buffers and syscalls. If they like javascript, well then you can make fun of their tail call recursion.
It depends on how you ask it. If you ask it as an exploratory question, it can be useful. If you ask it as a question where you're expecting the "right answer", it's awful for interviewing, because the insight is difficult to spontaneously come up with, yet easy to have already encountered online. Neither result is very informative.
It seems to me to still be very poorly understood in general that the purpose of a question in an interview is not to see if the candidate gets the right answer, but to see how they function. (In those interested enough to read the discussion this deeply it's probably somewhat better understood.)
It seems to me to still be very poorly understood in general that the purpose of a question in an interview is not to see if the candidate gets the right answer, but to see how they function. (In those interested enough to read the discussion this deeply it's probably somewhat better understood.)
The reason I ask the question is that I want to see if the person can handle thinking about recursion, and how their debugging process works, and how they built toward a solution.
I always stipulate that they can use whatever brute force approach they want, and that i'm not judging on the algorithm. (Though we'll then discuss the big O complexity of what they've done and i'll ask them to brainstorm some avenues for optimization).
The main drawback of this particular problem is that it's biased toward people with more formal CS experience who have probably seen more tree and graph stuff, when i'm not really trying to measure for that experience directly.
I'd be interested in a problem that doesn't have that aspect but still takes up a fair bit of brain space when thinking through. What I mean by that is that when you're trying to build and debug something recursive, you have to hold in your mind some representation of what the stack will be at various points, and not everyone has a great aptitude for that.
I always stipulate that they can use whatever brute force approach they want, and that i'm not judging on the algorithm. (Though we'll then discuss the big O complexity of what they've done and i'll ask them to brainstorm some avenues for optimization).
The main drawback of this particular problem is that it's biased toward people with more formal CS experience who have probably seen more tree and graph stuff, when i'm not really trying to measure for that experience directly.
I'd be interested in a problem that doesn't have that aspect but still takes up a fair bit of brain space when thinking through. What I mean by that is that when you're trying to build and debug something recursive, you have to hold in your mind some representation of what the stack will be at various points, and not everyone has a great aptitude for that.
As always, it depends on the group or team you are applying for. Some groups actually have a lot of applied computer science concepts and benefit from these type of questions. On my team, Web UI, we typically try to ask questions that pertain to the tasks they would encounter day to day.
I'm a hiring manager at Netflix and spend a bunch of time talking to other hiring managers at Netflix.
I don't know anyone who does trick questions (most people I know find them anathema, and even Google -- famous for them -- acknowledges they're useless). I definitely do know some people ask the 'cycle in a linked list' question (or others like it); honestly, I don't see a problem with that set of questions.
I don't know anyone who does trick questions (most people I know find them anathema, and even Google -- famous for them -- acknowledges they're useless). I definitely do know some people ask the 'cycle in a linked list' question (or others like it); honestly, I don't see a problem with that set of questions.
even Google -- famous for them -- acknowledges they're useless
When I interviewed at Google (four years ago now I think) there were no trick questions. Hard questions? Yes. But none that had "gotcha" answers that you'd either have to know already or be some kind of genius to come up with on the spot in an interview.
When I interviewed at Google (four years ago now I think) there were no trick questions. Hard questions? Yes. But none that had "gotcha" answers that you'd either have to know already or be some kind of genius to come up with on the spot in an interview.
I did not get trick questions, which is good. The focus was on if we were a good fit for each other. I wanted to know as much detail as possible about projects I could begin work on, to see how much value I could bring, and to confirm that I could perform. We spent a lot of time discussing that.
Netflix does like to hire senior staff, who often have previous public accomplishments they can refer to, and discuss in interviews.
Netflix does like to hire senior staff, who often have previous public accomplishments they can refer to, and discuss in interviews.
Brendan, I'm interested in your reaction to what a few other posters wrote and floated to the top regarding very aggressive, tactless hiring manager gleefully indulging about firing people or brow beating about quick firings due to performance, seems several people have the exact same experience and it belies your post a bit.
I was surprised, but the original poster followed up to say that that person has left the company. Would be helpful if people can note when the bad experiences happened.
I got some blunt answers (reinforcing what was in the culture deck), which felt different than the happy-talk you can get with other companies, but I appreciated the honesty. I didn't get anything tactless.
I got some blunt answers (reinforcing what was in the culture deck), which felt different than the happy-talk you can get with other companies, but I appreciated the honesty. I didn't get anything tactless.
I'm a recruiter and have worked at a few startups. My wife is looking for a new role and recently had an interview where they sent her questions and asked her to record answers and send them back. This blew my mind. What a horrible experience.
For me, the interview is absolutely 2 ways. I spend just as much time answering questions and talking about our team as I do asking questions. There are times where I walk away wishing I had done a better job, but you always HAVE to care about candidate experience.
For me, the interview is absolutely 2 ways. I spend just as much time answering questions and talking about our team as I do asking questions. There are times where I walk away wishing I had done a better job, but you always HAVE to care about candidate experience.
Customer satisfaction is disproportionately tied to the sales experience. I still resent the guys who sold me my Toyota. It stands to reason that how we are recruited also directly impacts how we feel about the company after we join.
I'm still angry about about a 96 Jeep I bought new. A little untruth by the sales guy about a minor feature, that was important to me, has turned me off all jeep products ever since. Nearly twenty years later I cannot look at any jeep one without remembering that profound disappointment when my new vehicle was not as I had expected.
I've been beating this drum for a bit now at my company. My employer is extremely prestigious for it's main field but largely unknown in the software engineering world. It doesn't help that we're literally across the street from a handful of household name level software companies. And yet, a common complaint (I had it myself when I joined) was that people feel put off by the hiring process that we have. To make it worse, I know for a fact that this sentiment is spreading via word of mouth locally.
My point to the folks at my company is that we need to be improving our brand in the eyes of software professionals, not making it worse. To do this we need to present an image that's not just bog standard, mid-sized bureaucracy style hiring.
My point to the folks at my company is that we need to be improving our brand in the eyes of software professionals, not making it worse. To do this we need to present an image that's not just bog standard, mid-sized bureaucracy style hiring.
Have to agree with this. I've turned down offers, or stopped the process, due to a bad interview experience. It's not a good signal, necessarily, but it is the only one that we have, as to what it might be like to work for you. If you can't get this together, what else do you do badly? I recognize from all these comments that companies can be quite nice internally but just suck at interviews, but what else do you have to go on. If my potential future boss finds his phone more interesting than talking to me during the interview for example, why would I accept that job offer, especially in today's market when my phone is literally pinging with interview opportunities as I interview with you?
And I that perhaps a bit more subtly than it appears. This frantic search for warm bodies can make you feel pretty desirable and important, and I think it is easy for that to skew your thinking a bit and to over-interpret small things that happen during interviews. But, that is the reality of human behavior, and you cannot ignore it.
And I that perhaps a bit more subtly than it appears. This frantic search for warm bodies can make you feel pretty desirable and important, and I think it is easy for that to skew your thinking a bit and to over-interpret small things that happen during interviews. But, that is the reality of human behavior, and you cannot ignore it.
What other big companies have awful candidate experiences?
I recently went through a job hunt and two stand out in my mind: Red Hat and Rackspace.
Neither one of them insulted me or anything, per se. Rather, I saw that they were looking for engineering people on a couple different job boards and instructed you to apply through their 3rd party system. I had done a lot of work lately in virtualization and distributed computing and these guys are good open source citizens there, so I figured I'd apply. Two months have gone by now and still no word -- my status on their website remains "resume received".
Makes me wonder how they ever manage to hire anyone at all. It's really soured me both to them and companies that use that shitty application system in general. At this point I figure anyone who uses it (including Amazon and Oracle) aren't even worth wasting my time messing around with.
I recently went through a job hunt and two stand out in my mind: Red Hat and Rackspace.
Neither one of them insulted me or anything, per se. Rather, I saw that they were looking for engineering people on a couple different job boards and instructed you to apply through their 3rd party system. I had done a lot of work lately in virtualization and distributed computing and these guys are good open source citizens there, so I figured I'd apply. Two months have gone by now and still no word -- my status on their website remains "resume received".
Makes me wonder how they ever manage to hire anyone at all. It's really soured me both to them and companies that use that shitty application system in general. At this point I figure anyone who uses it (including Amazon and Oracle) aren't even worth wasting my time messing around with.
The reality is that most job postings aren't tied to actual jobs that need to be filled right now. These postings just hang out there on websites and passively gather resumes. Occasionally someone actually looks at the applicant pool for 10 minutes and picks a few. The rest are never responded to or dealt with in any way. You'll probably never get a response, or you'll get one three months after you've started another job.
My personal favorite experience was being called (on my desk phone) by a recruiter in response to an application that I submitted, for a different job at the same company. I had applied 4-5 months previously, and had been working there for at least 3 months. One hand seriously has no idea what the other hand is up to.
I sympathize with you, this can feel pretty bad as an applicant (especially if you've done a lot of work on your resume / cover letter just for that job). Once I realized how things work on the back end, I stopped caring or even thinking about jobs until an actual human reached out to me.
My personal favorite experience was being called (on my desk phone) by a recruiter in response to an application that I submitted, for a different job at the same company. I had applied 4-5 months previously, and had been working there for at least 3 months. One hand seriously has no idea what the other hand is up to.
I sympathize with you, this can feel pretty bad as an applicant (especially if you've done a lot of work on your resume / cover letter just for that job). Once I realized how things work on the back end, I stopped caring or even thinking about jobs until an actual human reached out to me.
Current rackspace employee - ime, we want you to apply through our system (here http://rackspace.jobs/). If you're getting no reply from us at all, then there's a good chance that no one here has got your CV.
(Or the US does thing entirely differently - I only work in the UK business unit, so you never know)
(Or the US does thing entirely differently - I only work in the UK business unit, so you never know)
That is the system I used.
I'm sure no one actually got/read my CV. It irritates me to no end that I can't talk to an actual hiring manager, can't provide a cover letter, etc.
I'm sure no one actually got/read my CV. It irritates me to no end that I can't talk to an actual hiring manager, can't provide a cover letter, etc.
Hiring is a two-way street. The candidate is obviously trying to sell himself or herself, but the company should do the same. Some companies like they are doing you favor by hiring you. I cannot imagine they get great talent.
I think a lot of candidates also forget this, partly because they "need a job".
You know the longer I work in the industry that more one thing has becomes apparent. There are afaik no "dream" company which also are of sufficient size, except maybe Pixar (My theory is that if you work with products aimed at children it keeps your soul from corrupting)
Google started as a Xanadu everyone wanted to job for, but more and more tales about bureaucracy and people jocking for power keeps coming into light.
Apple has for long time seemed to be a very demanding employer where you sign away your life to the company the day you start working.
Microsoft was the original power employer but for a long time seems to have been paralyzed by department infighting and middle management.
Valve long claimed to have a unique and awesome culture but other accords has described it as being dysfunctional an ineffective.
I'm not sure whether Facebook is good or bad or has corrupted at this point.
Anyways, the point seem to be that the bigger the company the more business people and management who will corrupt the company. The more employees the more rules and bureaucracy is needed to enforce them.
It certainly is possible to avoid this but it seems the bigger the company the faster the entropy slide into oblivion and the more energy it takes to counteract it... and not many do. The "Bozo explosion" as Jobs described also was very apt.
Google started as a Xanadu everyone wanted to job for, but more and more tales about bureaucracy and people jocking for power keeps coming into light.
Apple has for long time seemed to be a very demanding employer where you sign away your life to the company the day you start working.
Microsoft was the original power employer but for a long time seems to have been paralyzed by department infighting and middle management.
Valve long claimed to have a unique and awesome culture but other accords has described it as being dysfunctional an ineffective.
I'm not sure whether Facebook is good or bad or has corrupted at this point.
Anyways, the point seem to be that the bigger the company the more business people and management who will corrupt the company. The more employees the more rules and bureaucracy is needed to enforce them.
It certainly is possible to avoid this but it seems the bigger the company the faster the entropy slide into oblivion and the more energy it takes to counteract it... and not many do. The "Bozo explosion" as Jobs described also was very apt.
Is having a "high performance culture" a subtle way of saying they fire people very quickly for not producing enough results?
I've already mentioned that the director of talent acquisition was part of my interview process. She gleefully told me stories of firing people. It was not "We monitor performance and those that do not meet our required level are fired" it was more like "I overheard an engineer say something and fired him on the spot." As well as "we had people doing job X because they were the best at X. Once that project was finished, we fired them."
The last story I mention is especially concerning since, at least in NY, if a company has a single project they need completed, they hire consultants. Consultants are paid very well (much more than even Netflix will pay) as compensation for the risk of being a consultant (i.e., no health insurance, no implicit or explicit agreement that the work will continue for more than a single project).
The last story I mention is especially concerning since, at least in NY, if a company has a single project they need completed, they hire consultants. Consultants are paid very well (much more than even Netflix will pay) as compensation for the risk of being a consultant (i.e., no health insurance, no implicit or explicit agreement that the work will continue for more than a single project).
Yes. It is one of the few companies I've worked at where I saw substandard engineers get fired for being substandard. At most companies, they just shuffle substandard engineers around into a role where they won't cause too much damage.
I assume that also means you see engineers who are not substandard get fired for being substandard?
I don't think it's hard to imagine a great developer performing poorly because either the role or company is a poor fit.
I don't think it's hard to imagine a great developer performing poorly because either the role or company is a poor fit.
In that situation, they are still "substandard". Ideally there would be some mentoring process that happens to try and get the employee on the right track. And a good recruiting process should minimize the number of employees who are a bad fit for whatever reason so this doesn't happen often. But at the end of the day, it really isn't good for the employee or employer to continue a relationship which isn't fruitful.
Indeed I would agree with this, I just thought the comment I replied to was disingenuous to only mention substandard engineers getting fired, when it really is engineers who are underperforming getting fired.
It just makes it seem as though getting fired implies you are a bad engineer, and not getting fired means you are somehow better than those who got fired.
It just makes it seem as though getting fired implies you are a bad engineer, and not getting fired means you are somehow better than those who got fired.
Essentially it's a culture of elitism. Reminds me of Ivy League. It can work, but it's hard to scale and in my experience it's very hard to avoid a monoculture.
How diverse is the population of engineers at Netflix compared to other public tech companies at a similar stage?
A high-performing culture that emphasizes mentorship is better IMO.
How diverse is the population of engineers at Netflix compared to other public tech companies at a similar stage?
A high-performing culture that emphasizes mentorship is better IMO.
It drives off a reasonable number of high-performing people as well, though obviously not all. One of the problems systems like stack ranking have encountered is that some proportion of people who are really good and not the intended target of the system end up very stressed out by it. Varying reasons: some people underestimate their own skills, some are worried about the system's false-positive rate, some are stressed out by worries about coworkers being fired even if not worried about their own job, etc.
[deleted]
My second hand experience says that they are very prone to firing people.
At first glance this seems good, because I've certainly worked places where dead weight was permitted and there seemed to be no getting rid of them.
The problem is: how do you know which people are good? I believe you can come to pretty accurate conclusions with the right people in place at each level of your hierarchy. However, one wrong person can completely skew your perception of who is doing good work.
I've also never seen a metrics-based review system that was actually designed for measuring humans. It must work really well on the robots that Google tests it on, but people don't map to 1-5 point scales or bell curves as well as you might think.
At first glance this seems good, because I've certainly worked places where dead weight was permitted and there seemed to be no getting rid of them.
The problem is: how do you know which people are good? I believe you can come to pretty accurate conclusions with the right people in place at each level of your hierarchy. However, one wrong person can completely skew your perception of who is doing good work.
I've also never seen a metrics-based review system that was actually designed for measuring humans. It must work really well on the robots that Google tests it on, but people don't map to 1-5 point scales or bell curves as well as you might think.
On a good team of engineers, I think a consensus generally builds when someone is not performing at the necessary level. Either you are constantly fixing their code, or they are slowing down the team because they cannot produce fast enough. Eventually this will bubble up to the manager, and they can then decide to shuffle them around, mentor them, put them on an improvement plan, or let them go.
Perhaps, if you work on a team of peers. I'm not speaking from personal experience in terms of managerial problems, but I have often been the only person doing my sort of work, which makes peer review challenging.
And I don't think that Netflix shuffles, mentors or warns people -- I think they just bounce you out of the company. It's been put to me as "they pay top of market, so they shouldn't have to deal with any personnel issues."
And I don't think that Netflix shuffles, mentors or warns people -- I think they just bounce you out of the company. It's been put to me as "they pay top of market, so they shouldn't have to deal with any personnel issues."
This is my issue with it as well. With perfect knowledge it sounds wonderful, but we all know how political situations can cloud people's judgment in an organizational context.
I mean think of it, have they literally never made a mistake here? Well, what if you're that mistake? Tough shit, here's 50 grand (made up number), go be unemployed now.
I mean think of it, have they literally never made a mistake here? Well, what if you're that mistake? Tough shit, here's 50 grand (made up number), go be unemployed now.
Are engineers constantly afraid of losing their jobs? How does this affect their willingness to accept risk?
I think you might be confusing "fires low performers" with "fires people who have occasional misses." There's a world of difference between the two.
I have a few friends who I worked with at a large company, the kind with a large bureaucratic, broken management system that shuffles around incompetence without ever purging it. They went on to work at Netflix and they tell me how much they love it. They no longer have to deal with terminally incompetent divisions. They're top performers; there's no fear. If Netflix were stupid enough to fire them they'd instantly be buried in new opportunity. Of course, Netflix isn't that stupid.
Consider the economic incentives: A strong will-fire policy is a great negative incentive to prevent incompetent hires in the first place. It's not so scary if you're competent and capable -- and that's precisely the kind of people a company will want to hire..
I have a few friends who I worked with at a large company, the kind with a large bureaucratic, broken management system that shuffles around incompetence without ever purging it. They went on to work at Netflix and they tell me how much they love it. They no longer have to deal with terminally incompetent divisions. They're top performers; there's no fear. If Netflix were stupid enough to fire them they'd instantly be buried in new opportunity. Of course, Netflix isn't that stupid.
Consider the economic incentives: A strong will-fire policy is a great negative incentive to prevent incompetent hires in the first place. It's not so scary if you're competent and capable -- and that's precisely the kind of people a company will want to hire..
I could see having that perception if you were coming from a large company that never fires anyone.
I can say that for some people, it is absolutely scary, even if you are competent and capable. For example: - You suffer from imposter syndrome. Not that uncommon. - The companies you work for have fired people regularly (read: startups). You notice these people are not always incompetent, but more often bad at politics or unlucky. - You have others to support where the risk of being fired just isn't worth it.
Or, put it another way. Incoming netflix hires already have this expectation, so you'd expect the incompetent to self-select, as you've suggested. Yet netflix is reportably still firing often, which suggests one of the following is happening: 1) people who are so incompetent that they don't know they are incompetent are getting through netflix's hiring process 2) something else is happening and incoming netflix hires should absolutely be worried about being fired.
I can say that for some people, it is absolutely scary, even if you are competent and capable. For example: - You suffer from imposter syndrome. Not that uncommon. - The companies you work for have fired people regularly (read: startups). You notice these people are not always incompetent, but more often bad at politics or unlucky. - You have others to support where the risk of being fired just isn't worth it.
Or, put it another way. Incoming netflix hires already have this expectation, so you'd expect the incompetent to self-select, as you've suggested. Yet netflix is reportably still firing often, which suggests one of the following is happening: 1) people who are so incompetent that they don't know they are incompetent are getting through netflix's hiring process 2) something else is happening and incoming netflix hires should absolutely be worried about being fired.
It's #1. Hiring is hard; everyone makes mistakes. Or sometimes people simply don't perform well in certain roles. Their deck goes into detail on this point IIRC. Try to fix it and if you fail, acknowledge the failure and move on.
Acknowledging that you will need to fire some portion of those you hire is an adult approach to the issue. Likewise from an employee's perspective. It's not a big deal to plan for things possibly not working out.
Acknowledging that you will need to fire some portion of those you hire is an adult approach to the issue. Likewise from an employee's perspective. It's not a big deal to plan for things possibly not working out.
I searched for the phrase "high performance culture" in the article and couldn't find it. Was it edited after you read it? He does talk about "performance engineering", which basically means "make video streaming work really fast".
Can anyone comment on Netflix's backend architecture?
Can anyone comment on Netflix's backend architecture?
It is implied by the summary slides, but the phrase can be seen exactly as stated in the title of slide 38 (the last of the slides on this topic, starting on slide 18), "Our High Performance Culture Not Right for Everyone.
Okay thanks. I only read the article, not the slide deck.
Hopefully "high performance culture" isn't a synonym for "sweatshop".
Hopefully "high performance culture" isn't a synonym for "sweatshop".
So... what happens if an employee gets sick or has personal issues that lead to less than stellar performance? Termination?
Most people get a decent severance package though, so it's a win-win.
Yup. They're pretty open about that in some presentations I've seen.
See slides 23 and 25. http://www.slideshare.net/mobile/reed2001/culture-1798664
The slides have 10.4 million views! Are there even that many programmers in the US ?
Two problems with your logic:
1) A view is an action, not a person.
2) International viewers can view the URL even if there is much less of a chance it will be relevant to their job search
In addition to what thephyber said, the Netflix culture doc has been very widely read across many industries as exemplary of a high performance culture. Similarly, I'm not in the shoe sales business but I've read the Zappos Core Values[0] as well.
[0] http://about.zappos.com/our-unique-culture/zappos-core-value...
[0] http://about.zappos.com/our-unique-culture/zappos-core-value...
I was reading through the culture deck and I love The Values. I even like the idea of regularly letting people go who are not contributing to the success of the company.
However, there were a few points that are a little disconnected from reality, or perhaps they are not being entirely honest about the employee / employer relationship.
When I'm working for somebody I give them everything, my heart and soul. My passion. My success is the companies success.
But I think it's honest to be clear that I am giving up _time_ with my family or _time_ working on my own projects to bring home a salary. There is a big difference between my heart and soul for 20 hours a week, or 40 hours a week, or 60 hours a week. Hours do matter. Hours are my side of the bargain, and in return for hours I get paid cash.
I think its a form of dishonesty to gloss over this and wave your hands around and say hours don't matter, just come in when you want and do your best and if you perform well you won't be fired. When I hear this I think the employer doesn't expect you to have anything else in your life other than your job, and that what they really want is _all_ your hours in exchange for your salary.
I don't think that's necessarily bad, just say so and be upfront about it.
Having no holiday policy also artificially creates a grey area, or a point of conflict between an employee or employer. If I were a cynical old bastard I would suggest that the no holiday policy is actually so that holidays don't accrue from year to year. In my experience young engineers don't really take holidays and if you don't force them out of the office they end up with months and months of leave saved up.
However, there were a few points that are a little disconnected from reality, or perhaps they are not being entirely honest about the employee / employer relationship.
When I'm working for somebody I give them everything, my heart and soul. My passion. My success is the companies success.
But I think it's honest to be clear that I am giving up _time_ with my family or _time_ working on my own projects to bring home a salary. There is a big difference between my heart and soul for 20 hours a week, or 40 hours a week, or 60 hours a week. Hours do matter. Hours are my side of the bargain, and in return for hours I get paid cash.
I think its a form of dishonesty to gloss over this and wave your hands around and say hours don't matter, just come in when you want and do your best and if you perform well you won't be fired. When I hear this I think the employer doesn't expect you to have anything else in your life other than your job, and that what they really want is _all_ your hours in exchange for your salary.
I don't think that's necessarily bad, just say so and be upfront about it.
Having no holiday policy also artificially creates a grey area, or a point of conflict between an employee or employer. If I were a cynical old bastard I would suggest that the no holiday policy is actually so that holidays don't accrue from year to year. In my experience young engineers don't really take holidays and if you don't force them out of the office they end up with months and months of leave saved up.
Check out "10. What happens to my earned and accrued but unused vacation if I am discharged or quit my job?" at http://www.dir.ca.gov/dlse/faq_vacation.htm
Exactly my thinking. Maybe they literally don't expect you to put in more hours. But if there is no specific limitations others will spend more hours to "out-star" you, because the star stays and the others have to go. And because the other guy is doing it, you also have to do it. And in the end everybody works 80 hour weeks. I love counting working hours and holidays because in the end it means I really can take this time off.
Just as a single data counterpoint, my recruiting experience with Netflix was below par. It may have been the way that I was approached (from a friend who was also an engineer) . However, the 'process' took over 3 months to get nowhere. After many re-schedulings and me having to restart the process myself, I just gave up. Never heard from them after I had given up, either.
Curious to hear what team you were applying for?
"hire, reward, and tolerate only fully formed adults"
This. If I had one advice for every company out there, its to try and do this. Being adult doesn't have to do with your age. People who are responsible, curios and always willing to learn and work out differences... these are the kind of people that you really want.
Admittedly that's hard to do. Perhaps that's why many people like to hire within their network.
This. If I had one advice for every company out there, its to try and do this. Being adult doesn't have to do with your age. People who are responsible, curios and always willing to learn and work out differences... these are the kind of people that you really want.
Admittedly that's hard to do. Perhaps that's why many people like to hire within their network.
A lot of people make excuses based on generations, but it's more about what management is willing to tolerate.
I've been at NFLX for 7 months now. I agree with much of what Brendan has discussed here in terms of culture. If you are confident in your abilities it really is a great place to be and you really do get to work with some of the brightest minds in the valley.
The whole firing average performers thing is, in my opinion, really a means of making sure that only those applicants who feel strongly that they have something to bring to the table should apply. This is not where you go for job security, it is where you go to work on something that excites you. That being said, it is extremely rare to see someone let go who did not have some sort of fair warning or multiple indications that their work was somehow below par. I believe the multiple claims on glass door are remnant of the culture when this company was under serious duress in 2012/2013.
Of course, as with any organization, mileage may vary. One of the negative aspects of this culture is that as you get some very smart, very confident, very opinionated minds into a room - you are of course going to get into some head butting. Sometimes the overarching business strategy may change before a team can adapt to that change, and then persons may become defensible about their territory. While Netflix as an organism does a great job of eliminating this threat, it does take some time to formally fix the mojo within a deprecated organization / way of doing things.
The whole firing average performers thing is, in my opinion, really a means of making sure that only those applicants who feel strongly that they have something to bring to the table should apply. This is not where you go for job security, it is where you go to work on something that excites you. That being said, it is extremely rare to see someone let go who did not have some sort of fair warning or multiple indications that their work was somehow below par. I believe the multiple claims on glass door are remnant of the culture when this company was under serious duress in 2012/2013.
Of course, as with any organization, mileage may vary. One of the negative aspects of this culture is that as you get some very smart, very confident, very opinionated minds into a room - you are of course going to get into some head butting. Sometimes the overarching business strategy may change before a team can adapt to that change, and then persons may become defensible about their territory. While Netflix as an organism does a great job of eliminating this threat, it does take some time to formally fix the mojo within a deprecated organization / way of doing things.
Most of this jives with what I have heard from two Netflix engineers, except for the work/life balance. Both folks that I talked to said that Netflix was very much a place where they tried to work you as hard as possible until you burned out, but that this was balanced by the exceptional compensation. I wonder if the culture has changed or if only certain roles are like that?
Netflix has definitely afforded me the most work/life balance I've ever had. If you are still here at 6pm, it's pretty much empty.
You HN bio says
> Now I hang out and enjoy technology, advise startups and some other stuff (including working at Netflix as the Site Reliability Lead)
Which gives me the impression you work part time (or at least reduced hours) at Netflix. If that's the case, it may not be a good work/life comparison to other experiences you've had.
> Now I hang out and enjoy technology, advise startups and some other stuff (including working at Netflix as the Site Reliability Lead)
Which gives me the impression you work part time (or at least reduced hours) at Netflix. If that's the case, it may not be a good work/life comparison to other experiences you've had.
Nope, definitely full time. :) The rest of that is extracurricular.
but what time do you arrive in the morning?
Lately around 11 because I just had a baby, but before that between 9 and 10 usually. If you get here before 10 you can get still get prime parking.
People basically work 9 to 5. Yes, some people will put in a couple hours at home or on the weekend, but the nice thing is that no one expects you to be there, so you can definitely get all your "group work" done from 9 to 5.
People basically work 9 to 5. Yes, some people will put in a couple hours at home or on the weekend, but the nice thing is that no one expects you to be there, so you can definitely get all your "group work" done from 9 to 5.
The culture at Netflix is discontinuous (more specifically: Customer Service vs Engineering) and has peaks and valleys as you navigate the landscape. Some teams work harder than others. There were definitely top engineers that worked less than 40 hours and top engineers that worked more than 40 hours.
Netflix sounds like a pretty clued on place in terms of hiring and culture. Which considering their size is no small feat. I don't like their clever wording around what they call a "high performance culture" which basically means that if you don't meet the level they expect, you get fired. Which is fine, but they should be a little more honest about the fact without burying it behind creative HR speak.
I would love to know more about their hiring process though. You mentioned that you didn't have to answer questions unrelated to your job (something I personally experienced during a job interview on a bad scale recently). Do they make you solve puzzles and other pointless indicators that some companies use to determine if a developer is any good or not? More specifically maybe a front-end focused role, not a back-end one.
Would love to know more about the process (as much as you can without getting into trouble).
I would love to know more about their hiring process though. You mentioned that you didn't have to answer questions unrelated to your job (something I personally experienced during a job interview on a bad scale recently). Do they make you solve puzzles and other pointless indicators that some companies use to determine if a developer is any good or not? More specifically maybe a front-end focused role, not a back-end one.
Would love to know more about the process (as much as you can without getting into trouble).
I must just be an outlier on this, but I hate the idea of only getting interview questions that pigeonhole me into some narrow role, because it suggests that the job will be similarly pigeonholed, which I think is awful. I much prefer lines of questioning that attempt to suss out how well I can participate on a team, learn and adapt, and think creatively, because they suggest that they hope for me to be doing those things a lot, which is great.
Let me elaborate. Recently I went for a job that was being advertised as a front-end developer position. The recruiter who briefed me on the position also informed me that it was a front-end only role and that there would be a test on various front-end things; HTML, CSS and Javascript for the most part.
As it turned out, the interviewer had plans to test me on a few front-end related things, but then proceeded to ask me questions about Java, databases, server administration and complex Javascript puzzles. Keep in mind this was a position for a front-end developer, their job listing didn't mention Java, databases or server administration. Looking at their current site, they are abusing jQuery pretty badly, aren't minifying their CSS/JS or tonnes of other things, so it felt weird I was being asked super complicated and mostly irrelevant questions when their site seemed so poorly developed.
I think it is important you not only get quizzed on things relating to your job, but also other things not directly relating to your job (but still important and within reason). I showed up for a particular job as a front-end developer and was asked questions that you would ask a DBA, Java developer and front-end developer. It was not the role being advertised.
This is a mistake that I discovered seems to happen at quite a fair bit. The hiring process is definitely broken at a lot of companies.
As it turned out, the interviewer had plans to test me on a few front-end related things, but then proceeded to ask me questions about Java, databases, server administration and complex Javascript puzzles. Keep in mind this was a position for a front-end developer, their job listing didn't mention Java, databases or server administration. Looking at their current site, they are abusing jQuery pretty badly, aren't minifying their CSS/JS or tonnes of other things, so it felt weird I was being asked super complicated and mostly irrelevant questions when their site seemed so poorly developed.
I think it is important you not only get quizzed on things relating to your job, but also other things not directly relating to your job (but still important and within reason). I showed up for a particular job as a front-end developer and was asked questions that you would ask a DBA, Java developer and front-end developer. It was not the role being advertised.
This is a mistake that I discovered seems to happen at quite a fair bit. The hiring process is definitely broken at a lot of companies.
I'm with you, and it sucks and is very nerve-wracking to have the wrong expectations going into an interview. Having said that, my reaction to that would have been more like "oh good, I'm glad they're also interested in what I know about a bunch of other stuff, I was afraid they just wanted me to be the HTML, CSS, and JS guy". Specialization is a good thing, but I prefer jobs where I'm hired because they think I'll be generally useful to the company, perhaps on things they haven't even foreseen working on yet, rather than for a really narrow role.
A farther flung interview suggests an interest in hiring a person rather than a set of skills.
A farther flung interview suggests an interest in hiring a person rather than a set of skills.
I admire your optimism. Perhaps I have been in the industry for too long, but these days I much prefer being a specialist in a particular niche as opposed to be known as the guy in the office who gets emailed when the printer breaks, a server goes down, a Wordpress site needs to be built or someone has a question about why their email is broken.
I have been in that situation a few times in my career, when I worked at a digital agency especially. My job varied from Javascript, CSS and HTML, to developing HTML newsletters, building Wordpress websites, setting up servers/databases and tonnes of other things. At the time it was an invaluable learning experience, but also meant I worked long hours because my list of responsibilities was longer, friendships suffered because I worked a lot of weekends/late nights. As a result of that job, I didn't feel like it made me an expert in one particular thing. I was good at many things, but not truly great at front or back-end development. I felt like I had to learn outside of work hours to get good enough to specialise in my chosen field (my day-to-day job was obviously also a factor).
If I went for a job advertised as one thing, but then discovered that they expect you to be good at a lot of other things it would make me think twice (at least now I do). When I first started out, I was willing to do anything because I was young, naive and excited I had a job doing what I wanted to do in life.
My initial thoughts would be, "Please, not again. I don't want the responsibility of wearing multiple hats. I've worked hard to get to the point where I want to specialise in a chosen field", followed by, "This company is trying to get a combination stir-fry developer so they can cheap out and not have to hire a separate database administrator or back-end developer."
If you want a developer who knows a lot of things and is expected to work with a tonne of different languages, deploy a server and make coffee: there is nothing wrong with that, just be upfront and honest about it, so people like myself don't waste your time and have their time wasted. Don't lure candidates in with a misleading job description only for them to discover the job is actually more than you initially led on.
I have been in that situation a few times in my career, when I worked at a digital agency especially. My job varied from Javascript, CSS and HTML, to developing HTML newsletters, building Wordpress websites, setting up servers/databases and tonnes of other things. At the time it was an invaluable learning experience, but also meant I worked long hours because my list of responsibilities was longer, friendships suffered because I worked a lot of weekends/late nights. As a result of that job, I didn't feel like it made me an expert in one particular thing. I was good at many things, but not truly great at front or back-end development. I felt like I had to learn outside of work hours to get good enough to specialise in my chosen field (my day-to-day job was obviously also a factor).
If I went for a job advertised as one thing, but then discovered that they expect you to be good at a lot of other things it would make me think twice (at least now I do). When I first started out, I was willing to do anything because I was young, naive and excited I had a job doing what I wanted to do in life.
My initial thoughts would be, "Please, not again. I don't want the responsibility of wearing multiple hats. I've worked hard to get to the point where I want to specialise in a chosen field", followed by, "This company is trying to get a combination stir-fry developer so they can cheap out and not have to hire a separate database administrator or back-end developer."
If you want a developer who knows a lot of things and is expected to work with a tonne of different languages, deploy a server and make coffee: there is nothing wrong with that, just be upfront and honest about it, so people like myself don't waste your time and have their time wasted. Don't lure candidates in with a misleading job description only for them to discover the job is actually more than you initially led on.
Thanks for the great response! You're right, I would definitely be suspicious of people marketing one thing and delivering another, so to speak. I haven't had the experience of getting a software development job and finding myself fixing printers, so perhaps that's a danger I should learn from your kindly shared experience to be more wary of. I suppose our experiences and frustrations have simply developed differently!
The "Freedom and Responsibility" link here describes the culture, including the wording "adequate performance gets a generous severance package". I was asked to read this before my interview and found it sufficiently direct.
http://jobs.netflix.com/who-we-are.php
http://jobs.netflix.com/who-we-are.php
It's not the kind of company where managers or departments hate each other, and use their roles to conduct political warfare.
It's not the kind of company where bad mistakes are frequently made, and no one is held accountable.
These are aspects of "culture" that are really easy to boast of but hard to actually prove that you have. Some more data on how Netflix avoids inter-personal conflict between those with power would be really interesting.
It's not the kind of company where bad mistakes are frequently made, and no one is held accountable.
These are aspects of "culture" that are really easy to boast of but hard to actually prove that you have. Some more data on how Netflix avoids inter-personal conflict between those with power would be really interesting.
They say how they do it: Hire smart people that match with our philosophy. And that might be all you can do.
Just as a counter point - I had a different experience with these guys. Got approached by a hiring manager who set up the first screening call that went fairly well. Then got contacted by the Recruiter ...
Things went downhill fast after that point - the recruiter was very casual in her approach towards anything related to skills or compensation but very aggressive about how they value performance, what an honor it was to work at Netflix how lucky I am to be in the interview "pipeline"...
I had never met a bunch of folks so enamored by their own culture. I probably said something like "I have worked at quite a few places that have very good supportive cultures as well" towards the end.
The process ended after that call...thankfully.
[posting from a throwaway to avoid the fairly easy googling identification]
Things went downhill fast after that point - the recruiter was very casual in her approach towards anything related to skills or compensation but very aggressive about how they value performance, what an honor it was to work at Netflix how lucky I am to be in the interview "pipeline"...
I had never met a bunch of folks so enamored by their own culture. I probably said something like "I have worked at quite a few places that have very good supportive cultures as well" towards the end.
The process ended after that call...thankfully.
[posting from a throwaway to avoid the fairly easy googling identification]
Senior Software Engineer @ Netflix: $210,157/year/avg. Netflix seems to have some high salaries, even for the bay area.
http://www.glassdoor.com/Salary/Netflix-Salaries-E11891.htm
http://www.glassdoor.com/Salary/Netflix-Salaries-E11891.htm
> It's not the kind of company where managers or departments hate each other, and use their roles to conduct political warfare.
Political warfare isn't always obvious to a newcomer with several months on the job.
Political warfare isn't always obvious to a newcomer with several months on the job.
I used to work at a place where studying organizations was important to the business itself, so we focused a lot on things like Netflix's culture slide deck. One of my favorite parts of that deck is how it points out that a company's culture is what happens every day, not what is painted on the wall in fancy letters. It made me reflect on the discrepancy between what my employer at the time said, and how they acted.
I interviewed for a role on the website UI team in spring of 2013. I thought the interview process was one of the best I have experienced. My would-be manager initially reached out to me (not a recruiter) and we had a few nice phone conversations about what they were looking for. They flew me out for a two day interview. If they know it isn't a fit on the first day, they don't have you come back for the second.
I met with 3 developers, a hiring specialist and a development manager on the first day and they asked very domain-relevant questions within my area of expertise. No silly programmer brain teasers. I had plenty of time to ask questions of my own.
On day two I met with non-developers. Business, designers/UX, etc. I was able to get a very good idea of the people I would be working with and the types of problems I would be solving.
I ended up deciding to take another offer, but it was a very positive experience overall. I didn't encounter any jerks like some others have.
I met with 3 developers, a hiring specialist and a development manager on the first day and they asked very domain-relevant questions within my area of expertise. No silly programmer brain teasers. I had plenty of time to ask questions of my own.
On day two I met with non-developers. Business, designers/UX, etc. I was able to get a very good idea of the people I would be working with and the types of problems I would be solving.
I ended up deciding to take another offer, but it was a very positive experience overall. I didn't encounter any jerks like some others have.
brendangregg is one of The People in performance analysis. Netflix would be foolish to pass on him. So the experience is most likely not representative of the average hire.
The description sounds like it's still the honeymoon phase. Or was Joyent THAT bad? (-;
Came here to say this. He's been the closest thing to a rockstar sysadmin for as long as I can remember and even before he taught the world how to use Dtrace.
I know this piece is mostly about what it's like to work at Netflix, but the more technical part leads to an obvious question: If FreeBSD is so great for performance analysis, and Netflix is already using it at scale, then why not also use it on the EC2 instances? Seems like they could gradually move toward FreeBSD-based instances. Or is Linux really that much better as an EC2 guest?
Until very recently, it's been hard to get FreeBSD to work well on EC2. When I started at Netflix 2.5 years ago, I asked them same thing. I think we're finally at a place where we might be able to start looking at making the move.
But to be honest, we're pretty heavily invested in the Linux ecosystem at this point.
But to be honest, we're pretty heavily invested in the Linux ecosystem at this point.
As jedberg said, we're heavily invested in Linux on the cloud, which means there's a large cost associated with the move (porting infrastructure software, tools, and testing).
But FreeBSD has been improving on EC2, such as PVHVM support. If the benefit was big enough, it might outweigh the cost. I'd like to do a little FreeBSD EC2 perf testing this year (as I would for any tech that might pay off)...
But FreeBSD has been improving on EC2, such as PVHVM support. If the benefit was big enough, it might outweigh the cost. I'd like to do a little FreeBSD EC2 perf testing this year (as I would for any tech that might pay off)...
We've been talking about the same thing in engtools over the last few weeks... we should set up a meeting :)
I wonder if he will still be in love with his job after another 12 months pass. :)
As with the other hires on my team I'm thrilled to have Brendan onboard. I would also hope that if he happens to leave Netflix due to issues with the culture he will share that experience as well, publicly.
Thank you to the people who are sharing their Netflix stories as well.
I'm curious about the time frame though. The author of the post noted that he started several months back, to anyone who is sharing their story here can you please also note the approximate time frame for when your story takes place?
I'm curious to see if the company has corrected the problems that some people have hit while maneuvering through the recruiting process.
I'm curious about the time frame though. The author of the post noted that he started several months back, to anyone who is sharing their story here can you please also note the approximate time frame for when your story takes place?
I'm curious to see if the company has corrected the problems that some people have hit while maneuvering through the recruiting process.
"It's not the kind of company where managers or departments hate each other, and use their roles to conduct political warfare." Laugh!
I would like to know parts of the company that he doesn't like or would like to see changed. Can anyone chime in?
At companies where "stupid things happen, but can't be fixed", it's easy to make a list of things that people would like to see fixed, since they've been irritating everyone forever. Netflix isn't like that, and we have the freedom to fix stupid things anyway. So it's a hard question to answer. :-)
There have been technologies that I haven't liked, and I've had the freedom to work on them, change them, improve them, and have. I can list many of those, but it's not too different to what I've been putting in my blog during the past 10 months.
There have been technologies that I haven't liked, and I've had the freedom to work on them, change them, improve them, and have. I can list many of those, but it's not too different to what I've been putting in my blog during the past 10 months.
Thanks for the response. I was thinking certain technology might have been in the list of improvements. I'm glad to hear that you are free to work on them and improve them.
Considering it's all built on well-known and tested (provided you follow the best practices) cloud services (AWS right?) I often wonder what they do all day. Netflix platform strikes me as something you invest heavily in at day 1 but then only need a boilerplate team of developers to keep it ticking over and responding to user feedback.
They love to bleat on about their Chaos Monkey this and Chaos Monkey that. But come on, they wrote a read-only cloud-hosted and distributed video streaming service that leans on standard cloud services and best practices for 90% of the hard parts. Chaos Monkey just smacks of writing a integration test for a third party component you don't own.
Frankly I wouldn't want a job at Netflix simply because the problem domain is not interesting enough. Read-only highly-resilient distributed systems are not particularly hard to create and test. It's only becomes an interesting problem when you need to do a comparable amount of write-ops at the same time as those read-ops.
They love to bleat on about their Chaos Monkey this and Chaos Monkey that. But come on, they wrote a read-only cloud-hosted and distributed video streaming service that leans on standard cloud services and best practices for 90% of the hard parts. Chaos Monkey just smacks of writing a integration test for a third party component you don't own.
Frankly I wouldn't want a job at Netflix simply because the problem domain is not interesting enough. Read-only highly-resilient distributed systems are not particularly hard to create and test. It's only becomes an interesting problem when you need to do a comparable amount of write-ops at the same time as those read-ops.
One thing to remember is that one person's experience at a company can be vastly different than others. For example your job happiness can be either great or terrible depending on your manager.
I really like the 9 values, i do seem to align. Except for the "analysis paralysis" bit. It perfectly describes two recent weeks.. so i put the coin-phrase on a sticky. :)
I also interviewed with the talent woman, who gave me the baseball team analogy and that fact they love to fire people. A little off-putting for a candidate to hear, no?
Riiiiiiight: "It's not the kind of company where managers or departments hate each other, and use their roles to conduct political warfare."
As George Costanza said, "it's not a lie if you believe it".
Author mentions:
> Bad News syndrome
What is that precisely? (in context of tech companies)
> Bad News syndrome
What is that precisely? (in context of tech companies)
page isn't loading :\
Auto-scaling not enabled for this cluster :P
Netflix hired an in house P.R. Consultant.
This can't be real.? I have family who worked at netflix.
Netflix must have brought their P.R. Consultant on full time for the last 3 months to write this post.
Netflix must have brought their P.R. Consultant on full time for the last 3 months to write this post.
Many of the benefits op describes come from having a company which is growing. As soon as Netflix starts floundering and questioning its future you will definitely see political warfare and all kinds of time burning endeavors.
This is basically an HR approved Netflix puff piece.
This is basically an HR approved Netflix puff piece.
Netflix is over 15 years old, has floundered numerous times and reinvented itself at least once while retaining the same management. I don't know if this post is an "HR approved Netflix puff piece", but your comment is a textbook middlebrow dismissal.
I understand why you would be skeptical, it seems like more rah-rah crap from a successful tech company. However, it is not a puff piece, it's completely accurate. Political "warfare" or other malicious actions are not tolerated at any level at Netflix.
Netflix only looks for sharp people that are also a cultural fit. If you are smart and negative, you won't last long.
I don't think that counters what OP is saying. Netflix is publicly traded. Their CEO, who sets the cultural tone, only lasts as long as the shareholders allow him to last. If they start floundering for enough consecutive quarters, I guarantee you Reed will be gone and a PHB who will "maximize shareholder value" will replace him.
If the Mikes can be ousted from RIM, you can bet your rear that Hastings can be ousted from Netflix. And once "maximizing shareholder value" becomes the goal, "culture" becomes an afterthought.
If the Mikes can be ousted from RIM, you can bet your rear that Hastings can be ousted from Netflix. And once "maximizing shareholder value" becomes the goal, "culture" becomes an afterthought.
Well, yeah, if the company isn't doing well and leadership changes, obviously that'll trickle down to employees and culture. No one said it'll be like this forever at Netflix, but it does sound like they put a heavy emphasis on "culture" now.
Exactly. Because anything can happen, Netflix could be a terrible place to work in the future, and therefore it is definitely not a good place to work now.
That's not the point, and not what OP or I said. He said that the benefits Brendan describes are more a result of being a growing company than "being Netflix". He didn't say it wasn't a good place to work now, and he didn't say it would be a terrible place to work in the future. You did.
The part I'm skeptical about is, "Adequate performance gets a generous severance packet."
Can't say I've ever heard of an organization where that's true. Typically, adequate performance means no promo, and being first in line for dismissal if the order comes down to cut staff.
Firing someone who is trying and doing sort of OK-ish but not actually well sounds hard. I would expect all but the hardest of hearts to be reluctant to dismiss a lowish performer, preferring to hope that experience and mentoring will yield a turnaround. People have empathy, after all. (Well, except for the sociopaths...)
In fact, to actually get managers to get rid of the merely adequate, you'd probably have to institute something like an up-or-out system, so managers could blame the system rather than themselves or the workers when the merely adequate got shoved out the door.
Can't say I've ever heard of an organization where that's true. Typically, adequate performance means no promo, and being first in line for dismissal if the order comes down to cut staff.
Firing someone who is trying and doing sort of OK-ish but not actually well sounds hard. I would expect all but the hardest of hearts to be reluctant to dismiss a lowish performer, preferring to hope that experience and mentoring will yield a turnaround. People have empathy, after all. (Well, except for the sociopaths...)
In fact, to actually get managers to get rid of the merely adequate, you'd probably have to institute something like an up-or-out system, so managers could blame the system rather than themselves or the workers when the merely adequate got shoved out the door.
Yes, I never trust what company people say about their workplaces, unless: I know them, it's in private and they have sharply critical minds. (Usually called "disgruntled".)
- If I don't know them, they have little incentive to tell me the truth.
- If it's not private, then selection bias: glowing affirmations (or pseudo-critique: "Yeah we have our problems, but...") will obviously be the voices we hear. Not only are those maybe rewarded, but cold enough critiques are swiftly punished. For obvious reasons.
- If they're not sharply critical types, they miss what should be obvious, because they drink the koolaid or are just plain fine with whatever silliness.
(Why the emphasis on critique? Because one's job is solving problems, and real companies have such egregious problems. I'll accept fairly wrong critique in preference to correct bragging, because critique's usually missing and at least something not-too-wrong is a string to pull on during research.)
- If I don't know them, they have little incentive to tell me the truth.
- If it's not private, then selection bias: glowing affirmations (or pseudo-critique: "Yeah we have our problems, but...") will obviously be the voices we hear. Not only are those maybe rewarded, but cold enough critiques are swiftly punished. For obvious reasons.
- If they're not sharply critical types, they miss what should be obvious, because they drink the koolaid or are just plain fine with whatever silliness.
(Why the emphasis on critique? Because one's job is solving problems, and real companies have such egregious problems. I'll accept fairly wrong critique in preference to correct bragging, because critique's usually missing and at least something not-too-wrong is a string to pull on during research.)
Critical type here. There's something missing from his review. The company seems to fire people on the spot for little mistakes, from what I've read above. There has to be a lot more dirt, he just hasn't encountered yet.
Generous severances (of the sort that might accompany the dirt) usually come with a generous non-disclosure agreement, so that makes sense.
I liked the information about salary negotiation.
In case anyone from Netflix is reading here. Why does Netflix make it so easy for my 2nd grader to watch shows like Orange is the new smut? The only way I know to prevent her having access is to set my user to "Teen". If mine is set to "Adult", all she needs to do is click my Netflix user button. If you think 2nd graders are not watching that show, that is bull. I have a friend from another country whose daughter was watching it and bragged about it to a substitute teacher.
It's called "Orange is the New Black" and you shouldn't expect a tech company to be a parent for you.
I met with the *Chief talent officer (had to look up this title from my original schedule with them...) for one of my interviews and she spent half the time telling me why the stock price was so low "We were high on a $300 share price and thought we were gods." Then, the other half telling me her favorite firing stories. I don't know what the purpose of all of this was but it gave me the impression that HR/head of HR needed to demonstrate how important they are in the company.
One of my potential colleagues interviewed me and gave me a fizzbuzz question. I successfully answered it. He then asked me to rewrite it with some restrictions. I did this. Then he asked me to do it one more time. I wasn't familiar with the python syntax for if-else shortcut (e.g., x = 100 if y is True else 0) and so couldn't rewrite it to his liking. This lack of familiarity with this python trick resulted in feedback at the end of the interview that I did not have a deep enough understanding of computer science.
I honestly could tell that the interviewer giving me the fizzbuzz questions wasn't clicking with me personally. That's fine, and I completely respect that it's a valid reason not to hire someone. However, because of this feedback, and the fact that the people at netflix generally liked me, they wanted me to work on some sort of data warehouse management team. I'm not sure why they would offer me a job so wildly different from what I was contacted to apply for, or why the syntax from one language would be considered representative of my knowledge of CS.
Overall, I think the experience of one person at a company is nothing more than an anecdote that can be entertaining, perhaps moderately informative, but it's not a complete picture. There are many stories out there about people interviewing with or working for Netflix. If you are seriously interested in the company, read a lot of those stories, discount all of them as biased, and then see for yourself by talking to them.