3 ms·
""" You should not be testing people’s ability to recall some obscure definition in an interview. You should be testing people’s ability to tackle something the
by KittenInABox 5y ago
"""
You should not be testing people’s ability to recall some obscure definition in an interview. You should be testing people’s ability to tackle something they can’t recall off the top of their head. And, you should allow them every tool they have available.
If they’re totally unfamiliar with the problem, and yet they make significant progress in just one hour that should be interpreted as a good sign this person would provide a lot of value to your company
"""
I think this is extremely important. A developer that can make a lot of progress on something they haven't seen before is often times just as good as a developer who can tell you the big-O efficiency of reversing a red-black tree off the top of their head. Although the latter may indicate a very interested systems-level hobbyist, which is also an excellent value in terms of an engineering quality but impossible to tell from a whiteboard interview if they're a hobbyist or if they just studied.
- monkeybutton 5y agoJust as a counter point, developers that have such a knowledge about algorithms and efficiency tend to be able to sort through different possibilities and branches investigation for new problems much quicker than a developer that has to look up everything on the way. Although that's something that can just come from experience too.
- KittenInABox 5y agoI can't tell during my limited time in an interview if a developer has that knowledge because they crammed (and therefore will forget quickly on the job) or if they actually study and understand this stuff. I can tell during my limited time in an interview if a developer is capable of making logical deductions and not flail when exposed to a problem they may not have seen before. And, better yet, if they do study algos for fun, this will become apparent!
- monkeybutton 5y agoThat's fair, cramming algos is easier than cramming intuitive problem solving skills.
- Clewza313 5y agoHonest question: just how often do you actually need to worry about algorithms in your day to day work? The vast majority of software dev, even/especially in hot startups and the like, is bog-standard CRUD and 99.9% of the time the correct response to "I need to do something slightly complicated" is "call an existing library function".
- ZephyrBlu 5y agoThey specifically said "for new problems", not bog standard CRUD.
- monkeybutton 5y agoI'm working with/adjacent to data scientists and it comes up fairly often. Do startups not have anyone doing some kind of analysis for them?
- Clewza313 5y agoI mean, this is the whole point of the dreaded coding whiteboard interview, no? You can't memorize your way out of it, and with any luck the interviewer will be looking at the big picture of how you tackle the problem and what headway you make, instead of sniping at syntax or the names of library calls.
- Aeolun 5y agoHuh? All the whiteboard interviews I’ve ever had have been easily memorizable problems.
- Aeolun 5y ago> just as good as a developer who can tell you the big-O efficiency of reversing a red-black tree off the top of their head I’m not really interested in whether or not they know this. I’m more interested in whether they can explain it to me.
- KittenInABox 5y agoI would also be interested in this, but it's also something simply crammable. It's impossible to know from a limited interview time just from trivia whether or not someone just crams last minute. I'm more interested in knowing if they can debug something nasty or opaque with patience and using deduction instead of flailing. Chances are the person who can do this might also be able to explain why a red-black tree inversion is a certain O-notation, but its not strictly necessary.