5 ms·

1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a

1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a smart developer without a CS degree to learn what they need to know for interviews. 2. Yes, I understand that interview prep might interfere with other obligations. You don't have to study. But it'll help you. I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past? 3. Sure, you could do coding competitions if you want. That'll replace existing interview studying; you wrote your comment as though that's in addition to your previous studying. 4. Yes, true, you don't code on a whiteboard. But this, in and of itself, doesn't matter. What matters is whether whiteboards are more predictive and whether they create a better candidate experience. So, forget whether it's "real world" or not. Whiteboards have their pros and cons. The major benefit of a whiteboard is that it allows a candidate to not get caught up in details, like the exact syntax for some function (who cares?) or writing in all the details of some trivial thing just so it can compile. It allows us to focus on the big picture. It encourages more thought process and communication. On a computer, many candidates just shut down -- they try to get things out as fast as possible, and they stop thinking about what they're actually doing. 5. You do not need to work on your handwriting. I've done A LOT of interviews and this has almost never been an issue.

NTDF9 9y ago
>> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. Fine. I know this. Will this give me a job? No >> Yes, I understand that interview prep might interfere with other obligations. You don't have to study. But it'll help you. I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past? No. I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard. If the interviewer cannot filter out bullshitters, the interviewer is incapable of the "job of interviewing". Maybe hire better interviewers. Why is the burden on the candidate? >> The major benefit of a whiteboard is that it allows a candidate to not get caught up in details, like the exact syntax for some function (who cares?) or writing in all the details of some trivial thing just so it can compile. It allows us to focus on the big picture. It encourages more thought process and communication. On a computer, many candidates just shut down -- they try to get things out as fast as possible, and they stop thinking about what they're actually doing. I agree with this, only so long as the interviewers don't fret about some stupid edge case. Why is there an expectation of perfect code in 15 mins on a whiteboard? Who does that in production? The interviewer knows about these edge cases because they've seen the problem before. But I can guarantee that the same interviewer would not be able to 'perfectly' solve some problems that I pose them without having seen them before. Which brings me back to the question. What is the point of the coding interview (or perfection in coding interview) if the only people who can solve them are the ones who have seen the problem before?
- ryandrake 9y ago
  I think we just have to accept that the skills needed to pass an interview are a largely different set than the skills needed to excel at the job. One set of skills is not more important than the other, because you need both of them to get and keep the job. We need to practice both.
- gaylemcd 9y ago
  >> >> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. >> Fine. I know this. Will this give me a job? No No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question. >> I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard. The ability to see a hard problem, develop your own solution, and translate that into code is a pretty important skill. "Skills" aren't all about knowledge. >> If the interviewer cannot filter out bullshitters, the interviewer is incapable of the "job of interviewing". Maybe hire better interviewers. Why is the burden on the candidate? It's a lot more complex than that. It's not just about filtering out bullshitters. It's also about identifying people who might be great but are unable to talk about it. There's also lots of people who are great but haven't been in situations where they've been able to tackle interesting challenges (either because of their inexperience, industry, etc). Or maybe they've done interesting things but in a related field that's hard to understand. But, yes, absolutely train interviewers. (Interviewing isn't really a role that you hire for.) But even a very well trained interviewer might not be very effective in a behavioral interview. >> I agree with this, only so long as the interviewers don't fret about some stupid edge case. Why is there an expectation of perfect code in 15 mins on a whiteboard? Who does that in production? There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe not. It depends on the situation.) What I train interviewers on is that correctness in and of itself is not relevant. Why a candidate was correct or incorrect might be. >> The interviewer knows about these edge cases because they've seen the problem before. But I can guarantee that the same interviewer would not be able to 'perfectly' solve some problems that I pose them without having seen them before. The interviewer is comparing the candidate to other candidates on the same question. So if a candidate is getting rejected because they failed to be perfect, this means that other candidates are actually getting to perfect solutions. Or you just have a crappy interviewer who rejects everyone. >> Which brings me back to the question. What is the point of the coding interview (or perfection in coding interview) if the only people who can solve them are the ones who have seen the problem before? If that's the case? Nothing. But that's not the case.
piptastic 9y ago
I'm pretty sure the entire parent comment was sarcastic
- gaylemcd 9y ago
  I'm pretty sure I interpreted the comment correctly...
dnackoul 9y ago
>1. No, you don't need to know everything... It takes maybe a week for a smart developer without a CS degree to learn what they need to know for interviews. I just went through a job search and I didn't find this true. I think the bar on algorithms has raised significantly with all of the prep material (your book included) out there. I also found a few companies sent over "things to study" lists that were quite comprehensive and included topics that you might not even see in undergrad. >I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past? I think this is a false dichotomy. I had two friends that just interviewed at Stripe and loved their process: https://stripe.com/jobs/engineering-onsite.pdf https://stripe.com/jobs/engineering-onsite.pdf
- deleted 9y ago
  [deleted]
