If your normal work environment is anything like a whiteboard interview, I want nothing to do with your company.
Again I don't want to work at this company.
What do you mean no time to Google? You're never going to be able to remember everything. Sure the ideal situation is that you're fixing a bug where you happen to know the exact syntax for every piece of every library you need.
But in the very likely situation where you don't, of course you have time to google.
>and the ability to code something up quickly that also works correctly without having time to test it sometimes saves the day.
Often becuase the company has optimized the hiring process for people who are good at doing this vs. people who are good at designing maintainable, durable systems.
If 30 minute, million dollar fixes is a frequent enough occurrence to make aptitude at them the primary or even a major factor in your hiring decision, you have done something horribly wrong.
>I do think coding interviews that people are complaining about are good, and getting in shape to do well in them is good for you.
Having hired people using many different techniques, I think that these types of interviews are only a bit better than random chance. They are a separate skill from 99% of daily programming work, and they are gameable. I also think they are nothing more than a fad caused by people cargo culting Google.
Not a single other technical discipline widley uses this kind of stage performance based interview process. Not one.
>and you want to be talking to someone while you're doing it, as a sanity check.
That makes zero sense. Sure sometimes it helps to talk through a problem if you're working with someone who is also trying to solve the problem with you, and you might want to explain a fix after you solve the problem but before you push as a sanity check.
But if it's a hard problem you can kick rocks if you expect me to explain what I'm thinking about while I'm concentrating on solving it--while you're watching over my shoulder, and are not actively engaged in helping me solve the problem. You're just slowing me down.
I also can't remember ever being asked to solve a problem whose solution would have merited publication in my lifetime, and I was born around the same time Unix was.
>I also can't remember ever being asked to solve a problem whose solution would have merited publication in my lifetime, and I was born around the same time Unix was.
We've had different experiences then. I've definitely had to implement algorithms designed after 1971.
I agree that for GUI work you probably don't need this, but for a back end position I would like a person for whom this kind of interview isn't a big deal to prepare for.
I'm curious to hear what the post 1971 algorithms in question are.
Any engineering disciplines that deal with designing processes are very similar to software engineering. It's nowhere special enough to demand a completely unique hiring process.
Even if it were, I'd like to see some hard data to support the current interview best practices.
>I'm curious to hear what the post 1971 algorithms in question are.
Off the top of my head: You've had a question with Red-black trees? B-trees? Quad-trees and oct-trees?
For Red-Black and B-Trees, I've never heard of anyone being asked to implement the entire thing from scratch, but significant portions sure. Also explaining the implementation of significant portions.
Here's a similar post from 2015 by tptacek
>You're a 55-year old engineer who graduated from school in '81. You're being interviewed by a 24-year old engineer who graduated 2 years ago. You're asked, in an "algorithm interview", to explain some detail of the implementation of an AVL tree.
>In reality, despite the fact that they're covered in CS courses, virtually nobody uses AVL trees in industry. In fact, people barely use balanced binary trees at all, and when they do, they use red-black trees, and they use someone else's implementation, because they're a bear to debug.
>The 24-year old has an advantage with this question because they were recently taught about, and perhaps had to do exercises/homework/tests based on, AVL trees.
>That this happens is stupid, because it's very unlikely that conversance with AVL trees is going to make much of a difference to your on-the-job performance. Almost all the narratives you can come up with about this involve reading tea leaves and are shot down easily by better selection/hiring/interviewing techniques that answer questions more directly.
>This line of questioning can go too far; I don't, for instance, think knowing the big-O characteristics of an AVL tree is unreasonable (it's a balanced binary tree, and you should have the complexity of operations on those in resident set throughout your career).
Here's another coment from tptacek in the same thread. If you don't know who he is--you definitely want to hire him if you can. Him failing out of your hiring process would be a travesty.
>I was asked to do Bellman-Ford. I bombed that question, and was so shaken that I bombed the rest of the interview as well.
>The irony was, I'd just spent the preceding 2 years writing multicast link-state routing code. I could have coded a decent C++ Bellman-Ford in a couple hours, but couldn't pull it out of my head on the spot in an interview without babbling. (I tried to dodge by describing link-state LSP forwarding and then Djikstra, but wasn't given credit for knowing the more sophisticated algorithm).
>Algorithm interviews suck. We should stop doing them entirely.
>Getting rid of coding interviews won't stop some interviewers from being jerks. I much prefer being rejected for bombing a coding interview, than killing it and then getting rejected because of the behavioral interview
The same thing applies to your point. Coding interviews don't replace those issues they just add another hoop. What do you think behavioral questions, lunch interviews, and culture fit are?
>where someone 20 years younger than me acts like they can figure me out by asking me a bunch of silly questions.
Based on what I've observed this is what currently happens. 99% of companies have a terrible process for developing questions and evaluating responses.
And programming is pretty much the only field where it's the norm to be interviewed by someone much younger than you.
The issue with not being able to Google isn't Google specifically, it's the lack of all the tools you use to solve real problems.
I'm with you on this one, if working at a company induces interview levels of a stress daily, even regularly, then please don't hire me.
To make matters worse, it seems that I project this aura of calm and self assurance, or so I've been told by two of my interviewers after they hired me, so that I don't even get a concession for obvious nervousness.
handling stress = managing emotions = maintaining emotions in a stress-test