3 ms·
"Only a portion". And almost-perfectly is a big deal. You're not expected to write compiler-ready code, just to show that you understand what's happening under
by nostrebored 10y ago
"Only a portion". And almost-perfectly is a big deal. You're not expected to write compiler-ready code, just to show that you understand what's happening under the hood. Which meshes up with practical expectations -- if you can't understand what potential bugs/space/time complexity you're introducing when leveraging a library, then you're a fundamentally worse coder than someone who can.
- estefan 10y agoExcept this is in fact bullshit since if you're ever working on some speed/memory critical code, that's the time to bother filling your brain with the different options available and picking the appropriate one. Carrying around arbitrary knowledge to show off is pointless. Most code most programmers write won't ever run at sufficient scale or be sufficiently critical that CPU or memory bounds will matter, and using e.g. one sorting algorithm vs another will be largely irrelevant. It's recognising when you need to bother optimising that is the sign of a competent developer. And asking someone to write actual (not pseudo) code on paper/whiteboards - as I've seen in interviews - is like assessing someone's driving ability by asking them to mime driving a car.
- cmrdporcupine 10y agoI agree. But it's worth pointing out that a Google style interview also includes some portion which is "system design" oriented which would touch more on that kind of thing. But they're more interested in avoiding false positives, than false negatives. So the process is designed to weed out most people.