[granshaw]

Yes. That kind of stress would be like trying to fix an issue causing the company to hemorrhage money within 30 mins without being able to google anything and with others looking over your shoulder and wanting you to explain your thoughts. Oh and you have to get it correct on a whiteboard first

[milemi]

These situations do happen in real life, minus the whiteboard.

[learc83]

You can't google anything, and people expect you to explain your thought process while solving an emergency issue with a 30 minute deadline?

Again I don't want to work at this company.

[milemi]

Sometimes there's no time to google, and you want to be talking to someone while you're doing it, as a sanity check. https://dealbook.nytimes.com/2012/08/02/knight-capital-says-... $10M/minute is an extreme case, but these things happen on a smaller scale all the time. I'm not saying this is the justification for coding interviews, just saying that it happens, and the ability to code something up quickly that also works correctly without having time to test it sometimes saves the day. 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. You can tell it's good for you just by the amount of complaining people are doing :)

[learc83]

>Sometimes there's no time to google

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.

[milemi]

None of the problems at interviews are really hard.

[learc83]

Many problems have solutions that were worthy of publication and took a lot longer than 30 minutes for very smart people to solve. So if you don't already know the answer or the answer to a very similar problem then yes objectively they are hard problems.

[bydl0coder]

Here's the difference - when shit hits the fan everyone in the room wants to solve the problem and they are actively helping each other. Technical interview is completely different.

[rrhyne]

We conduct it as a working session. Our primary goals are to determine ability to reason about problems, apply the proper technique (not syntax), the ability to communicate with us about what they are doing clearly and to get a sense of how they work during the planning phase of a project. We are looking for a connection with the prospect more than a complete technical solution.

[verletx64]

Worth saying, sometimes there’s nothing to google, or googling wouldn’t yield a significant answer - perhaps the issue lies in some module of fairly home grown code.

[learc83]

Sure that happens, but you probably have access to internal documentation, a compiler, a REPL--something.

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.

[milemi]

Google, or any other reference, is the hard drive, and the skill you have in your noggin is the cache. You wouldn't want to buy a machine that's all hard drive and no cache.

[learc83]

That analogy isn't a refutation of anything.