Constanly. I've been through an exciting decade of software development. I interviewed many people and hired some. Being in a mixed soup of engagement models – full-time employment and freelancing/contractor work I have a perspective from both ends.
In the beginning, I put a lot of effort into whiteboard interviews and technical questions and paid close attention to answers.
This over the past decade, and eventually when hiring for my own company, transformed more into a casual talk with the candidate because:
1. Everyone who can code can probably put together something in React.
2. Leetcode is a pretty bad indicator of nearly anything. As someone who studied math and solved many Leetcode problems on different websites more than a decade ago, you don't need any of that to build web apps.
3. There is no way to accurately assess the person's willingness to work and contribute in a couple of hours, so you have trial periods.
Because I'm moving back to FTE, I'll get stuck on some whiteboard interviews with counting the stop signs in Chicago. But the truth is, I'm confident there's missing critical work in any organization making software that I can effectively work on and bring to the next level. Unfortunately, there is no way to learn this through interviews.
Current interview system is built around scalability and repeatability. Companies do not want to create an elaborate training process to conduct interviews. So what they do instead?
1. Hand out a cookie-cutter set of bland questions which are asked for the sake of it.
2. Conduct Leetcode style interviews where problems are available aplenty and interviews don't have to put effort in preparing for the interview
Constanly. I've been through an exciting decade of software development. I interviewed many people and hired some. Being in a mixed soup of engagement models – full-time employment and freelancing/contractor work I have a perspective from both ends.
In the beginning, I put a lot of effort into whiteboard interviews and technical questions and paid close attention to answers.
This over the past decade, and eventually when hiring for my own company, transformed more into a casual talk with the candidate because:
1. Everyone who can code can probably put together something in React.
2. Leetcode is a pretty bad indicator of nearly anything. As someone who studied math and solved many Leetcode problems on different websites more than a decade ago, you don't need any of that to build web apps.
3. There is no way to accurately assess the person's willingness to work and contribute in a couple of hours, so you have trial periods.
Because I'm moving back to FTE, I'll get stuck on some whiteboard interviews with counting the stop signs in Chicago. But the truth is, I'm confident there's missing critical work in any organization making software that I can effectively work on and bring to the next level. Unfortunately, there is no way to learn this through interviews.
A nice trick that may reveal more about a candidate mentioned in Kim Scott's book, Radical Candor, is to walk the candidate outside.
When outside of a stressful environment, the candidate might feel more free to reveal his actual personality.
Great point! I did most of my interviews on a video call. You may try to create a casual environment there, but it doesn't always work.
I completly agree about the trial periods. I wonder when internships for seniors will start to become more common.
I didn't even know it was a thing, but it sounds great!
Let me join the chorus "Interviews suck"! :D
Current interview system is built around scalability and repeatability. Companies do not want to create an elaborate training process to conduct interviews. So what they do instead?
1. Hand out a cookie-cutter set of bland questions which are asked for the sake of it.
2. Conduct Leetcode style interviews where problems are available aplenty and interviews don't have to put effort in preparing for the interview