- cloakandswagger 9y ago
  I would estimate a reasonable amount of prep time prior to interviewing is around 100 hours. This is about how long it will take to brush up on and practice data structures, algorithms, DP, design questions, etc. This is about 2 months of practicing an average of 2 hours a day, meaning you're still working a day job. I figure this could be reduced to 1 month of prep if you quit your job and have all day to yourself.
  - gaylemcd 9y ago
    Lots of people get offers with little to no prep.
    - dnackoul 9y ago
      Usually these are people who are coming from companies with similar interview styles and are passively prepped by being an interviewer (for algos/coding) and designing web-scale systems (for system design).
- jarsin 9y ago
siliconc0w 9y ago
Wow - this kinda blew up. 1. Obviously you have a lot of experience with this but I just can't see how a week is anywhere near accurate judging from my personal experience, people I've talked to, and the numerous online stories of people's personal experience. 2. To be honest, I kinda expect the world's smartest organization to find some better way to evaluate talent. Google says they want diversity but requiring a month of studying isn't going to allow for that. Their process throws false negatives on a lot of people that could otherwise be great engineers (which they largely admit to). 3. They're different skillsets. One is about knowledge, the other is about memorizing question patterns and practicing implementation speed. 4. Does Google have data here? My experience is a lot of candidates shut down at a whiteboard because it's not what they're used to. They're afraid to experiment or erase or use longer clearer variable names because of the overhead of writing by hand and dealing with space limitations. It's a lot more messy to modify and extend code you've already written. 5. No, it's really bad. It's like this weird mix of cursive and small caps. I'm not sure what is going on.
- gaylemcd 9y ago
  1. I'm not saying a week for preparation overall. I'm saying a week to learn the core algorithms and data structures. Frankly, that's probably much less than a week to learn. 2. Yes, it does throw false negatives. Lots of people get hired with zero prep though. I generally say about a month of prep is where you hit pretty low returns from more time. But that doesn't mean that you need a month, or that a month will be enough for you. 3. I'm not sure I see your point here. If coding interview prep is a different skillset from coding competitions, then you wouldn't do coding competitions in order to do interview preps. 4. Some candidates do shut down because it's not what they're used to. A well-trained interviewer can mitigate this to some extent (not always). Some people will also shut down at a computer. Interviews will always be an artificial environment and people can freeze for different reasons. At a whiteboard, it's often a bit easier to unfreeze candidates and create a happier atmosphere. 5. That's fine. As long as I can read it, it's fine. And if I can't read it and you can explain to me what you're writing, that will also work.
codesnik 9y ago
bad handwriting is not an issue for interviewer, but it could seriously ruin thought process for interviewee. It ruins it for me, for sure. You know, good code "looks" good, and that feeling is a major part of programmer intuition for me.
tutufan 9y ago
> Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past? I want to work for a company that doesn't start with the assumption that I'm a liar, yes. Going further, it'd be nice to have a company that basically knew what they were looking for, and knew how to evaluate that in a casual conversation.

NTDF9 9y ago

>> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. Fine. I know this. Will this give me a job? No >> Yes, I understand that interview prep might interfere with other obligations. You don't have to study. But it'll help you. I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past? No. I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard. If the interviewer cannot filter out bullshitters, the interviewer is incapable of the "job of interviewing". Maybe hire better interviewers. Why is the burden on the candidate? >> The major benefit of a whiteboard is that it allows a candidate to not get caught up in details, like the exact syntax for some function (who cares?) or writing in all the details of some trivial thing just so it can compile. It allows us to focus on the big picture. It encourages more thought process and communication. On a computer, many candidates just shut down -- they try to get things out as fast as possible, and they stop thinking about what they're actually doing. I agree with this, only so long as the interviewers don't fret about some stupid edge case. Why is there an expectation of perfect code in 15 mins on a whiteboard? Who does that in production? The interviewer knows about these edge cases because they've seen the problem before. But I can guarantee that the same interviewer would not be able to 'perfectly' solve some problems that I pose them without having seen them before. Which brings me back to the question. What is the point of the coding interview (or perfection in coding interview) if the only people who can solve them are the ones who have seen the problem before?

