How can you hire Tennex engineers a lot more effectively? This is a problem that I faced early in my career when I made a bunch of higher turning mistakes, I hired engineers who had great resumes, who talked a good game when they talked about their experience. But in practice, we’re not able to deliver. And being a Tenux engineer doesn’t mean you’re good at interviewing for Tennex engineers.
Ironically, I worked with some amazing Tennex engineers who were really awful at making the determination themselves. I can mostly just talk about my own experience. I think I’m pretty good at figuring it out now. And I figured out how to do it fairly early in my career. But at the very beginning, I made a lot of mistakes. I would hire people based on their resume, based on asking them about their experience, what problems they worked on. And it turns out that a lot of people can tell a great story about what they did, but in reality, they may not have been the person who came up with the techniques or actually solve the problem they can describe what their team did, but that doesn’t mean that they can work on a new problem themselves very well at all.
One of the things that I would say, I absolutely think is a mistake is using lead code as a interview question. The biggest problem with Leap Code is that there are many websites that just list out a whole bunch of leap code problems. And so the engineer may have spent a lot of time studying these problems and just memorizing the solution. Memorizing is really pointless in software engineering when you can just Google things.
Again, the problem with dynamic programming is the technique is relatively straightforward. So if you’ve seen the problem and the solutions before, then you can easily answer these kinds of questions. But let’s keep in mind, the guy who invented dynamic programming got an ACM Lifetime Achievement Award for his solution, which I think he published sometime in the 50s. So here’s a problem that if you haven’t seen it before, this is something that someone won a industry wide award for coming up with a solution. So it is not a reasonable question to ask someone if they’ve never seen it.
To me, the most important factor is that the question should be somewhat quirky, somewhat different from the standard questions that you see on any kind of interview question list. I think it’s especially useful if there’s a little bit of a system design element to it. So you want to talk about the actual problem and then some performance implications, scaling, various things like that. It’s an added plus of the question has a little bit of a product element to it. It requires some understanding of the real world, how users would use the feature. And that also affects how you would design this system.
So one example, I’m not gonna talk about these questions in detail for the same reason I mentioned before. I don’t want them to get super publicized. But as an example, I asked one of the questions that I like to ask to a music major who had been doing some coding. There’s a little bit of front end Javascript. She was able to solve the problem just like that. She immediately saw all the implications, went into it, described it, you know, basically got the concept of it, optimized, it was able to deal with performance and all these other issues. And she never thought of herself as a super hardcore computer science type of person, but she could handle very difficult programming problems.
Another example is I was interviewing a young woman who had graduated from university of Pennsylvania with a degree in psychology, but she was coding. She’d only been coding for a year. It was just a job she picked up. You know, she had never really intended to become a programmer, but she solved the problem right away. And but she didn’t know all very much about like how you would implement in detail. So she was talking about how there must be a way in SQL to do XYZ. And she was right. Of course, there is such a feature that she was looking for. And I said, you’re absolutely right. That’s correct. And then she continued to solve the problem. That is a 10X engineer. I mean, she was incredible. I gave her an offer. Unfortunately, she took a different offer. But later I kept checking in with her to see how she was doing in her career. And she just kept advancing and she became like a senior engineer and she was doing fabulously at all these tech companies. It’s exactly the thing that I would have predicted for her.
Now, the reason why these questions don’t have to be super difficult is that it is difficult to find people who can solve novel problems that they haven’t seen before, even if they’re not in my mind, super difficult. And that is a bar that I think should be the minimum standard for someone that you’re going to hire. In my experience, the majority of people, even with long resumes, cannot do this very well. Testing knowledge and memory to me is less important.
Now, of course, if you are going to be hiring for a position that where especially front end engineering, it really helps to know the framework cuz there’s a lot of little details that are helpful to learn. And experience matters when you’re trying to hire someone who’s very senior or managerial level or like a principal level type of engineer because the experience gives you a lot of material to draw upon for practices that are more effective or less effective, that are not really about raw problem solving. But I would much rather hire someone with almost no experience or straight out of college with just some internships who is 10 x at problem solving than someone with 10 years of experience who can’t problem solve new things very easily. I can teach someone who is fresh out of college and a very good problem solver. And it is very difficult to guide a senior person who has a lot of experience but is not very good at problem solving because they cannot understand and or grass nude concepts quite often or they they don’t they make overly complex solutions or it takes them a long time to solve things. So that is my particular bias when it comes to hiring.
Again, for things like Devops, for things like front end engineering, I think it matters more to have experience because they need to understand all the pitfalls or all the systems. But for something like backend engineering in particular, I think knowing how to pro solve problems is the most important thing. And if you have even some familiarity with the general style of the framework you’re using, you don’t, they don’t have to necessarily have experience in the exact framework that you happen to be using. I have many times brought people in or myself started working on a new framework that I’ve never used before, they had never used before. And they ramp up on it very quickly if they can solve problems well.