Feels very weird to me to spend time and energy building tools for a type of interview process that is becoming more and more derided by the community?
Codecademy pioneered a more interactive REPL style of learning for basic programming.
I felt that this interactive step-by-step approach could be used to learn other parts of Computer Science more efficiently.
Because of algorithms being highly represented in software engineering interviews, it seemed like a good place to start. But this step-by-step format could also be used to teach other parts of Computer Science.
I personally loathe these types of interviews and don't administer them myself. Nonetheless, it isn't going away anytime soon and I am willing to practice for it if needed.
In practice this means creating a small example project with all of the tedious boilerplate ready and in place and asking the candidate to implement 1-3 relevant stories on it.
It's not the streetlight effect that got the industry into this sorry state. It's a combination of cargo culting and laziness.
Unfortunately, the fact that it is generally considered a flawed process by the community, doesn't mean the this kind of interviews are not required or common anymore.
That HNers hate them provides a nice circle-jerk, but doesn't help you get the job.
Its amazing how many people phone me "for a chat" after seeing my Linkedin profile then expect me to jump in to do their coding test. You have to convince me that I actually want to work for you first. If I haven't spoken with anyone technical about the job then its a definite no.
If they have written it they should be able to discuss it and answer questions easily.
If someone else wrote it and they have understood it enough to discuss it, you probably have an even better developer, especially if the job involves working with some legacy code.
That can be really difficult for a lot of candidates. It's predicated on the idea that they've written code they:
a) Feel comfortable sharing (not just a one-off weekend hack project)
b) Are allowed to share, legally. This is usually the real problem for most developers.
The truth about hiring: There really isn't any one-size-fits-all that works for everyone. Any hiring process you come up with is going to be an incredible obstacle for a sizable minority of people.
Honestly? Because companies view those kinds of questions as proxies for IQ tests (which are mostly illegal to use as a hiring method). Notice the defense of them largely revolves around "seeing how you solve a problem" and "how you communicate your problem-solving ability". They're seen as measures of your intelligence, which is what they're actually interested in--not your experience or expertise (outside of specific areas).
Those interviews are, of course, something you can easily (with a serious time commitment, but fairly easily nonetheless) prepare for and game, which of course makes them bad proxies for intelligence. And of course, I don't think algorithm questions necessarily measure someone's actual intelligence at all. And of course, it's unclear how highly intelligence is correlated with your ability to succeed as a software engineer.
But that's why. I have little doubt that they would actually try IQ tests if they thought they could get away with it. I'm fairly certain at least one major company tried asking candidates for SAT scores.
Assuming a certain level of intelligence, that is.
If you base your hiring decision on how awesome they are at leetcode hackerrank style algorithm questions you're selecting for bullshit artists who memorized "cracking the coding interview".
There's a systematic industry-wide bias against realism in developer tests. It's depressing how many people think realism either isn't necessary or isn't possible within typical interview time constraints.