4 ms·

I interviewed at Apple once. In the second technical call on codepad I was struggling with something really basic in Python (which I have 15+ years experience w

by orf 6y ago

I interviewed at Apple once. In the second technical call on codepad I was struggling with something really basic in Python (which I have 15+ years experience with) due to nerves and the general weirdness of the situation. My struggling stressed me out, which made it harder to concentrate, which stressed me out, etc. While I was struggling the interviewer said "come on, if you can't answer this then how am I going to convince anyone you're a good programmer?". That spun me out and I crashed even harder. In his eyes I'm one of those 199 people who "can't even code". Fuck 'em, if coding is knowing how to implement weird palindrome-related algorithms in a completely alien browser-based IDE (if you can call it that) over a call with a several second delay in your kitchen at 9pm local-time after a hard days work then maybe I can't code.

_qulr 6y ago
> I interviewed at Apple once. In the second technical call on codepad I was struggling with something really basic I had a very similar experience. Moreover, on the phone call there seemed to be some kind of soft ticking sound in the background, like a clock. It was very distracting. I wonder if the interviewer was actually timing me.
tharkun__ 6y ago
That sounds like an absolutely horrible experience. I detest live programming exercises for the same reason. From both a candidate perspective and mine as a hiring manager now. At my current place (and before as well) we give the candidates a 'take home test'. The problem is a bit larger than FizzBuzz, so that we can see how they would structure things, if they can write clean code, write tests etc. The 'take home' nature solves quite a few of the problems you mentioned, both for the candidate and us if you ask me. And even there you have to be careful that things don't get out of hand. Nobody good who currently has a job is going to spend any time on a take home test that the employer expects them to spend hours upon hours on over a short period of time. Of course there are always managers that fear it's too easy to cheat but if you ask me, that's either never happened to us or if so, it was very clear after talking to the candidate in person about their code, that we wouldn't hire them anyway, so at best they cheated us out of some interview time.

by orf 6y ago

_qulr 6y ago

> I interviewed at Apple once. In the second technical call on codepad I was struggling with something really basic I had a very similar experience. Moreover, on the phone call there seemed to be some kind of soft ticking sound in the background, like a clock. It was very distracting. I wonder if the interviewer was actually timing me.

tharkun__ 6y ago

That sounds like an absolutely horrible experience. I detest live programming exercises for the same reason. From both a candidate perspective and mine as a hiring manager now. At my current place (and before as well) we give the candidates a 'take home test'. The problem is a bit larger than FizzBuzz, so that we can see how they would structure things, if they can write clean code, write tests etc. The 'take home' nature solves quite a few of the problems you mentioned, both for the candidate and us if you ask me. And even there you have to be careful that things don't get out of hand. Nobody good who currently has a job is going to spend any time on a take home test that the employer expects them to spend hours upon hours on over a short period of time. Of course there are always managers that fear it's too easy to cheat but if you ask me, that's either never happened to us or if so, it was very clear after talking to the candidate in person about their code, that we wouldn't hire them anyway, so at best they cheated us out of some interview time.