3 ms·
The tide is definitely turning. The last two interviews I've been to were nice casual affairs where me and another engineer had a technical discussion on how I'
by jerrylives 9y ago
The tide is definitely turning. The last two interviews I've been to were nice casual affairs where me and another engineer had a technical discussion on how I'd approach various problems they were having (such as deployment woes, wonky network topology etc). The best part is that I feel like I learned something as well, rather than just being shown my failure because I didn't get the interviewer's "trick" to how to solve his convoluted non-practical coding puzzle.
Both of these companies I can gladly say are some of the best places I've ever worked with bright, motivated engineers and a great culture. I think part of it is that if you know your stuff, you'll be easily able to suss out who is bullshitting in a discussion / debate and who isn't. If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities.
- gaylemcd 9y ago> If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities. I agree with this. I tell companies to not ask questions from Cracking the Coding Interview. But that doesn't mean those style of interviews are fundamentally broken. It's just stupid to ask questions that candidates are likely to know.
- jerrylives 9y agoIndeed, I don't write off whiteboard interviewing altogether - if you know exactly what you are hiring for, it can be very helpful to have e.g. a systems engineer write out some C code or go through tree problems. The issue comes in that a lot of people aren't entirely sure what they are hiring for, just that they need a warm body who can code to some arbitrary ability. That's why I always make sure to ask the interviewer what the burning problems are and what kind of action they are looking for on Day One.