More Than One Right Way
A while back, I did an interview loop for a dev role. It was my first one in a while, and I was nervous.
I spent a couple minutes discussing my method, and started coding. During the middle of it, I continued to run through scenarios in my mind, and captured and corrected several edge cases. With more time, I could have amended my style to something that matches the regular rubric for coding interviews: thinking deeply about edge cases, writing perfect code the first time. But my natural style is one of iterating aggressively, and that’s what came out. It’s the style that has lead me to a successful career for 9 years and counting.
After I was done, my interviewer told me “You have one of the strangest styles I’ve ever seen. You didn’t catch the edge cases initially, but you real-time corrected them as you encountered them, and had a bug-free solution at the end. It’s the weirdest style I’ve seen.”
Unfortunately the role didn’t work out, unrelated to the interview. But the experience made me think about how our processes could always be improved to measure what we’re really looking for. I think I certainly would have failed that interview with someone who was more strict about my approach matching some hypothetical ideal.