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

Re: Engineering whiteboard interviews: yay or nay?

#341

Post by drharby » Fri, Aug 10, 2018, 4:17 PM UTC

kmike84 wrote: post #198

nybblesio wrote: post #113

A regular viewer of my daily Twitch programming stream (link is in my profile) asked me to solve a problem he was asked to whiteboard. He wasn't asked to draw diagrams or write pseudo-code so they could learn how well he communicated. He was asked to write the code and it was heavily implied that it must compile and run -- even though whiteboards don't do that. Here's my attempt: https://youtu.be/6LHqrxrC6Uo I solved…

I got an impression that just specifying the input data took almost 1.5 hours, because of C++ and a decision to have it as a graph, not as a matrix. If an interview is in Python, one would write something like ``grid = [[1,0,0], [1,2,0], [0,2,2]]``, and be done with that part. Probably you got exhausted after doing all these preparations and debugging issues not related directly to the algorithm. I'm not sure the fin…

Thats the fun part 'to me' about mastery of cpp.

Sure you COULD use a graph, but using a different code abstraction to represent the idea of a graph is much more pragmattic and maintainable, of course that varies with application.

Im reentering interviewing phase right now, and its funny revisiting these problems with a new lense. The mind is very plastic and its exciting, so far as things to come.

Total nerd out moment :v

Re: Engineering whiteboard interviews: yay or nay?

#342

Post by UncleMeat » Fri, Aug 10, 2018, 4:21 PM 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…

Give feedback to the company.

When I give interviews candidates often say they don't remember some API. I tell them I don't care and they should make something up and I'll figure out what they are doing from context. The only time this burns candidates is when they clearly don't understand an ADT well enough to give it a sane interface.

Re: Engineering whiteboard interviews: yay or nay?

#343

Post by benmowa » Fri, Aug 10, 2018, 4:22 PM UTC

vultour wrote: post #165

privacypoller wrote: post #57

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…

Riddles are the worst, I was recently asked the "You have a 5 litre and a 3 litre container, how do you get 4 litres" question (never heard it before). It's so simple to figure out if you're on your own and just play around with the idea. When asked on the spot I just kept thinking "hey these people want an answer NOW, don't make them wait" while feeling their stare, and couldn't figure it out without help.

{

t0:{[3,5],[0,0]},

t1:{[3,5],[0,5]},

t2:{[3,5],[3,2]},

t3:{[3,5],[0,2]},

t4:{[3,5],[2,0]},

t5:{[3,5],[2,5]},

t6:{[3,5],[3,4]},

}

Thinking about making this an algorithm, are we forced to use recursion?

Re: Engineering whiteboard interviews: yay or nay?

#344

Post by dvlsg » Fri, Aug 10, 2018, 4:40 PM UTC

dingo_bat wrote: post #285

crsv wrote: post #82

Earlier quoted context omitted.

You have a software engineering job and you never used recursion of any kind? This strikes me as super odd.

It's almost always a norm that you never use recursion in production code. Always convert it to iteration. Bounded iteration.

Depends on the language too, I suppose. I'd be more shocked if they said they had never used recursion, but were using haskell at work.

Re: Engineering whiteboard interviews: yay or nay?

#345

Post by ep103 » Fri, Aug 10, 2018, 5:19 PM 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…

Simple, I want them to work on the same topic as other engineers I've interviewed, so I can benchmark them against each other, and ensure the topic is close to what we work on, and not just what the candidate happens to know a lot about.

Re: Engineering whiteboard interviews: yay or nay?

#346

Post by adrianmonk » Fri, Aug 10, 2018, 5:37 PM UTC

keithnoizu wrote: post #303

I always do horribly on these. I also don't have a degree in computer science so although I can setup a binary search tree, etc. well enough if work demands it I don't have the muscle memory of working with them intensively over and over again to spin out solutions to interview questions. Once in the workplace however I usually get promoted up pretty quickly. I'm pretty handy with generics and meta programming along…

IMHO, people with/without CS degrees should be evaluated by different standards/methods.

If you do have a CS degree, then I expect you to be able to show decent competency with that material because you were sitting in all those classes for all those years. If you didn't learn anything, it makes me question whether you apply yourself to what you do or just coast through stuff and are going to coast through at this job too. Since we have the shared experience of a CS degree, if I understand what you got out of it, I think it tells me something about your attitude and approach to your work.

