4 ms·
I'm sorry to hear anout your experience. Whiteboarding is tough, from both ends I think. How do you decide in 1 hour if you want to invest 1 month of a team's
by Swizec 9y ago
I'm sorry to hear anout your experience. Whiteboarding is tough, from both ends I think.
How do you decide in 1 hour if you want to invest 1 month of a team's time to see if the candidate was a good hire? It's a tough problem.
When I do interviews I try to make them worth the candidate's time. My approach is to ask just one key question: "Pick an algorithm you like, one you've invented or one you've read about, and teach me how it works"
This I think balances the power dynamic since it puts the candidate in control. And it gives them a chance to show off, should they choose to do so. Plus I might learn something.
Afterwards I start throwing additional information at them and try to twist the algorithm they presented into unfamiliar situations. This gives the candidate a chance to learn something new, I hope. I taught one candidate about impractical theoretically awesome O(n) sorts this way.
But people whom we've hired after such an interview told me that at the time they felt like they failed the interview even when they did smashingly well.
Anyway, I'm happy that you eventually got the job! I wish people spent more time trying to make it fair to the candidate.
- vinhboy 9y agoI appreciate this stuff immensely. In one of my interviews, the interviewer was teaching me stuff. He asked me if I knew about this and I said no I haven't used it. Then he showed me how. It was a good experience. Edit: I remember now. He taught me how to use Pry. Now I use it daily.
- walrus1066 9y agoOut of curiosity, why the focus on algorithms? Does your work genuinely involve understanding the implementation details of various algorithms? If so, could you provide an example? I'm genuinely curious.
- Swizec 9y agoAn algorithm is a series of steps to do a thing. In that sense everything I do is understanding and implementing algorithms. From wikipedia: An algorithm (Listeni/ˈælɡərɪðəm/ AL-gə-ri-dhəm) is a self-contained sequence of actions to be performed. Starting from an initial state and initial input (perhaps empty),[4] the instructions describe a computation that, when executed, proceeds through a finite[5] number of well-defined successive states, eventually producing "output"[6] and terminating at a final ending state. I mean, if you're not writing code that takes inputs and produces outputs, then what the hell are you doing? The point is to test candidate's ability to impart knowledge and to learn and to quickly adapt new information into the way they solve a problem. You can be the best coder in the world, but if I can't understand your code enough to be able to maintain it, you are going to be a pretty useless team member. Similarly, if you can't adapt your technical solutions to new information quickly, you're going to have a hard time keeping up with our product team. Hell, I'd be perfectly happy if you explain to me the algorithm (recipe) to make the perfect barbeque ribs. That shit's complicated too.