An important goal of programming language design should be to make it as hard as possible to come up with stupid tricky interview questions.
-
-
Well, it's indeed better than C++ or even C. But I'm not even sure it's better than JavaScript in that regards.
-
The good thing is: in Rust the answer to most of the tricky questions for those other languages would be “it fails to compile” instead of “it does some insanely stupid shit that will haunt you for days in production”.
-
If it fails to compile, it's not a tricky question :)
-
<show code>. Q1. “What is misleading about rustc’s diagnostic here?” Q2. “Fix the code to compile (and work)”
-
I haven’t shown the code yet but I could come up with some tricky examples. They wouldn’t be usable forever, assuming compiler diagnostics and language expressiveness improves over time. But still seems like it would fall into bucket pcwalton defined.
-
Still, I admit that as an interviewer, i would need to *work* to do this. And thus
@pcwalton’s desire may be met in this instance. -
I'd rather choose any of problems which Rust doesn't consider unsafe - memory leaks, panics, etc. - which are relatively easy to trigger with just standard library and minimal examples - and ask to find them.
-
(these might fall into tricky questions bucket, but not useless ones IMO)
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.