642 karma · joined January 30, 2015
The article then goes on to explain that OP basically spent a weekend writing a book report about some pop science YouTube videos. What a joke.
A senior candidate has a serious, revenue-generating side business, maybe in a competing product area? Yeah, that seems like cause for concern: this candidate's potentially-dropped cycles working on their business could mean a significant loss in team productivity, we might worry that they're on the verge of quitting to focus on their own product, whatever.
An intern candidate has a side hustle? Awesome, sounds like they're not totally clueless, likely they'll be able to ramp up quicker than someone with less experience. Ideally they put it on the back burner for the internship duration but nothing is going to collapse if they're not functioning at 100%. I feel like it's a much bigger risk that you hire someone with a weaker resume and get nothing from them even when they try their best.
Who on earth is spending hours writing a single regex?
"Get here in 3 hours or you're fired" is just trying to humiliate people, it's not even pretending to be a technical challenge.
Clearly pitching it as an actual, authoritative source of info was not the right call
If the Haskell compiler is spitting out "ambiguous instance of +" or whatever that error message is, it's a sign that the author doesn't understand what they're asking for. Taking a language whose value proposition is "I refuse to compile your code if there is the slightest indication that it's not perfect" and slapping a fuzzy ML model on top of it to suppress a class of errors is not a good idea.
Type systems exist as a way of ensuring that the programmer's mental model matches the code. Offloading type annotations to something else removes that safety from you.
> no priors
Sure? I don't see how that changes anything. My point is just that we already have very high quality summarizers of code, but software development is still hard. Making a model that attempts to approximate the summarizers of code that we already have isn't going to help much, no matter how good it gets.
I think the Kolmogorov complexity of serious production codebases is very high -- in order to convey what the codebase does, you have to transmit roughly as many bits as the codebase itseld. In most companies, you already have a way to get a "compact, human-readable description" of what the code does -- it's called asking your coworker, or reading your internal documentation. Ramp up is still hard.