4 ms·

This. Real-time interviews are the worst of two worlds (emergency fast coding and live demonstration at the same time) and barely show anything about how one n

This. Real-time interviews are the worst of two worlds (emergency fast coding and live demonstration at the same time) and barely show anything about how one normally does things. E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. It helped me a few times when the servers were on fire and I needed to fix stuff fast and think later. But that's incompatible with live demonstration, unless the purpose is to embarrass myself and make me look completely incompetent or diffident.

vram22 9y ago
>E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment. A real-life example of what I said in the last few lines above: A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser): # init 0 (which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...
- yardie 9y ago
  Oh, I can only guess. A well run shop will have performance bonuses that the floor employees may depend on for vacation funding, college funding, or a down payment on a house. A shutdown like that can impact a weekly, quarterly or annual bonus severely. He may have inadvertently prevented someone from financing the house they wanted
jswizzy 9y ago
It's definitely a skill that doesn't translate to actual development. Before I was a programmer I was a Navy nuclear power plant operator and they did boards like that. In that situation, it made sense because you needed to be able to remember causality procedures during an emergency. Coding, on the other hand, doesn't have that requirement often if at all.
gt5050 9y ago
Real time coding interviews are really necessary to avoid hiring people who dont have basic proficiency in coding ( https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) The problem given in a coding interview should be a simple one and the candidate should be allowed to choose the solution language.
- daenney 9y ago
  A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Or having to feel guilty about reaching for Stack Overflow and wondering how that would affect their interviewer's opinion of them. Sure they could Google the question but then give them something that requires a litte bit of creativity on their side and ask them to talk through their submission. In an interview I'm much more interested in hearing how people would structure and architect applications, how they think about and would deal with tech debt, how they'd iterate and improve, how they think about reliability, instrumentation, testing and what not than having them solve a simple question in 30m. I'm not hiring people for a position that boils down to "solve a simple problem in 30m" either.
  - wildfire 9y ago
    > A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Who is paying for that time? As someone who has interviewed a lot of people; if I am going to ask someone to perform some coding, I offer them the fact that my entire TEAM (5+ people) will be there for them to ask questions of. That is us being serious about hiring. It isn't just a single person who is interviewing - but a large amount of the engineering team.

vram22 9y ago

>E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment. A real-life example of what I said in the last few lines above: A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser): # init 0 (which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...

yardie 9y ago
Oh, I can only guess. A well run shop will have performance bonuses that the floor employees may depend on for vacation funding, college funding, or a down payment on a house. A shutdown like that can impact a weekly, quarterly or annual bonus severely. He may have inadvertently prevented someone from financing the house they wanted

jswizzy 9y ago

It's definitely a skill that doesn't translate to actual development. Before I was a programmer I was a Navy nuclear power plant operator and they did boards like that. In that situation, it made sense because you needed to be able to remember causality procedures during an emergency. Coding, on the other hand, doesn't have that requirement often if at all.

gt5050 9y ago

Real time coding interviews are really necessary to avoid hiring people who dont have basic proficiency in coding ( https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) The problem given in a coding interview should be a simple one and the candidate should be allowed to choose the solution language.

daenney 9y ago
A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Or having to feel guilty about reaching for Stack Overflow and wondering how that would affect their interviewer's opinion of them. Sure they could Google the question but then give them something that requires a litte bit of creativity on their side and ask them to talk through their submission. In an interview I'm much more interested in hearing how people would structure and architect applications, how they think about and would deal with tech debt, how they'd iterate and improve, how they think about reliability, instrumentation, testing and what not than having them solve a simple question in 30m. I'm not hiring people for a position that boils down to "solve a simple problem in 30m" either.
- wildfire 9y ago
  > A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Who is paying for that time? As someone who has interviewed a lot of people; if I am going to ask someone to perform some coding, I offer them the fact that my entire TEAM (5+ people) will be there for them to ask questions of. That is us being serious about hiring. It isn't just a single person who is interviewing - but a large amount of the engineering team.