It reminded me at the time where I was working at a 20 person startup and developing spike prototypes ahead of the other 15 developers. My favorite praise that I'd get from management was that my plans were "simple but not simplistic".
The software equivalent of "an ounce of prevention is worth a pound of cure". I will note, however, that the reviewer that Goedecke is disagreeing with isn't necessarily wrong, if the goal of the challenge is not just to create the absolute best possible code but to also demonstrate mastery. It would be a hell of a flex to write a complicated script though, then comment out everything that wasn't absolutely necessary and just leave the simple necessities.
> It would be a hell of a flex to write a complicated script though, then comment out everything that wasn't absolutely necessary and just leave the simple necessities.
"Reviewer note: The submission ignores best the practice of writing self-documenting code, and included too many comments"
Respectfully disagree. It shows that the interpretation of the solution to a coding challenge is highly subjective.
How I use coding challenges when hiring is by first forming my opinion about a given approach. Did this person try to stand out? Does he/she use novel constructs? Stick to what they know? Do they “practice what they preach” on their resume/first round? Etc.
After this, discuss with a colleague to reduce bias/subjectivity. Finally, invite the candidate to discuss the solution. Ask them to review (parts of) their own code as they would a colleague’s PR. This way, the assignment becomes a tool to start a conversation.
At least you get the chance to demonstrate some of your creativity and forethinking with a code challenge. LC style timed questions are just turn off your brain and regurgitate.
"An idiot admires complexity, a genius admires simplicity. A physicist tries to make it simple. Anyway, an idiot, anything the more complicated it is, the more he will admire it. If you make something so clusterfucked he can't understand it, he's gonna think you're a god cause you made it so complicated nobody can understand it."
LIDAR is more complicated than camera-only approaches. Human drivers have just two eyes, surely software can do better than humans with more eyes that have better resolution than our own. Simple.
This is the greatest example of simplistic planning.
Human drivers have two eyes and a brain evolved for storing visual hints.
And LIDAR is not that complicated, too. Just not the simplest thing, that would be rails and pantographs, whatever you would translate those to your vehicle.
I'd bet it's a lot easier to write high reliability self driving software when you have multiple redundant sensors that don't all go to shit when it's foggy. There's probably a good reason that after a decade of r&d, every major player in this space with the exception of the one run by a narcissistic moron is using radar, lidar, and cameras in their sensor suite.
Humans can't drive safely in the fog. They can drive safely on a road travelled often even with low visibility by using visual hints they need to "scan" at lower speed. No car taking a cam approach for self-driving is doing that btw.
And yet, conceptually, there's still no capacity humans have that camera-only autonomous vehicles can't be given, even if they don't have it right now, right?
Theory says so, facts paint a different picture where CV systems are foiled more often (in good visibility conditions) than the same situation where a human could be foiled with camouflage or trompe-l'oeil.
Something is missing, time will tell if training will produce more solid models.
reply