The best interview's I've done (very senior developer here) have been pair programming interviews. We have a suite of several problems and rotated through them to our candidates. The "problems" are a list of acceptance criteria for a program that we give to the interviewee a criteria at a time and they finish making the program up to the criteria they've seen so far. There usually a couple of difficult changes to the program as new criteria get revealed that need refactoring to achieve or at least careful thought. We sit with the developer and use a style called ping pong pair programming where we go back and forth as driver and navigator every test. The problems are about 5 AC each and can be done it about an hour and a half. We do it tdd style. It doesn't matter if they've never done tdd. It's easy with a guide to do it. Our company actually doesn't do tdd, but we do a fair amount of pair programming. The point of the TDD is to allow collaboration to switch back and forth as driver navigator and have a natural switch between the two. What this interview does is show a lot from entry level to senior level, how do they work, think, collaborate, problem solve as an actual developer. They're encouraged to work as you would work. You can use help/google/talking to the co programmer (the interviewer), just as you would while really working. The interviewer can help interviewees who need it in the form of collaboration. This help gets a lot of nervous people over their nervousness. This interview also reveals quickly if they have no ability to develop (i.e. they can't solve the problems or use the ide). I've had nearly half of the interviewees tell me this was the best interview they've ever been on. After the pair programming exercise we (the interviewer and interviewee) reflect and talk about it. This is where you actually do the senior developer interviewing. Talking about performance, repurcussions, re-use, refactorings, scaling, parallelisms. As you're doing the pair programming exercise, you get an idea and impression of what it would be like to work with the person and what their personality & work habits might be. From the hiring side. Every person I've decided to recommend hiring from this process has turned out to be a great addition to the company. I've never recommended somebody from this interview who quickly left or was a bad fit. I've also only ever heard of one other company doing this kind of interview, which is a shame, because the interview is basically work with me, solve a problem with me, do I, as the interviewer, like working with you and think you can work well in the company. We generally had one interviewer as a pair programmer and one other dev sitting and mostly observing and occasionally helping during the programming part of the interview and all three talked during the reflection part of the interview.
What really happens is you get a ticket that says "Our largest customer wants a report that shows XYZ sorted by the third letter of each users middle name by EOD. Freaking do it now!" This is the algorithm for "Don't waste your time with Big-O nonsense and code something already". This is the real-world scenario you will see most often and the business analysts in your company think of it as O(1).
I came up with a solution of the ”hard” interview problem in Python in 5 minutes. The tests you suggested I would have flunked. So you are definitely right.
Why do we technical interviews at all? Do other jobs work this way?
Every technical interview I've ever had is like two car mechanics sitting across from each other with the following exchange:
- What does a windshield do? Keep the wind out
- What does the vent do? Let the wind in
- What does the heat seater do? Heat the seat
- What does the stereo do? Play the beat
The questions I get asked are insipidly stupid, because the interviewer doesn't give a damn, because interviewing candidates is not a developers job, it's a managers job. And because he doesn't give a damn, I get ghosted as a moron for answering the questions correctly, just like I get ghosted for providing a working code test.
The only good interviews I've had in the biz were with managers only (no dev present), with only one exception - I once had a dev interviewer who actually had a paper printout of questions to ask, which were actually relevant to the job posting.
So as far as I'm concerned, we need to reject technical interviews, and being interviewed by devs. We should only accept interviews by managers, so we can be treated just like everyone else. Because just like everyone else, we have to be reasonably capable at our job to remain employed.
The best interview's I've done (very senior developer here) have been pair programming interviews. We have a suite of several problems and rotated through them to our candidates. The "problems" are a list of acceptance criteria for a program that we give to the interviewee a criteria at a time and they finish making the program up to the criteria they've seen so far. There usually a couple of difficult changes to the program as new criteria get revealed that need refactoring to achieve or at least careful thought. We sit with the developer and use a style called ping pong pair programming where we go back and forth as driver and navigator every test. The problems are about 5 AC each and can be done it about an hour and a half. We do it tdd style. It doesn't matter if they've never done tdd. It's easy with a guide to do it. Our company actually doesn't do tdd, but we do a fair amount of pair programming. The point of the TDD is to allow collaboration to switch back and forth as driver navigator and have a natural switch between the two. What this interview does is show a lot from entry level to senior level, how do they work, think, collaborate, problem solve as an actual developer. They're encouraged to work as you would work. You can use help/google/talking to the co programmer (the interviewer), just as you would while really working. The interviewer can help interviewees who need it in the form of collaboration. This help gets a lot of nervous people over their nervousness. This interview also reveals quickly if they have no ability to develop (i.e. they can't solve the problems or use the ide). I've had nearly half of the interviewees tell me this was the best interview they've ever been on. After the pair programming exercise we (the interviewer and interviewee) reflect and talk about it. This is where you actually do the senior developer interviewing. Talking about performance, repurcussions, re-use, refactorings, scaling, parallelisms. As you're doing the pair programming exercise, you get an idea and impression of what it would be like to work with the person and what their personality & work habits might be. From the hiring side. Every person I've decided to recommend hiring from this process has turned out to be a great addition to the company. I've never recommended somebody from this interview who quickly left or was a bad fit. I've also only ever heard of one other company doing this kind of interview, which is a shame, because the interview is basically work with me, solve a problem with me, do I, as the interviewer, like working with you and think you can work well in the company. We generally had one interviewer as a pair programmer and one other dev sitting and mostly observing and occasionally helping during the programming part of the interview and all three talked during the reflection part of the interview.
What really happens is you get a ticket that says "Our largest customer wants a report that shows XYZ sorted by the third letter of each users middle name by EOD. Freaking do it now!" This is the algorithm for "Don't waste your time with Big-O nonsense and code something already". This is the real-world scenario you will see most often and the business analysts in your company think of it as O(1).
I came up with a solution of the ”hard” interview problem in Python in 5 minutes. The tests you suggested I would have flunked. So you are definitely right.
Why do we technical interviews at all? Do other jobs work this way?
Every technical interview I've ever had is like two car mechanics sitting across from each other with the following exchange:
- What does a windshield do? Keep the wind out
- What does the vent do? Let the wind in
- What does the heat seater do? Heat the seat
- What does the stereo do? Play the beat
The questions I get asked are insipidly stupid, because the interviewer doesn't give a damn, because interviewing candidates is not a developers job, it's a managers job. And because he doesn't give a damn, I get ghosted as a moron for answering the questions correctly, just like I get ghosted for providing a working code test.
The only good interviews I've had in the biz were with managers only (no dev present), with only one exception - I once had a dev interviewer who actually had a paper printout of questions to ask, which were actually relevant to the job posting.
So as far as I'm concerned, we need to reject technical interviews, and being interviewed by devs. We should only accept interviews by managers, so we can be treated just like everyone else. Because just like everyone else, we have to be reasonably capable at our job to remain employed.