3 ms·
It is possible that eclipse users are more used to relying on their IDE for auto-completion so they can't whiteboard as effectively...
by rawnlq 9y ago
It is possible that eclipse users are more used to relying on their IDE for auto-completion so they can't whiteboard as effectively...
- wutbrodo 9y agoI hear stuff like this a lot, which seems to rely on whiteboard interviews expecting people to know method names. Do anyone but the worst interviewers actually _do_ this? That's a serious question, since my experience in this regard is pretty skewed. I've been doing whiteboard interviews for years now, including for a couple of years at Google, and the notion of ever expecting a candidate to remember a method name perfectly is beyond insane to me. I'm not OCRing their code and dumping it directly into a compiler: why the fuck would I care if they used size() or length() when checking how long a string is[1]? [1] Yes yes, I'm aware that this example isn't perfect because it could mean different things depending on the language
- Filligree 9y agoI'd like to hope they don't! Interviewees, however, tend to get flustered if they can't remember the method names. It's another rock on a pile that eventually leads to nervousness collapse, something that happens far too often, so after a few dozen interviews I've started stressing up-front that no, it doesn't matter, I'm not scoring you on that. That, on its own, produced a measurable increase in average score.
- jetsnoc 9y agoWhat do you score on?
- Filligree 9y agoIt all amounts to "Would I like to work with this person?", but a couple of things. Persistence, memory, ability to learn -- not trying the same thing over again if it doesn't work -- intelligence when possible, knowledge if I expect them to have it. That's pretty vague. I use the same strategy as the sibling post, ratcheting up difficulty until the candidate fails, so I usually have a lot to go on, but the exact criteria end up changing from one interview to the next depending on what the candidate did. Occasionally I end up with not enough data. I try to give my feedback in the form of a confidence interval, but if it's mediocre candidate combined with not-stellar signal quality... figuring out how to score them can take a while.
- wutbrodo 9y agoYea, I know how stressful it is to read the tea leaves of what an interviewer is actually looking for, so I'm always extremely up-front about the fact that I don't care at all about certain things. Hell, I've even told people that an incorrect final answer isn't a big deal: one of my favorite strategies is incrementally racheting up the difficulty of a problem until the candidate gets stuck. The richness of the information you can gain from this process is fantastic, though again, you have to couch it in a lot of communication to the interviewee that they shouldn't get stressed about not perfectly crushing the problem.
- thaumasiotes 9y ago> I've been doing whiteboard interviews for years now, including for a couple of years at Google, and the notion of ever expecting a candidate to remember a method name perfectly is beyond insane to me. I'm not OCRing their code and dumping it directly into a compiler: why the fuck would I care if they used size() or length() when checking how long a string is? When I interviewed at Google, a major part of the rejection feedback they gave me was "we felt like you weren't worried about whether your code would really run".
- compumike 9y agoFWIW, during the coding sections of Triplebyte's technical interview, you're allowed and encouraged to look up documentation, search Stack Overflow, play around in a REPL, run and test as often as you'd like, etc. It's what you'd do normally in a non-interview situation. (Not a whiteboard situation.)