Originally published from Books on Code
There is a reason programmers are prone to imposter syndrome. Failing a technical whiteboard coding interv...
For further actions, you may consider blocking this person and/or reporting abuse
I am a developer with 30+ years experience and a degree in computer science. This article describes code interviews very well. This is how nonsense it is. Developers do not code at whiteboards and on paper. We code on computers using code completion and google. So interview should test how good you at that not at something else. But they test you at something else because interviewers just that dumb. They can't understand simple things. You need to tell this to them at the beginning of your interview instead of trying to be good at something that is not your job. I am wondering when this will all change...
Don't forget about the human part of the interview. I judge someone who says "I don't know" a lot better than someone that tries to BS through it.
once upon a time, someone ask me how I did a small algorithm, when I answer, looking on stackoverflow, how to do it, cause I don't have the minimum idea of how to do this. Looking back maybe I was wrong, idk to me was... "I resolved the problem, right?"
cheers
This is a very good point. I didn't focus on behavioral stuff in this article, but it's also crucial.
The whole post is showing a way to brute force an algorithm with an unnecessarily high mental cost. If you apply TDD instead of brute forcing your brain, you'll start testing the null cases instead of leaving it for later and use the following tests as tools to drive your thinking by using the transformation priority premise. For that it's better to have a computer, as you want to make sure your code is correct at all times.
It's like studying to apply for some work involving physics and having a test asking how much is 3*2/4+343-221/45^7-6 without allowing you to use a mere calculator or to show how to apply actual meaningful physics concepts instead of complex basic math