Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering whiteboard interviews: yay or nay?

keyvalues.com

Post reply on HN
Print view View original

141–150 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#141

Post by LaserToy »

balls187 wrote: post #127
LaserToy wrote: post #99

Principal Engineer from huge gaming company here. White board coding interview are testing only one thing: how well candidate is prepared for it. And here what is wrong with it: The assumption that candidate should spend his/her valuable time preparing for someone's assessment is arrogant. I do understand why Google and Facebook do it (the do other arrogant things), they assume you want to work for them so much you w…

> So, why should I prepare for Google's or someone's else interview? Because you want the job? Everyone is busy, that's a terrible excuse not to brush up on your interview skills. By the tone of your post, my sense is that prior to your recent epiphany you weren't very kind to candidates who you interviewed.

Do I? There are a lot of great companies, why should I waste time on Google? Working there is not as fancy as you think.

>> Everyone is busy, that's a terrible excuse not to brush up on your interview skills. I believe that their approach is arrogant, they just don't value candidates time.

I have a confession to make, I spent some time at Google. And after I left I was interviewing people using their approach and I regret it now.

P/S/ When you interview for a company, you actually taking more risk that the company (talking about folks who are headhunted into interviews). If it doesn't work out, you will be out searching for a job, you career growth may be slowed down. And what is the company risk?

Re: Engineering whiteboard interviews: yay or nay?

#142

Post by loxias »

KhanMahGretsch wrote: post #70
remoteorbust wrote: post #45

Earlier quoted context omitted.

> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that…

> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? Perhaps it would be more effective to have the candidate whiteboard a concept that they are already familiar with, be it a high-level engineering principle or a system/solution they have built in the past. Attempting to solve a problem you have just been presented with AND communica…

That's an awesome idea -- as someone who rabidly hates whiteboard interviews, to the extent that I'm looking at the responses in this article as a note of who to consider applying with next, I would love the challenge of "explain a complex concept you're already familiar with". I've never gotten that in an interview before.

Re: Engineering whiteboard interviews: yay or nay?

#143

Post by pkteison »

Tobani wrote: post #110
spike021 wrote: post #86

Earlier quoted context omitted.

>I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in…

We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as more of a conversation, we're less concerned about getting to the "right, fastest, or most optimized" answer. Not a hard problem, no mindgames, no syntax rules, and no complicated pre-known algorithm work other than an if and a loop. Let's just talk about some…

Every time an interviewer has told me something like this, they then nitpick syntax and appear to be primarily concerned with "does my whiteboard code compile" sorts of problems. And getting stuck / asking for help feels like I get docked for getting stuck. Same with less optimized. So it's hard to trust such an explanation - clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options.

So it seems to me entirely reasonable to still be nervous.

Mind you, I don't have a better answer, but I don't think just explaining that suboptimal is ok and it's a discussion really helps.

Re: Engineering whiteboard interviews: yay or nay?

#144

Post by ilikehurdles »

munchbunny wrote: post #89
jdc wrote: post #60

Earlier quoted context omitted.

The point is that the interview style in question overemphasizes on-the-spot responses. How is prowess in a game of "gotcha" an important indicator of engineering skill?

I tend to agree with (what I think is) the sentiment of some of the respondents in the article: if your whiteboard interview is a game of gotcha, then the problem is your interviewer, not the whiteboard. I think the complaint that programmers pretty much never have to think about code under pressure is a fair criticism. The whiteboard really puts you on the spot. But if it's your company and your hiring managers are…

State dependent learning is a bit of a factor too. I can count on one hand the number of times I’ve presented anything on a whiteboard at work, yet just about every company asks these questions during interviews. A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in.

Whiteboard coding interviews are one thing that I have to go out of my way to practice for and get better at over time when interviewing (ie over the course of a few failed interviews). I don’t feel more skilled or smarter by the end of the set of interviews, but I inevitably do better at these kinds of problems. Should the interview be testing my competency at day-to-day work skills or how well I’ve practiced my interview skills, because whiteboard coding problems only achieve the latter.

Re: Engineering whiteboard interviews: yay or nay?

#146

Post by balls187 »

LaserToy wrote: post #141
balls187 wrote: post #127

