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

Re: Engineering whiteboard interviews: yay or nay?

#221

Post by BinaryIdiot » Fri, Aug 10, 2018, 12:43 AM UTC

ltdanimal wrote: post #73

BinaryIdiot wrote: post #49

Earlier quoted context omitted.

If you're looking for them to do something _really simple_, like FizzBuzz, then you're doing it wrong already. This is something that could have taken place over a technical phone screening. Once they hit the on site interview it should be more about how they can work together with a team, how they would design systems, what they would do if they needed help, etc. Coding up FizzBuzz on-site is a waste of everyone's t…

How exactly could you evaluate FizzBuzz over the phone? Its designed as a weed out question early on, if they can't do that (and yes some have failed) then it makes a decision pretty easy

Most places I've interviewed at (or was the interviewer) talked to the candidate over the phone but had something like Google Docs open so you could watch some live coding. Usually just go through some very basic exercises to make sure the person at least knows how to code and ask a few, general programming questions. Stuff like that.

Re: Engineering whiteboard interviews: yay or nay?

#222

Post by mrep » Fri, Aug 10, 2018, 12:45 AM UTC

WDCDev wrote: post #168

remoteorbust wrote: post #100

Earlier quoted context omitted.

That's an excellent idea. I'm in no way saying the existing method is perfect. Just that some of the things it tests around communication and being put on the spot and analyzing a problem in a way that is understandable to the rest of the room is actually a really good engineering skill. There can be other great ways to measure those skills. I know my opinion is unpopular, but I sometimes do think I've figured out so…

They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough. But ... if you read some of the feedback from interviewers at "those companies" that rely on these interviews, they say the reason they failed someone is exactly because they "didn't leetcode hard enough". It is manifested as: "Well other candidates got the same solution as you, they just did it 10 minutes faster…

> "You missed an edge case, even though your core algorithm was correct".

That may have been a reason why I have failed some interviews but I feel like most interviewers are actually good about this and will say something along the lines of "what about this input?" where my code does not work and then I have that "oh shit, that won't work for that" and then I fix it.

Re: Engineering whiteboard interviews: yay or nay?

#223

Post by BinaryIdiot » Fri, Aug 10, 2018, 12:45 AM UTC

curtis wrote: post #71

BinaryIdiot wrote: post #49

Earlier quoted context omitted.

If you're looking for them to do something _really simple_, like FizzBuzz, then you're doing it wrong already. This is something that could have taken place over a technical phone screening. Once they hit the on site interview it should be more about how they can work together with a team, how they would design systems, what they would do if they needed help, etc. Coding up FizzBuzz on-site is a waste of everyone's t…

We're a small startup, and we don't have a really structured process. Also I have been the only person asking a detailed coding question (in consultation with my boss). Everybody else on the team has been responsible for those other questions. I should also add that I personally prefer to do coding questions in person on a whiteboard, rather than doing them during a phone screen with some sort of collaboration softwa…

I mean if it works for you then great but I've seen that back fire far too many times where I had to interview an incoming candidate who didn't do any coding over collaboration software and then couldn't do simple FizzBuzz. Basically wastes their time traveling and interviewing and my time when a quick check just to make sure they can do a few, quick basic things over the phone can save so much time.

While I dislike the way most large tech companies handle their interview process this one I don't mind as much.

Re: Engineering whiteboard interviews: yay or nay?

#224

Post by solipsism » Fri, Aug 10, 2018, 12:49 AM UTC

sgslo wrote: post #80

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…

If the goal is to test the thought process why not give interviee a self-directed project then ask them to present a 10 minute talk about it? You get some code written to verify the engineer can build something, plus you get confirmation that they can organize their thoughts and effectively communicate them to another engineer. Isn't that a more realistic scenario? How often do you give an (employed) engineer a task…

I'm confused by what you mean by self-directed. Would you give the person a specific problem to solve? Or would they be coming up with both the problem and the solution?

Re: Engineering whiteboard interviews: yay or nay?

#225

Post by blubb-fish » Fri, Aug 10, 2018, 12:51 AM UTC