If you don't have a CS degree, then I am going to focus more on skills required for the job role itself. If being strong on algorithms is really necessary for the job, then I'll need to cover that. For any job, though, I'll need to convince myself you have a certain base level of competency so that, for example, you know that a linear search of a billion items is bad.

Re: Engineering whiteboard interviews: yay or nay?

#347

Post by vkou » Fri, Aug 10, 2018, 5:50 PM UTC

stlHusker wrote: post #328

pavel_lishin wrote: post #44

Earlier quoted context omitted.

I would argue that a piece of paper showing that someone attended school and graduated and is licensed to be an ER nurse carries much more weight than a piece of paper showing that I'm allegedly qualified to be a software engineer. I know it's totally anecdotal, but we've all heard horror stories about candidates who couldn't write a for loop; some of us have witnessed these things first hand. And yes, phone screens…

Again, the op stated these things are put there to "show how people react to stress" -- my post was a response to that, there is no re-creation of a stressful environment in the situations I stated. "I know it's totally anecdotal, but we've all heard horror stories about candidates who couldn't write a for loop; some of us have witnessed these things first hand. And yes, phone screens should be filtering out those so…

The analogy to white-board interviews for hiring a musician is:

"Here's a couple of pages of unfamiliar sheet music that a second-year student should be able to play. You have an hour to figure out how to muddle through it on an instrument of your choice."

People hiring musicians don't do that, because they instead prefer to give candidates 16 bars of complex sheet music, and expect them to play it perfectly during the audition.

The programming equivalent would be to give someone a hard take-home problem, let them stew on it, bring them into the interview, and ask them to type in their solution, from memory, into a text file, on a keyboard with a broken Backspace key. That they will then compile, run, and compare the result of to that of the other 60 candidates auditioning for the role.

Are you sure you want to do auditions, instead of interviews?

> It is ironic that for an industry that is in a sense so subjective that the gates in the hiring process are more concrete.

That's because there's fifty thousand correct ways to solve a trivial programming problem, but only 'one' way to correctly play second violin in Vivaldi Four Seasons.

Music is a subjective art. Playing music is a mechanical process. My iPod can play music. My iPod can't implement a sorting algorithm.

Re: Engineering whiteboard interviews: yay or nay?

#348

Post by qudat » Fri, Aug 10, 2018, 7:24 PM UTC

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…

> We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them.

Except at the end of the day this is an interview, you are judging their answers and evaluating their performance. I have been part of white boarding sessions like this and it does not reduce anxiety and still feels completely removed from what I actually do on a daily basis.

Re: Engineering whiteboard interviews: yay or nay?

#349

Post by munchbunny » Fri, Aug 10, 2018, 7:27 PM UTC

ordinaryperson wrote: post #195

lev99 wrote: post #175

Earlier quoted context omitted.

> 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. I do coding interviews in the following manner: I select an interesting problem from a book. I personally complete the problem, measuring what was challenging and the time it took for me to complete the problem. I check the textbook solution, makin…

This would be a good method if your goal is to hire a carbon copy of yourself. First, your definition of "interesting problem" probably includes a lot of personal biases. What you find interesting probably touches stuff you've had experience with, but just because you've done work on say, customized implementations of binary search, doesn't mean it's a good baseline for all developers everywhere. Maybe they've worked…

I mostly agree with this approach. I think that you absolutely should be measuring the "boring stuff" because that's 90% of the work by number of hours spent.

On the other hand, I think there needs to be some proxy for "how well does the interviewee navigate complexity?" Because a programmer who does it well is far more valuable than a programmer who doesn't, and there's high variance on this between programmers and between fields of expertise.

The systems design interview sort of gets at it, and whiteboard interviewing often tries to get at it. I feel like I've yet to settle on an approach I'm happy with.

Re: Engineering whiteboard interviews: yay or nay?

#350

Post by qudat » Fri, Aug 10, 2018, 7:27 PM UTC

techwraith wrote: post #97

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…

VPE at Eaze here (the original author of the quote above) - You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.

I think this is a great approach. It keeps the company flexible to hire a broad array of talent under differing circumstances while also letting the interviewee play to their strengths.