Earlier quoted context omitted.

> So, why should I prepare for Google's or someone's else interview? Because you want the job? Everyone is busy, that's a terrible excuse not to brush up on your interview skills. By the tone of your post, my sense is that prior to your recent epiphany you weren't very kind to candidates who you interviewed.

Do I? There are a lot of great companies, why should I waste time on Google? Working there is not as fancy as you think. >> Everyone is busy, that's a terrible excuse not to brush up on your interview skills. I believe that their approach is arrogant, they just don't value candidates time. I have a confession to make, I spent some time at Google. And after I left I was interviewing people using their approach and I r…

> Do I? There are a lot of great companies, why should I waste time on Google? Working there is not as fancy as you think.

I'm definitely confused. You don't want to waste time preparing for an interview, but you will waste time interviewing at a company for a job you don't want?

Yes, there are lots of companies hiring. But in my experience, in preparing for one software interview, you're preparing for others as well.

I interviewed at Dropbox, Amazon, Valve, and Indeed, within a span of a few weeks, and the prep work (Cracking the Coding Interview) was applicable to all.

Re: Engineering whiteboard interviews: yay or nay?

#147

Post by pkteison »

I find it weird that the responses seem to draw a distinction between whiteboards and coderpad. The assumption seems to be that the problem making the whole thing stressful and unnatural was the communication medium and not the fact that it's a super time compressed artificial problem with many unstated considerations and a tremendously outsized influence on the rest of your life, no pressure, just talk through everything exactly like you never do.

Most of the problem seems to me fundamentally unaddressable without verifiable portfolios, but those have their own problems. Even in industries where portfolios are standard, plagiarism is a thing - how do you get the verifiable part? I want to hire someone great, not just someone who was on the same team as someone great.

Re: Engineering whiteboard interviews: yay or nay?

#148

Post by loxias »

techwraith wrote: post #115
mattnewton wrote: post #106

Earlier quoted context omitted.

How do you compare the resulting apples & oranges? I can do a lot more at home (especially if I cheat on time, which everyone who really wants your job and can afford to do will do)

We're less concerned with the resulting code than we are about your ability to explain the code that you wrote and your ability to prove to us that you have good judgement when making technical decisions. Also, we're growing fast enough that we're rarely comparing candidates. If we can hire both the apple and the orange (assuming both candidates are evaluated to be good for the role), we will.

I'm actively looking/interviewing and really like the "cut of your jib". (both your answers here, plenty of aspects of Eaze as a company, the prospect of moving back to SF...)

For both the sr backend and devops positions, how important to the roles is familiarity/experience with your technical stack? I might have some of the skill set/experience you're looking for -- sr backend engineer, sr systems engineer, devops are all positions I've held -- but honestly I don't know JS, .NET, or Chef. Bluntly, I don't want to waste your (or my) time. ;)

Also, I wish HN supported private replies

Re: Engineering whiteboard interviews: yay or nay?

#149

Post by 0x00000000 »

anonytrary wrote: post #121

Whiteboards, in practice, are never used for writing strict code. They're used for high-level diagramming and high-level pseudocode. The only time I've used whiteboards in my job is either when I need to hash out a solution or approach with my coworkers, because I'm confused or don't understand the problem, or when I need to understand high-level architecture for a system. It's a tool for clearing one's thoughts and…

At a big 4 company recently, they specifically told me "avoid writing pseudocode"

Re: Engineering whiteboard interviews: yay or nay?

#150

Post by mountainofdeath »

anonytrary wrote: post #121

Whiteboards, in practice, are never used for writing strict code. They're used for high-level diagramming and high-level pseudocode. The only time I've used whiteboards in my job is either when I need to hash out a solution or approach with my coworkers, because I'm confused or don't understand the problem, or when I need to understand high-level architecture for a system. It's a tool for clearing one's thoughts and…

Most selective companies require you to have near correct code in the most efficient algorithm, clean, correct, concise, with all edge cases in about 30-45 minutes depending on the question. They also seem to love dynamic programming algorithms and competitive programming tricks (the less common stuff you glossed over in an advanced algorithms class).

I say this as someone who worked at one and interviewed at others. You really do need to treat it like an exam.

Post reply on HN