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

251–260 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#251

Post by jpindar »

crsv wrote: post #82
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…

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

I do embedded work. In this field some compilers don't even allow recursion.

Re: Engineering whiteboard interviews: yay or nay?

#252

Post by batteryhorse »

tluyben2 wrote: post #234
vultour wrote: post #165

Earlier quoted context omitted.

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.

I guess if you are old enough you'll know that one from the movie. Doesn't mean you remember how they solved it (because what did I care at the time?). Nothing to do with programming unless someone asks you to write a short program to figure out the most efficient (least steps) on how to do it. Behind a computer.

Yup. Bruce Willis and Samuel Jackson were able to figure that one out. It can't be that hard. They were under a lot of pressure as well.

Re: Engineering whiteboard interviews: yay or nay?

#254

Post by dm7 »

whiteboarding is essential when hiring for roles where development environment is not productive. there are still huge systems which take 5 minutes to link on fastest machine, or embedded, real-time and distributed systems where it takes so much time to debug that one's daily productivity would be close to zero unless he writes code which would be mostly correct before first run.

developing under such constraints is radically different from environments with high iteration velocity - i.e. browser or scripting.

that said, in many modern environments whiteboarding is completely irrelevant, as modern application level programmer productivity is often ability to do plumbing-and wiring- work between many components and quickly assess why something is going wrong, rather then creating a highly performant or memory-efficient algorithm implementation.

Re: Engineering whiteboard interviews: yay or nay?

#255

Post by mrep »

spike021 wrote: post #226
amzn_82582 wrote: post #208

Earlier quoted context omitted.

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…

I gave a demo of my intro project after a month to my 100 person org at my last company and I was a new grad. In fact, when I was an intern, all interns did project demos at the end of their internship.

Re: Engineering whiteboard interviews: yay or nay?

#256

Post by QuackingJimbo »

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…

``vector> grid{{1,1,0},{1,2,0},{0,2,2}};`` in C++

Re: Engineering whiteboard interviews: yay or nay?

#257

Post by scottyelich »

jackcosgrove wrote: post #154

I think an under-tested aspect of software engineering is the ability to research solutions on the internet. Just give people a search bar and ask them to solve a problem outside their comfort zone. See what terms they use and how quickly they can arrive at a useful link. No pseudo-code or architectural diagrams needed. Just a link with a plausible solution. Because that's how most learning on the job actually happen…

I did an interview problem like this a while back (was about combining CIDR blocks) and I found an answer on the Internet. I coded up a similar solution (I used a slightly different data structure with a slight optimization just to show I didn't copy the algorithm exactly). The place actually complemented me on my Google foo as they claimed they asked the question because they knew (thought?) people couldn't look up the answer. Of course, they dinged me by saying my code had too many comments (nevermind I was detailing WHY and HOW my algorithm was different from the Google results). I didn't get any love for the man(1) page I made either. Oh well, can't please everyone. :-)

Re: Engineering whiteboard interviews: yay or nay?

#258

Post by philwelch »

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…

As a candidate, to me, that sounds a lot like, "we're going to do the same things we would normally do in a technical interview, but we're going to evaluate you based on random, arbitrary, subjective criteria that you will never know about rather than your actual level of skill."

Re: Engineering whiteboard interviews: yay or nay?

#259

Post by scottyelich »

jpindar wrote: post #243
jackcosgrove wrote: post #154

I think an under-tested aspect of software engineering is the ability to research solutions on the internet. Just give people a search bar and ask them to solve a problem outside their comfort zone. See what terms they use and how quickly they can arrive at a useful link. No pseudo-code or architectural diagrams needed. Just a link with a plausible solution. Because that's how most learning on the job actually happen…

If I were interviewing that would absolutely be an important part of the interview. It never ceases to amaze me how bad some people are at searching.

Hell, I've coded in languages that I didn't even know (didn't really even know what the language was -- I think it was like VB or something) by copying terms from some sample, reference or other part of the code and putting in the term or idea I was looking for.

Additionally, just try to look up items on a language that is in (constant?) flux like Swift. Swift 1.x? 2.x? 3.x? 4.x? What's the API today -- naming convention changed, parameters changed, etc. All I can say is that thank goodness Google allows for date ranges with searches. :-)

Re: Engineering whiteboard interviews: yay or nay?

#260

Post by hobls »

mlthoughts2018 wrote: post #239
majormajor wrote: post #227

Earlier quoted context omitted.

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

Bad workplaces are so common though that it’s a perfectly good heuristic to guess that if a place asks you to do whiteboard questions it’s a bad engineering workplace. You’re not missing much by passing, and the heuristic probably won’t be wrong much.

I guess you think every major tech company is a bad engineering workplace? Seems like a broad brush.
Post reply on HN