Engineering whiteboard interviews: yay or nay? • Hacker News Board

Re: Engineering whiteboard interviews: yay or nay?

#51

Post by java-man » Thu, Aug 09, 2018, 7:57 PM UTC

remoteorbust wrote: post #45

bradenb wrote: post #2

VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…

> 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…

even then, this is not what's being tested with the whiteboard.

thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.

Re: Engineering whiteboard interviews: yay or nay?

#52

Post by alkonaut » Thu, Aug 09, 2018, 7:57 PM UTC

bhb603 wrote: post #28

> "Whiteboarding" has become too large of an umbrella term, one that groups together everything that's wrong with the interview process. That general premise is right, we've lumped too much into the term "whiteboarding", and it's worth unpacking into the different interviewing practices we may like or dislike. Some things people don't like have nothing to do with an actual whiteboard (e.g. testing esoteric CS knowled…

Yes. The whiteboarding that gets hate is effectively the one where you would be asked to write a depth first traversal or similar, in some verbose language, correctly. On a whiteboard.

That is STILL a thing (judging by HN) and it's useless. I don't think anyone would ever think it's a bad idea to have a whiteboard on hand if a candidate is asked to describe how they would design some nontrivial system. Being asked to describe something without a whiteboard in that case, is even harder. The objection you often get for the latter kind is that it tends to benefit the extroverted kind that likes to babble and sketch, whereas a candidate who would prefer ten minutes alone with a pen and paper might not do so well. I think are some merits to that complaint, but I also know from experience that being able to babble and sketch is really important.

Re: Engineering whiteboard interviews: yay or nay?

#53

Post by scarejunba » Thu, Aug 09, 2018, 7:58 PM UTC

pavel_lishin wrote: post #29

pmiller2 wrote: post #6

Earlier quoted context omitted.

“Jotting down some code on a whiteboard” with a colleague is a much lower stress scenario than deriving and writing down, under a time limit, some DP algorithm you might not have used since college, and proving its correctness and run time to some stranger who may be barely out of college themselves.

I don't think people should play CS-quizshow during whiteboard interviews. Being asked to implement a breadth-first search, or whatever, is kind of annoying - especially since there's effectively one correct answer. At best, you're testing my memory and whether I read the right interview book. I had to do that at my last interview. I got through it ok-ish. The more interesting question was a more general system desig…

Surely not BFS. That's something you can figure out from first principles and knowledge of some data structures like stacks and queues, but I'd expect knowledge of those data structures anyway.

Re: Engineering whiteboard interviews: yay or nay?

#54

Post by jonathankoren » Thu, Aug 09, 2018, 7:59 PM UTC

Will_Parker wrote: post #40

Is there any engineer who you'd regret not hiring, who is unable to code FizzBuzz in real time in front of an audience? I'm skeptical.

I've seen a respected engineer that I worked with for years, be told by an outsider that he was incompetent because he couldn't fizzbuzz an interview. Yet, they had no problem acquiring the project he designed and wrote.

So yeah.

Re: Engineering whiteboard interviews: yay or nay?

#55

Post by java-man » Thu, Aug 09, 2018, 8:00 PM UTC

teachrdan wrote: post #5

bradenb wrote: post #2

VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…

There's some logic to that. It's the one of the same reasons we have high stakes exams in school: to show what the individual can do under pressure. In an interview setting you can't simulate what it's like to be at the end of a high-intensity sprint, but you can ask the candidate to answer a tough question on a whiteboard and (ideally) get a notion of how they work when the going gets tough.

unless the job requires whiteboard coding, you are not testing for the job.

an advice to candidate: when you've been asked to do whiteboard coding - run away. this is a negative signal.

Re: Engineering whiteboard interviews: yay or nay?

#56

Post by scarejunba » Thu, Aug 09, 2018, 8:00 PM UTC

lfowles wrote: post #42

ubernostrum wrote: post #26

Earlier quoted context omitted.

"Whiteboard interview" typically does not mean "sketch a general design of a system", or the other things whiteboards get actually used for on the job. It means "here's an algorithm challenge, solve it by writing the code on the whiteboard, and we'll flunk you if you make any mistakes". Not always a whiteboard, either; one of the best engineers I ever knew flunked a Google interview because of a situation where he ha…

Oof, I've had that experience during a technical phone screen with a different "hires only the best" company. I was asked to write (over the phone) a trivial statistical algorithm and started to describe the algorithm: "Function F returns a double and has two parameters, pointer to the start of the double array P and integer N for length of array." Apparently on the other end of the line was a human compiler that kep…

This is hilarious! Such a strong indicator that you, as a candidate, should reject the employer.

Re: Engineering whiteboard interviews: yay or nay?

#57

Post by privacypoller » Thu, Aug 09, 2018, 8:01 PM UTC

All of these interviewing "tools" (or tricks) attempt to be time/cost efficient proxies for doing the damn job, and they all suck.

* Whiteboard coding is awesome for software development shops that don't actually own computers or use punch cards to load programs.

* Shared coding environments with a time limit works well when you want to double screen for someone who can also diffuse suspicious packages that arrive at the office

* Riddles and puzzles are good when your workplace has a chicken coop, an office fox and you can't figure out how everyone can go for lunch without leaving the fox alone.

* Behavioral interviews are appreciated by candidates who took Psychology 100 back in school for an easy A.

* Take-home tests go over well with the huge population of talented software developers who can't find a job and have loads of time they want to spend decoding the operational cost of a bubble sort

The only thing I've seen that's at all realistic and effective is a very short, __paid__ project. I did a two-day one for Indeed (ironically one of the worst promoters of all this bullshit) and a 4-hour one for my current employer. The payment doesn't even have to be market, it's more important as a signal to candidates that the company values your time.

I ask for 3 things from perspective employers:

1. value my time like you value your own (both the number and composition of your interview steps)

2. keep me updated as to where we're at in the process and when the next stage/decision will be made

3. Move forward in the process in a timely manner. It should not take more than 2 weeks from when you initially contact me to the process concludes.

I've never gotten more than two of the above from a single organization, but I will someday, and I'm betting that a company that treats potential employees that well will treat actual employees better as well.

Re: Engineering whiteboard interviews: yay or nay?

#58

Post by jarsin » Thu, Aug 09, 2018, 8:04 PM UTC

ngngngng wrote: post #48

My most recent interview involved a coding assignment, which I topically don't do, but this one was a very interesting challenge that would make a good blog post afterwards so I did it. What was surprising is the interview not only included going over my code from the assignment, but also whiteboard problems about recursion. I've still never used recursion in my day job. Can interviewers really not gauge technical ab…

Interviewer: I see you have built an app just like ours five years ago. That's great. OK now let's get to the important stuff. How many cakes can you steal from the queen if your duflle bag hold 5 pounds and there are 10 different kinds of cakes?

True story.

Re: Engineering whiteboard interviews: yay or nay?

#59

Post by java-man » Thu, Aug 09, 2018, 8:04 PM UTC

romille wrote: post #39

To me, it's not about the code on a whiteboard vs a computer and correctness. It's about the thought process when breaking down a problem and the ability to organize and communicate their thoughts. It's also about exploring a problem space. How carefully does an engineer consider edge cases? What kinds of things are important to them? A whiteboard to me is a much simpler and accessible medium through which to explore…

I think it's important to measure what's actually relevant to the job. If the job entails large periods of coding on the whiteboard, then yes, it's a perfect metric.

If, however, the job requires careful consideration of dependencies, time domain, and, yes, edge cases - then you are NOT testing for that.

Lock the candidate in a room and give a few hours to let her to produce the result would be a better measurement.

Re: Engineering whiteboard interviews: yay or nay?

#60

Post by jdc » Thu, Aug 09, 2018, 8:06 PM UTC

remoteorbust wrote: post #45

bradenb wrote: post #2

VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…

> 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…

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?