3 ms·
The problem with this approach is that interview nerves don't just stop you from writing complicated algorithms, they often cause people to forget or stutter ov
by lhnz 7y ago
The problem with this approach is that interview nerves don't just stop you from writing complicated algorithms, they often cause people to forget or stutter over trivial/simplistic stuff like syntax or popular APIs.
For example, recently I did a simple algorithmic coding test in JavaScript. The overall logic I wrote was completely correct, but there were two issues: (1) I accidentally missed a function call (which I caught later on after re-reading the code), and (2) I completely forgot about the API `Array#slice(start, end)` so had to recreate it using a loop.
When I'm doing this kind of test, often I get very dizzy and can't think straight. Once I wrote the correct code, but couldn't read the output that was printed. The interviewer remarked that the code was correct, and that's how I knew I'd not made a mistake. That is ridiculous: I was capable of writing the logic, but lost the ability to read.
The only other thing which makes me feel this way, is public speaking.
I have a decade of experience, and can generally solve the problem. It's demoralising that despite years of experience, I forget the most trivial APIs/syntax. I've literally done this every day for years of my life. I have no idea how I'm meant to prepare for this, because I've clearly practiced enough, and I am losing fundamental cognitive abilities.
In general, I am much better if: nobody is watching me while I do the test, and I have enough time for my most intense nerves to pass. Or if it is a take-home coding test.
I know sometimes people wish to argue that "you should be able to code under pressure', but I was able to meet crazy deadlines at startups by working fast. There's something different about having only 30 minutes, and somebody watching you screen, judging your every move.
- nobodyandproud 7y agoDo more interviews. It’s the only way to get used to it.
- hobs 7y agoThis "might" work - but there's plenty of people that no matter the number of interviews they flop sweat, forget, and generally feel fight or flight reactions, though medication might help. I have trained a lot of people and you see similar stuff with test anxiety - even if it is the easiest, open book, no pressure situation, I have had people openly weep and quit their job - the internal pressure is just too great.
- dragonwriter 7y agoStatistically, a substantial portion of the candidate pool will be on the low end of th curve there, even if they adopt that strategy, and even assuming it's an adequate way of dealing with the issue individually in the log term. So, unless the intent is to test for interviewing experience, the test isn't doing what it is designed to do, and is a bad test.
- lhnz 7y agoI hope this works. I am doing leetcode.com interview questions in my evening and definitely getting better at these. But, as I said, the problem is that when I feel under the magnifying glass, basic cognitive skills like being able to read what's on the screen, or remember a syntax I've used for a decade can escape me. If I was making mistakes on hard problems, I'd be more accepting. What I get in interviews is similar to forgetting super common words that you use every day ("thingamabob" doesn't gain the interviewer's trust).
- dmoy 7y agoYup I agree you need to cut people a lot of slack in interviews. Don't use the same rigor you'd expect from production code. Definitely as an interviewer you shouldn't care about syntax or remembering proper libraries. Even better, give hints about libraries, and maybe be proactive about saying you don't care about syntax. The coding under pressure line is bullshit, code under pressure ends up being bad code that makes things worse. Rollback under pressure sure. Look at monitoring graphs under pressure. Write new code? Helllll no. A lot of interviewers have unrealistic expectations though, it sucks.