6 ms·

Isn't that what a whiteboard interview is? Proving you can do things without google or else you aren't a proper engineer? (For the record I disdain whiteboard i

Isn't that what a whiteboard interview is? Proving you can do things without google or else you aren't a proper engineer? (For the record I disdain whiteboard interviews as the accepted metric for testing one's ability)

jonfw 7y ago
A good whiteboard interview doesn't require much outside of basic syntax/data structures, and will offer some form of help along the way (often in the form of a somewhat helpful interviewer).
sharadov 7y ago
Every engineer on HN (several threads that I've browsed) seems to have a serious disdain for coder-pad interviews/whiteboard sessions. And I think HN has a good representation of software engineers. So, who are these companies hiring?
- abalone 7y ago
  Every student I’ve ever met seems to have a serious disdain for exams, but for some reason universities keep giving them.
  - sharadov 7y ago
    I would rather do an exam every year, and get a grade on the skills that they expect. Exams are standardized, granted that they are not perfect, but its closest to a system that works. Am not at the whims and fancies of an individual interviewer.
    - abalone 7y ago
      I'm not sure what you mean by standardization. You're totally at the whim of the exam-maker either way. If anything I find algorithm screens tend to draw from a semi-standard set of fundamentals as outlined in books like Cracking the Coding Interview and tested on Leetcode among many other examples.
- sanderjd 7y ago
  They are hiring a bunch of people who have a serious disdain for the way they are interviewed. A better question might be, "who are these companies putting in charge of their interview process?". I think the answer there is largely, "people who have a serious disdain for this kind of interview, but still need to interview people and don't have any better ideas for how to do it".
- NoodleIncident 7y ago
  I'm not sure HN is representative of anything, especially if you only look at what's upvoted. If I had to guess, I'd say that this sentiment is posted by people with 10 years of experience who feel like they should be talking about something else during interviews, but that it's being upvoted by college students or recent grads (no matter what you're asked to learn, a large fraction of the group will be frustrated by it)
- munchbunny 7y ago
  A couple personal observations here. I think there's a serious disdain for interviewing in general. The whole process sucks from end to end. Often it's because the interviewers just aren't good at it. But when it comes down to whiteboard interviewing, I think it's about your value system. More specifically, I think every interviewer has an opinion on the practical <--> theoretical spectrum, and the problem is when the candidate disagrees with the interviewer's opinion on where on the spectrum the interview should be. The upside of a practical interview is that you are testing whether they can do the work. The downside of a practical interview is that it indexes heavily on experience and lightly on the ability to cross disciplines. Theoretical interviews are the reverse. So the important question is: what does your team care about? Google will care much more about the ability for their engineers to move around than your startup will. In general large companies will care much more about portability. They have deeper pockets and are therefore more willing to train you on the job, so generally speaking if they think you can ramp up (even for senior hires), they're happy. As much as startups will say they see things this way, it's not really true. Startups in general care that their senior hires come with substantial domain expertise.
latencyloser 7y ago
Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see how you communicate, how you handle mistakes, how thorough you are in double-checking yourself, your work style (do you jump right in or ask lots of questions first), etc. In any case, there's a lot of strategies to show that you understand a concept without relying on exact memorization. For example, a common answer I give if I can't remember something might be something like: "The language has a sort function that can accept a list, I don't remember the exact API or the underlying implementation but let's assume it's n log(n) as that's a common runtime complexity for sorting--I'm going to define that as 'sort(listArg)'." I don't remember the exact function, so I'll just define and explain how it might work myself. If you're expected to be able to compile the code you're writing, simply ask the interviewer and explain the API you're looking for, I've had great success with that as well and prefer when an interviewee asks me over staring at the screen or board. If it's a problem where you're expected to produce some algorithm, if you can't come up with any solution, explain to your interviewer what you're stuck on. They may provide a hint that will get you rolling. I had this happen during an interview at Microsoft (spoiler, I got the job) where I forgot how to determine the length of the hypotenuse of a triangle haha. The interviewer wrote the formula on the board and we moved on. Interviewer later told me I seemed nervous and he chalked it up to a brain fart--good call, I was really nervous! The point of that problem wasn't to see if I knew the Pythagorean theorem--it was just a small piece of the puzzle I was stumped on. Similarly start from a simple, naive solution, and interatively optimize rather than trying to recall a perfectly optimal solution. If time is running low, explain your intended optimization or ones you think might be meaningful, making note of any uncertainties in that explanation. I've worked at Microsoft, Amazon, some other notables and interviewed at many others. I am speaking from that experience. Others may have better ideas. Of course, not all places approach this in a reasonable fashion and some are just missing the point entirely with their interview and they do expect you to somehow memorize everything.
- blackflame7000 7y ago
  I totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and built multiple large scale production systems and i've also simultaneously forgotten whether it should be += or =+ during a whiteboard interview because of a phenomenon I can't quite describe. Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot. The biggest problem with whiteboards is that they reward exactly what they say they try to weed out, rote memorization. It's no secret you could spend weeks practicing on leetcode for an interview but those skills simply don't translate to real-world programming. Algorithm design is maybe 2% of software engineering. The vast majority is knowing what pieces of technology are out there in order to avoid reinventing the wheel all the time. Whiteboards don't test that skill. It tests a marathon runner on their 100 meter dash time.
kenhwang 7y ago
I let candidates use their phone to Google or ask me to Google on their behalf. What they're Googling for never matters in the context of the interview and it's mostly to make them feel more comfortable. It's a whiteboard, I'm looking out for far more important things than whether the method is named `size` or `length`.
munchbunny 7y ago
IMO it's not. I've never given or taken a whiteboard interview where the I (or the candidate) was not allowed to either google things or to make assumptions about how certain things worked. For example, if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it. We might come back to this later in the interview, but I'm generally uninterested in whether you memorized an algorithm for it or remembered how to call the standard library function that does it. That said, if you make up the black box function, I might dig into why you designed the function signature the way you did, and I'd do that to see whether you can talk about code design from a "other people will read and use and debug your code" perspective.
- Infinitesimus 7y ago
  > if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it But sometimes, the interview question is generating all the permutations :(
  - munchbunny 7y ago
    True... but that does mean they're not expecting that you can remember the algorithm. :)
TrackerFF 7y ago
A good interviewer will not care about syntactic things, but rather try to sniff out your workflow and thoughts / processing when breaking down a process. It should be a proper two-way interaction. A shitty interviewer will follow a rigid script and "ding" you on trivial errors.
lliamander 7y ago
I think whiteboard interviews are fine, so long as the candidate is told ahead of time what the subject the whiteboard test will be about and has time to study for it (perhaps even given a take-home coding assignment about the same subject) and where the subject is actually relevant to code that has been written at the company. But I do think that Computer Science Jeopardy on a whiteboard is a bad idea.

jonfw 7y ago

A good whiteboard interview doesn't require much outside of basic syntax/data structures, and will offer some form of help along the way (often in the form of a somewhat helpful interviewer).

sharadov 7y ago

Every engineer on HN (several threads that I've browsed) seems to have a serious disdain for coder-pad interviews/whiteboard sessions. And I think HN has a good representation of software engineers. So, who are these companies hiring?

abalone 7y ago
Every student I’ve ever met seems to have a serious disdain for exams, but for some reason universities keep giving them.
- sharadov 7y ago
  I would rather do an exam every year, and get a grade on the skills that they expect. Exams are standardized, granted that they are not perfect, but its closest to a system that works. Am not at the whims and fancies of an individual interviewer.
  - abalone 7y ago
    I'm not sure what you mean by standardization. You're totally at the whim of the exam-maker either way. If anything I find algorithm screens tend to draw from a semi-standard set of fundamentals as outlined in books like Cracking the Coding Interview and tested on Leetcode among many other examples.
sanderjd 7y ago
They are hiring a bunch of people who have a serious disdain for the way they are interviewed. A better question might be, "who are these companies putting in charge of their interview process?". I think the answer there is largely, "people who have a serious disdain for this kind of interview, but still need to interview people and don't have any better ideas for how to do it".
NoodleIncident 7y ago
I'm not sure HN is representative of anything, especially if you only look at what's upvoted. If I had to guess, I'd say that this sentiment is posted by people with 10 years of experience who feel like they should be talking about something else during interviews, but that it's being upvoted by college students or recent grads (no matter what you're asked to learn, a large fraction of the group will be frustrated by it)
munchbunny 7y ago
A couple personal observations here. I think there's a serious disdain for interviewing in general. The whole process sucks from end to end. Often it's because the interviewers just aren't good at it. But when it comes down to whiteboard interviewing, I think it's about your value system. More specifically, I think every interviewer has an opinion on the practical <--> theoretical spectrum, and the problem is when the candidate disagrees with the interviewer's opinion on where on the spectrum the interview should be. The upside of a practical interview is that you are testing whether they can do the work. The downside of a practical interview is that it indexes heavily on experience and lightly on the ability to cross disciplines. Theoretical interviews are the reverse. So the important question is: what does your team care about? Google will care much more about the ability for their engineers to move around than your startup will. In general large companies will care much more about portability. They have deeper pockets and are therefore more willing to train you on the job, so generally speaking if they think you can ramp up (even for senior hires), they're happy. As much as startups will say they see things this way, it's not really true. Startups in general care that their senior hires come with substantial domain expertise.

latencyloser 7y ago

Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see how you communicate, how you handle mistakes, how thorough you are in double-checking yourself, your work style (do you jump right in or ask lots of questions first), etc. In any case, there's a lot of strategies to show that you understand a concept without relying on exact memorization. For example, a common answer I give if I can't remember something might be something like: "The language has a sort function that can accept a list, I don't remember the exact API or the underlying implementation but let's assume it's n log(n) as that's a common runtime complexity for sorting--I'm going to define that as 'sort(listArg)'." I don't remember the exact function, so I'll just define and explain how it might work myself. If you're expected to be able to compile the code you're writing, simply ask the interviewer and explain the API you're looking for, I've had great success with that as well and prefer when an interviewee asks me over staring at the screen or board. If it's a problem where you're expected to produce some algorithm, if you can't come up with any solution, explain to your interviewer what you're stuck on. They may provide a hint that will get you rolling. I had this happen during an interview at Microsoft (spoiler, I got the job) where I forgot how to determine the length of the hypotenuse of a triangle haha. The interviewer wrote the formula on the board and we moved on. Interviewer later told me I seemed nervous and he chalked it up to a brain fart--good call, I was really nervous! The point of that problem wasn't to see if I knew the Pythagorean theorem--it was just a small piece of the puzzle I was stumped on. Similarly start from a simple, naive solution, and interatively optimize rather than trying to recall a perfectly optimal solution. If time is running low, explain your intended optimization or ones you think might be meaningful, making note of any uncertainties in that explanation. I've worked at Microsoft, Amazon, some other notables and interviewed at many others. I am speaking from that experience. Others may have better ideas. Of course, not all places approach this in a reasonable fashion and some are just missing the point entirely with their interview and they do expect you to somehow memorize everything.

blackflame7000 7y ago
I totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and built multiple large scale production systems and i've also simultaneously forgotten whether it should be += or =+ during a whiteboard interview because of a phenomenon I can't quite describe. Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot. The biggest problem with whiteboards is that they reward exactly what they say they try to weed out, rote memorization. It's no secret you could spend weeks practicing on leetcode for an interview but those skills simply don't translate to real-world programming. Algorithm design is maybe 2% of software engineering. The vast majority is knowing what pieces of technology are out there in order to avoid reinventing the wheel all the time. Whiteboards don't test that skill. It tests a marathon runner on their 100 meter dash time.

kenhwang 7y ago

I let candidates use their phone to Google or ask me to Google on their behalf. What they're Googling for never matters in the context of the interview and it's mostly to make them feel more comfortable. It's a whiteboard, I'm looking out for far more important things than whether the method is named `size` or `length`.

munchbunny 7y ago

IMO it's not. I've never given or taken a whiteboard interview where the I (or the candidate) was not allowed to either google things or to make assumptions about how certain things worked. For example, if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it. We might come back to this later in the interview, but I'm generally uninterested in whether you memorized an algorithm for it or remembered how to call the standard library function that does it. That said, if you make up the black box function, I might dig into why you designed the function signature the way you did, and I'd do that to see whether you can talk about code design from a "other people will read and use and debug your code" perspective.

Infinitesimus 7y ago
> if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it But sometimes, the interview question is generating all the permutations :(
- munchbunny 7y ago
  True... but that does mean they're not expecting that you can remember the algorithm. :)

TrackerFF 7y ago

A good interviewer will not care about syntactic things, but rather try to sniff out your workflow and thoughts / processing when breaking down a process. It should be a proper two-way interaction. A shitty interviewer will follow a rigid script and "ding" you on trivial errors.

lliamander 7y ago

I think whiteboard interviews are fine, so long as the candidate is told ahead of time what the subject the whiteboard test will be about and has time to study for it (perhaps even given a take-home coding assignment about the same subject) and where the subject is actually relevant to code that has been written at the company. But I do think that Computer Science Jeopardy on a whiteboard is a bad idea.