Earlier quoted context omitted.
I guess it depends on the job, but for outage response, being able to understand a problem, and update or write new code in a reasonable amount of time is kind of a useful skill. Discussing it on a board with others can be useful, if the code isn't complex. Of course, that also depends on the environment; if you're in an environment can't actually push any code, even emergency fixes, quickly, then it doesn't help a l…
Do you design clever search algorithms during outages?
Engineering whiteboard interviews: yay or nay?
81–90 of 370 posts
Re: Engineering whiteboard interviews: yay or nay?
#82My 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…
Re: Engineering whiteboard interviews: yay or nay?
#83I've been on both sides of this. Whiteboard interviews are good for a couple of things: Can the candidate explain a problem on a whiteboard? Is his hand-writing legible? It's not sufficient to decide if someone can code. You want some actual code written by that person. And you don't need everyone on your team being able to explain things well on a whiteboard. Just try to figure out how they are thinking and how they…
Re: Engineering whiteboard interviews: yay or nay?
#84Earlier quoted context omitted.
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.
Honestly, we all might as well read chicken entrails because that would be about as predictive as our current interview practices.
Re: Engineering whiteboard interviews: yay or nay?
#85VP 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…
This is incredibly common, and you tell the candidate in advance that they will be expected to give an n-minute presentation on a subject of their choosing (need not even be tech) so they can prepare.
Tell me this: when did a mob last ambush you at your desk and demand that you invert a red-black tree on a whiteboard that they happen to have with them right now? I'm guessing that never happens where you work. If it does then fair enough :-)
Re: Engineering whiteboard interviews: yay or nay?
#86VP 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…
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 a team meeting with someone from product who will watch your demo of a potential new project/idea/concept.
Re: Engineering whiteboard interviews: yay or nay?
#87Earlier quoted context omitted.
Do you design clever search algorithms during outages?
If the existing search algorithm is the cause of the outage, maybe. If I a clever search algorithm will help me filter the data so I can reduce the scope of the outage, yes.
Re: Engineering whiteboard interviews: yay or nay?
#88My 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.
A question I've had in an interview was what is the difference between recursion and iteration. Fairly easy to explain, including examples of usage.
Re: Engineering whiteboard interviews: yay or nay?
#89Earlier 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…
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 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 playing a game of gotcha on the whiteboard, you need better interviewers.