3 ms·
For example, can he suggest what sensors would be good for a Lego robot that would knock a tennis ball off the ping pong table without itself falling off? Righ
by kafkaesq 9y ago
For example, can he suggest what sensors would be good for a Lego robot that would knock a tennis ball off the ping pong table without itself falling off?
Right off the bat, this is very muddled question to ask.
For one, "sensors"? I think you meant to say "actuators". Because a sensor by itself can't knock anything off a table.
More fundamentally, "Legos", for those of a certain age, were entirely non-mechanical components in their day. So (even though yes, we've also vaguely seen and heard about, and rolled our eyes at, the newer kind), this just sounds like asking them to (seriously) consider the question of how to build a logical circuit out of tinker toys. Yes, it can be done - but on the face of it, that kind of a question comes off as an invitation to join a mental masturbation session. Not the kind of question you'd ask of someone you respect, and whose time you know to be as invaluably precious as you own.
The person who can give sane answers on those would do a lot better than a coder who knows one toolkit well and nothing else.
This is of course a false dichotomy. Especially given that it was -- not sure how else to put this -- a silly question to ask in the first place.
- chrismcb 9y agoDoesn't seem like a very middle question to enjoy. The question basically sats you have "Lego robot that can knock A tennis ball off the long long table." So you already have a robot that can knock this off the table, it really isn't important that if it's made of Legos or not. Now what sort of sensor would you add so it won't fall off the table as well. It specifically asks about the sensors. Don't make questions harder than they are
- watwut 9y agoI have no ideal what the question asks for. What kind of sensor are there? And I did lego robot a while back for optional credit in college (mine worked well).
- kafkaesq 9y agoDon't make questions harder than they are. There's no need to make it any "harder" - the point is that just wasn't well-articulated to begin with. (Noting again that "well-articulated" is very different from fuzzy / ambiguous, in the engineering sense). And given that the people you want to hire, by definition, are generally very busy (and have many, many important things to do with their time) -- even when they aren't currently working (despite the urban legend that "they always have jobs") -- as such, it just isn't a good use of their time.
- ptero 9y agoI think you nailed the disconnect between our views. What I personally am looking for is an engineer -- someone who can look at problems formulated in a fuzzy fashion (this is critical), figure out what technical solutions exist, probing the customer/user to flesh out the initially vague requirements and come up with a few different ways to implement this. You are looking for coders: someone who can take well posed, unambiguous problem and algorithm descriptions and turn those into a working code. That is probably a better fit for a "coding interview" referred to in the title. It is just my experience that I get much better code and value for $ by hiring engineers even though I have to pay them higher salaries. That's just me though, YMMV.
- kafkaesq 9y agoYou are looking for coders: No I'm not - I'm very much looking for engineers in the mindset you describe. I just don't think your Lego robot question is a good tool for sniffing out that mindset. (For the simple reason that "muddled interview question" != "fuzzy real-world problem" - in fact there's a world of difference between the two). But then again, we have a disconnect. Which is of course totally fine.