5 ms·

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"

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 gave a lecture on the options rather than trying to discuss options. So it seems to me entirely reasonable to still be nervous. Mind you, I don't have a better answer, but I don't think just explaining that suboptimal is ok and it's a discussion really helps.

cakes 8y ago
This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption. Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.
- pmiller2 8y ago
  Writing down the assumptions can help.
- hvidgaard 8y ago
  Even if you didn't say > Can we assume I know how to do argument checking? I would probably question you at some point about a particular value of an argument and almost all candidates will get points for thinking out load that of course a NULL would get it crashing and that a simple check could stop it. Then it leads to discussion about how it should be handled. Sometimes a NULL means the program should cast an exception, other times it should just return without any side effect. IMO the hate for whiteboard questions is really a symptom of poor interview technique.
amzn_82582 8y ago
Maybe I was just lucky, but I interviewed with google and dropbox recently and both companies gave me laptops to type in, did not ask me once about if my code compiled, didn't comment on my style, nor did I have to perfectly know the standard library (for google, they told me to just guess at the random library functions and I also forgot some of the functions names for a set. For dropbox, one of the guys re-explained to me semaphore functions and how they worked since I forgot since it had been so long since I used them in college). I passed both. Granted, I will give you that optimized code has definitely been important. One of those interviews even had me use a bit array (at least I think it was that) to efficiently a store a list of booleans but at least they gave me the relevant function calls to use an already implemented one.
majormajor 8y ago
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.
- mlthoughts2018 8y ago
  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.
  - hobls 8y ago
    I guess you think every major tech company is a bad engineering workplace? Seems like a broad brush.
    - mlthoughts2018 8y ago
      Is it even disputed anymore that the experience of working at the big tech companies is abjectly awful? I mean, you gotta work somewhere and they “are fine” and you might as well try to get paid well, but that’s a far cry from a workplace that stands out as good. The only place I’ve worked that was “good” instead of “treats people poorly but where else are they going to go” was a small, boutique financial company. Small companies that are randomly led by non-dummies are the best, but are exceedingly rare. Out of the vast majority comprising the other stuff, it’s mostly all so miserable that you’re doing yourself a favor to skip it unless the pay is some dramatic increase for you or you otherwise have some emergency requiring you to take some job.
      - hobls 8y ago
        Of course it’s disputed. There are lots of happy employees of tech giants. Any company with thousands and thousands of employees is going to have a wide variety of teams of varying qualities. (And yeah, the pay makes a difference. Not a lot of places where you can make a few hundred thousand dollars a year.)
Ntrails 8y ago
> clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options. Right. And a competency based interview goes better if you have a perfect example for every question. But it isn't an auto-fail if some of your answers are mediocre Personally though - I'd rather hire someone who is able to properly communicate their thought process over an imperfect solution, than someone who was unable to discuss/explain the perfect solution they scrawled down.
UncleMeat 8y ago
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.

cakes 8y ago

This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption. Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.

pmiller2 8y ago
Writing down the assumptions can help.
hvidgaard 8y ago
Even if you didn't say > Can we assume I know how to do argument checking? I would probably question you at some point about a particular value of an argument and almost all candidates will get points for thinking out load that of course a NULL would get it crashing and that a simple check could stop it. Then it leads to discussion about how it should be handled. Sometimes a NULL means the program should cast an exception, other times it should just return without any side effect. IMO the hate for whiteboard questions is really a symptom of poor interview technique.

amzn_82582 8y ago

Maybe I was just lucky, but I interviewed with google and dropbox recently and both companies gave me laptops to type in, did not ask me once about if my code compiled, didn't comment on my style, nor did I have to perfectly know the standard library (for google, they told me to just guess at the random library functions and I also forgot some of the functions names for a set. For dropbox, one of the guys re-explained to me semaphore functions and how they worked since I forgot since it had been so long since I used them in college). I passed both. Granted, I will give you that optimized code has definitely been important. One of those interviews even had me use a bit array (at least I think it was that) to efficiently a store a list of booleans but at least they gave me the relevant function calls to use an already implemented one.

majormajor 8y ago

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.

mlthoughts2018 8y ago
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.
- hobls 8y ago
  I guess you think every major tech company is a bad engineering workplace? Seems like a broad brush.
  - mlthoughts2018 8y ago
    Is it even disputed anymore that the experience of working at the big tech companies is abjectly awful? I mean, you gotta work somewhere and they “are fine” and you might as well try to get paid well, but that’s a far cry from a workplace that stands out as good. The only place I’ve worked that was “good” instead of “treats people poorly but where else are they going to go” was a small, boutique financial company. Small companies that are randomly led by non-dummies are the best, but are exceedingly rare. Out of the vast majority comprising the other stuff, it’s mostly all so miserable that you’re doing yourself a favor to skip it unless the pay is some dramatic increase for you or you otherwise have some emergency requiring you to take some job.
    - hobls 8y ago
      Of course it’s disputed. There are lots of happy employees of tech giants. Any company with thousands and thousands of employees is going to have a wide variety of teams of varying qualities. (And yeah, the pay makes a difference. Not a lot of places where you can make a few hundred thousand dollars a year.)

Ntrails 8y ago

> clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options. Right. And a competency based interview goes better if you have a perfect example for every question. But it isn't an auto-fail if some of your answers are mediocre Personally though - I'd rather hire someone who is able to properly communicate their thought process over an imperfect solution, than someone who was unable to discuss/explain the perfect solution they scrawled down.

UncleMeat 8y ago

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.