One would do well to keep in mind the third commandment of technology management: "Thou shalt not suffer a witch to live." A.k.a., nobody likes a smartass, regardless of how good they are. If you interview one, it's a no hire. If you're unfortunate enough to find out there's one on your staff, it's pink slip time.
The interviewer didn't do so hot either. Instead of staying silent (mentioned a few times) when things got off track, he should have intervened.
Ultimately, the purpose of the interview is to allow the interviewer to become convinced to recommend hiring. If you're going down a path that isn't going to result in that, you're depriving the candidate of that opportunity. Not to mention wasting everyone's time.
Sometimes that means the candidate will have to adapt their answer to the interviewer. Everybody is different, and this is the interviewer who has been assigned. Occasionally, that may even mean dumbing down your answer.
Of course, for narrative reasons, the interviewer in this story has to be passive. Otherwise the story would be about 90% shorter.
The entire SV mythology relies on competitive smartassery. That's the reason for asking this kind of thing in the first place. The culture fit metric usually requires a minimum level of it too.
Someone is generally classified as a smartass when the balance of intelligence is on the smartass side. So this is just giving idiot managers carte blanche to fire people smarter than they are. For job security I guess.
Not sure I agree. I've worked with a few "smartasses" in my time, and it can be a real pain. Some people are absolute masters of the technical details of a subject, but fail to see the wider context.
For example, you get developers optimising the hell out of a block of code - making it unmaintainable in the process - when the real bottleneck is developer time, not processor time. Or someone builds a giant vector autoregression model powered by MCMC when a rolling mean would have been adequate for the task.
Build the simplest tool that will solve the task at hand is not a mantra that comes easily to some people.
I've worked with smartasses, and I've worked with many people smarter than me. While there can be overlap, there generally isn't, in my experience.
Smartassery is something I've most often witnessed in people having a need for self-assertion. Most really smart colleagues I've had are confident enough in their skills that they don't need to prove them by being smartasses.
> Someone is generally classified as a smartass when the balance of intelligence is on the smartass side.
Sometimes that's true, when a dumbass is involved.
At least equally often, though, that's what smartasses tell themselves either to avoid facing their social deficiencies or because they lack the self-awareness to recognize them.
Part of the reason why the blogpost is fun is the neat technical details and outside the box way of approaching small problems.
It's nice if the interview can be used to figure out if the interviewer/candidate want to work together.
I think it's fair to be frustrated at the "whiteboard interview questions" that most people encounter when interviewing.
I’m not sure I agree. I just rewrote code that another team member just wrote that was four layers of strategy patterns and factories into one single one page static class. Even they agreed that my code was easier to read and understand. I don’t think they could have written my version. Yet though. I’m trying to get them there.
My point is that it is sometimes easier to write complicated and unmaintainable code than writing clean and clear code.
If it's not code someone else could write, you aren't a disposable cog whose replaceability the company can leverage against you when negotiating compensation.
Conversely, well-written and document code that the maintainer wouldn't be able to make the leap to invent can still be maintained. Comprehension regularly exceeds ability to create.