whiteboard tests are always going to produce fuzzy red and white flags. those will come handy later when it gets to assessing the applicant based on sympathy and arbitrary objective arguments are required to back whatever the interviewer wants to conclude.

Re: Engineering whiteboard interviews: yay or nay?

#226

Post by spike021 » Fri, Aug 10, 2018, 1:00 AM UTC

amzn_82582 wrote: post #208

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…

Well, when you first start your job, you won't really know the people you are working with so I don't see how it is that much different.

Incredibly different.

I highly doubt a normal engineer is going to be giving a demo to their team with high stakes in the first three or so months. I understand if they're possibly a senior engineer, architect, or lead of some sort because they were probably hired with a plan to spearhead a specific project.

I'd say in the average case a new engineer will have enough time to at least break the ice with their new team before being put into a high pressure situation.

Re: Engineering whiteboard interviews: yay or nay?

#227

Post by majormajor » Fri, Aug 10, 2018, 1:04 AM UTC

pkteison wrote: post #143

Tobani wrote: post #110

Earlier quoted context omitted.

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…

All these discussions conflate a related, but separate problem with tech interviewing: most tech interviewers don't have much experience interviewing, and have never had good coaching on interviewing, and as a result mostly suck at it.

Picking on whiteboard code for not compiling is not good interview technique. But it's also a common enough failing that it's hard to say a bad interviewer in that regard means a bad workspace, unfortunately.

Re: Engineering whiteboard interviews: yay or nay?

#228

Post by anonytrary » Fri, Aug 10, 2018, 1:07 AM UTC

mountainofdeath wrote: post #150

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

Interviews of the sort you describe are like judging a fish by its ability to climb a tree. Indeed, whiteboards in interviews are used nothing like they are in real work. I'd hope more companies try and make interviewing closer to an actual work environment where the candidate can comfortably use their computer for solving the interview problem, using a whiteboard solely for communicating concepts and other surface level issues.

Re: Engineering whiteboard interviews: yay or nay?

#229

Post by tluyben2 » Fri, Aug 10, 2018, 1:07 AM UTC

BinaryIdiot wrote: post #46

pavel_lishin wrote: post #3

Earlier quoted context omitted.

Minor kvetch: quoting the way you did it makes long lines very difficult to read. I usually quote like this: > I am a quote This makes the quotation doubly-distinct, and still readable on mobile devices. === To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually wri…

I've worked at quite a lot of companies. Many of us will, occasionally, grab a room / whiteboard to go over something but 99% of the time it's a sort of flow or UX type thing. I've _never_ seen someone, or have asked to participate in, some sort of whiteboard coding thing. Even with pseudo code. That just doesn't seem helpful to me, at all.

Agreed; when there is code talking, we share screen on a projector/flatscreen and do it that way. How is writing code on a whiteboard good for anyone? Cumbersome and not reusable.

Re: Engineering whiteboard interviews: yay or nay?

#230

Post by redisman » Fri, Aug 10, 2018, 1:10 AM UTC

WDCDev wrote: post #168

remoteorbust wrote: post #100

Earlier quoted context omitted.

That's an excellent idea. I'm in no way saying the existing method is perfect. Just that some of the things it tests around communication and being put on the spot and analyzing a problem in a way that is understandable to the rest of the room is actually a really good engineering skill. There can be other great ways to measure those skills. I know my opinion is unpopular, but I sometimes do think I've figured out so…

They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough. But ... if you read some of the feedback from interviewers at "those companies" that rely on these interviews, they say the reason they failed someone is exactly because they "didn't leetcode hard enough". It is manifested as: "Well other candidates got the same solution as you, they just did it 10 minutes faster…

Agreed, thats a disingenuous point. "It's not about getting the right answer but the way you think". I've never found that to be true. If you don't get to the right answer, you're gone. If they planned to ask two questions and you only got through one, you're gone no matter how you "thought" about it. A huge part of this is Leetcode practice. If you can't solve most algorithm questions on whiteboard in less than an hour (because you haven't practiced) then you won't pass any interviews.