ryandrake 9y ago
I think we just have to accept that the skills needed to pass an interview are a largely different set than the skills needed to excel at the job. One set of skills is not more important than the other, because you need both of them to get and keep the job. We need to practice both.
gaylemcd 9y ago
>> >> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. >> Fine. I know this. Will this give me a job? No No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question. >> I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard. The ability to see a hard problem, develop your own solution, and translate that into code is a pretty important skill. "Skills" aren't all about knowledge. >> If the interviewer cannot filter out bullshitters, the interviewer is incapable of the "job of interviewing". Maybe hire better interviewers. Why is the burden on the candidate? It's a lot more complex than that. It's not just about filtering out bullshitters. It's also about identifying people who might be great but are unable to talk about it. There's also lots of people who are great but haven't been in situations where they've been able to tackle interesting challenges (either because of their inexperience, industry, etc). Or maybe they've done interesting things but in a related field that's hard to understand. But, yes, absolutely train interviewers. (Interviewing isn't really a role that you hire for.) But even a very well trained interviewer might not be very effective in a behavioral interview. >> I agree with this, only so long as the interviewers don't fret about some stupid edge case. Why is there an expectation of perfect code in 15 mins on a whiteboard? Who does that in production? There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe not. It depends on the situation.) What I train interviewers on is that correctness in and of itself is not relevant. Why a candidate was correct or incorrect might be. >> The interviewer knows about these edge cases because they've seen the problem before. But I can guarantee that the same interviewer would not be able to 'perfectly' solve some problems that I pose them without having seen them before. The interviewer is comparing the candidate to other candidates on the same question. So if a candidate is getting rejected because they failed to be perfect, this means that other candidates are actually getting to perfect solutions. Or you just have a crappy interviewer who rejects everyone. >> Which brings me back to the question. What is the point of the coding interview (or perfection in coding interview) if the only people who can solve them are the ones who have seen the problem before? If that's the case? Nothing. But that's not the case.

piptastic 9y ago

I'm pretty sure the entire parent comment was sarcastic

gaylemcd 9y ago
I'm pretty sure I interpreted the comment correctly...

dnackoul 9y ago

>1. No, you don't need to know everything... It takes maybe a week for a smart developer without a CS degree to learn what they need to know for interviews. I just went through a job search and I didn't find this true. I think the bar on algorithms has raised significantly with all of the prep material (your book included) out there. I also found a few companies sent over "things to study" lists that were quite comprehensive and included topics that you might not even see in undergrad. >I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past? I think this is a false dichotomy. I had two friends that just interviewed at Stripe and loved their process: https://stripe.com/jobs/engineering-onsite.pdf https://stripe.com/jobs/engineering-onsite.pdf

deleted 9y ago
[deleted]
cloakandswagger 9y ago
I would estimate a reasonable amount of prep time prior to interviewing is around 100 hours. This is about how long it will take to brush up on and practice data structures, algorithms, DP, design questions, etc. This is about 2 months of practicing an average of 2 hours a day, meaning you're still working a day job. I figure this could be reduced to 1 month of prep if you quit your job and have all day to yourself.
- gaylemcd 9y ago
  Lots of people get offers with little to no prep.
  - dnackoul 9y ago
    Usually these are people who are coming from companies with similar interview styles and are passively prepped by being an interviewer (for algos/coding) and designing web-scale systems (for system design).
jarsin 9y ago

siliconc0w 9y ago

Wow - this kinda blew up. 1. Obviously you have a lot of experience with this but I just can't see how a week is anywhere near accurate judging from my personal experience, people I've talked to, and the numerous online stories of people's personal experience. 2. To be honest, I kinda expect the world's smartest organization to find some better way to evaluate talent. Google says they want diversity but requiring a month of studying isn't going to allow for that. Their process throws false negatives on a lot of people that could otherwise be great engineers (which they largely admit to). 3. They're different skillsets. One is about knowledge, the other is about memorizing question patterns and practicing implementation speed. 4. Does Google have data here? My experience is a lot of candidates shut down at a whiteboard because it's not what they're used to. They're afraid to experiment or erase or use longer clearer variable names because of the overhead of writing by hand and dealing with space limitations. It's a lot more messy to modify and extend code you've already written. 5. No, it's really bad. It's like this weird mix of cursive and small caps. I'm not sure what is going on.

gaylemcd 9y ago
1. I'm not saying a week for preparation overall. I'm saying a week to learn the core algorithms and data structures. Frankly, that's probably much less than a week to learn. 2. Yes, it does throw false negatives. Lots of people get hired with zero prep though. I generally say about a month of prep is where you hit pretty low returns from more time. But that doesn't mean that you need a month, or that a month will be enough for you. 3. I'm not sure I see your point here. If coding interview prep is a different skillset from coding competitions, then you wouldn't do coding competitions in order to do interview preps. 4. Some candidates do shut down because it's not what they're used to. A well-trained interviewer can mitigate this to some extent (not always). Some people will also shut down at a computer. Interviews will always be an artificial environment and people can freeze for different reasons. At a whiteboard, it's often a bit easier to unfreeze candidates and create a happier atmosphere. 5. That's fine. As long as I can read it, it's fine. And if I can't read it and you can explain to me what you're writing, that will also work.

codesnik 9y ago

bad handwriting is not an issue for interviewer, but it could seriously ruin thought process for interviewee. It ruins it for me, for sure. You know, good code "looks" good, and that feeling is a major part of programmer intuition for me.

tutufan 9y ago

> Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past? I want to work for a company that doesn't start with the assumption that I'm a liar, yes. Going further, it'd be nice to have a company that basically knew what they were looking for, and knew how to evaluate that in a casual conversation.