What Are Tech Hiring Managers Looking For?

  |  Compiler Team  
Sviluppo professionale

Compiler • • What Are Tech Hiring Managers Looking For? | Compiler

What Are Tech Hiring Managers Looking For? | Compiler

About the episode

Interviewing for a job is often a stressful process. Most people don’t enjoy the inherent judgment involved. Being prepared helps—but what exactly are you preparing for? There isn’t a single interview process that covers the whole tech industry, not even for technical positions alone. But they do have elements in common.

Whiteboard exercises and verbal pseudocode help reveal basic coding ability. But that’s not the only point of those interviews. In this episode of Compiler, we learn about the hiring process from the perspective of applicants and the hiring managers who evaluate them—and the qualities beyond technical knowledge they take into consideration.

Compiler team Red Hat original show

Iscriviti

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Trascrizione

All right, Johan. What do you have for us today? Well, I've been hearing about this one topic from a lot of people I know in the tech industry—the hiring process. Well, it is really, really tricky and it can be super frustrating. And I know, I've been through it a few times and it has never been fun. Oh yeah. I mean, you've had a number of positions in tech over the years. What has been your overall experience with the hiring process? Overall? It's always been stressful. They're literally looking at your resume and judging you and hearing what comes out of your mouth and judging you. Just the thought of it is bringing me stress right now. I can't even. I mean, I wonder if part of that is not knowing what hiring managers are looking for in you. That's exactly what I wanted to talk about today. This is Compiler. An original podcast from Red Hat. We are your hosts. I'm Brent Simoneaux. I'm Angela Andrews. We are here to break down questions from the tech industry. Big, small, and sometimes strange. Each episode, we go out in search of answers from Red Hatters and people they're connected to. Today's question: What are tech hiring managers looking for? Producer Johan Philippine is here to help us out. So the idea for this episode started a few years ago when I was having a conversation with a coworker of mine. So, my name is Eric Chiang. Eric was working on something called Kubernetes, and it was a very much in-demand skill set to have. And he was telling me how he was looking for a new job. Now, I expected him to be looking for something in the same field, where he had built up these skills. But what he told me he was looking for seemed really completely different. He was looking to get a job in security. I guess it was when I decided to start looking for new jobs and was talking to some people. They were obviously like, "Oh, you're going to come work on our Kubernetes team." Eventually I just sort of decided, "You know what? I don't want to do that." So kind of put my finger in the air. I was like, "I'm going to go do security" because I know a little bit about that. I've been doing that kind of ad hoc in open source. What do you think was going on there? It sounded like he had a lot going for him in Kubernetes. What was going on in his head at this time? I think to put it simply, he was feeling burnt out. He's been doing it for a few years. So he told me he wanted to do something a little bit less stressful than Kubernetes, which was apparently working in security. Really? People came back to me with, "Oh, you'd be really interested in this job." I said, "No, I'm just going to do security. That sounds a little bit less stressful than what I've been doing. And continuing to sort of do this one job forever." So I was, I was pretty surprised. I mean, would it mean kind of starting all over again? Would that kind of change affect his hiring prospects? I remember saying to one person, "Oh yeah. I want to work in security," and them saying, "We have a thousand person security or you probably want to be a little bit more specific than ‘I just want to work in security.’" What did he ended up doing? Well, he's at Google now and he is working in security. So he managed to pull it off. What was the hiring process for him like at Google? Well, at first he was going through the software engineering role hiring process: The whiteboard interview. We'll get to that pretty soon. He told me he didn't feel like he was doing great at that, but about halfway through that hiring process, another former coworker of ours, who was at Google already kind of pulled him aside to say, "Hey, actually, if you want to work on security, you should come work for our team." Now what that meant was starting the interview process over again. Was that another whiteboard interview? It wasn't actually, it was more of a conversation. Ultimately my interviewers did a good job of looking at my resume and saying, "Okay, these are questions you might be able to answer." So I had a little bit of help there. I do remember though, the night before one of my interviews, watching YouTube videos about network security because I had no idea what anything of that meant and definitely just regurgitated some of those lecture answers to my interviewers. But I mean, he was able to get hired at Google, doing security, doing something he didn't have a lot of background in, or at least not as much as I would have expected to be hired for that kind of role. So it really got me thinking: What are hiring managers looking for? Yeah. How do they really know someone will be able to do the job? Exactly. All right. Johan, who did you talk to next? So I spoke to my friend TJ. My name is TJ Lee. I'm a Senior Software Engineer at Google. He wrote a Quara post a few years ago about the interview process a lot of tech companies use: The dreaded whiteboard interview. A whiteboard interview is where the candidate is asked to code up a solution to a programming question on the whiteboard in front of the interviewer. So how the format of an individual whiteboard interview goes is the candidate comes in, they greet each other, and the interviewer poses the coding problem to the candidates. So the candidate verbally out loud thinks and talks over the various aspects of the problem: what kind of approaches he or she can use to solve the problem, the space and runtime complexity of that kind of solution, and the type of test cases that they had to run through to make sure that their solution actually works. At some point the candidate will have thought it through enough that the interviewer feels convinced that the candidate is able to code up the working solution and ask the candidate to code it up on the whiteboard. Then they're run through a few test cases and discovers bugs and make sure that it actually works and meets the complexity requirements. And how you do on these white boarding coding questions IN interviews determines the vast majority. Let's say 90 plus percent of whether or not you actually get the job. Angela, is this something that you've ever done? Have you done a whiteboard interview? Yes, actually when I was in coding bootcamp, they would teach us how to perform these white boarding interviews. They would go over different algorithms like FizzBuzz and a couple of others. We had to know how to work our way through them, just in case they came up in an interview. Is this something you do in your job now? Emphatically, no. That's actually a pretty big controversy for the whole process. TJ explained that the primary criticism that these interviews have is that it's largely unrelated to what most software engineers do on a daily basis. He said that if you're a good software engineer, it doesn't necessarily mean you're going to be a good whiteboard coder. He himself, he said that if he had to re-interview for his job again without preparing, he probably wouldn't do very well. People who do well are always the ones who practiced and prepared specifically for these interviews. So in other words, those who grind the LeetCode and HackerRank questions. So it definitely helps to have done some background and data structures and algorithms with a computer science degree. But if I'm being completely honest, the relevant parts of a four-year computer science degree, they'll help you with these coding reviews. But you could obtain that at home alone in a few months for free with just an internet connection. There's a lot of free resources on these kinds of things on YouTube and Wikipedia. If you wanted, you could spend a little bit of money on an online course for intro to data structures and algorithms. But in terms of the relevant knowledge of passing these whiteboard interviews, you'd be on par with the MIT, Berkeley, or Stanford undergrad if you spent just a few months learning some very specific parts of coding. Is this, it seems really artificial, right? In a lot of ways, it sounds really artificial to me. In the defense of white boarding interviews, they do suss out a little bit of at least the basics of being able to understand a problem and write a solution with code, right? Even though it's on a whiteboard and you're not actually able to run it, the interviewers and the candidate are able to kind of have this back and forth about how to build a solution, right? But the secondary thing that they're testing is not necessarily just the knowledge of the technology, but the interaction that the candidate is having with the interviewers, right? Because all throughout the interview, they're asking questions about the solution, right? They're asking how it's going to perform, why the candidate made certain choices, right? Perhaps it doesn't seem like it'd be the most efficient way. Those are all kind of reflections of real life interactions that the candidate and the interviewers are going to have because in order to work as a team, they're going to need to have those communications. They want to make sure that they're going to be able to solve these problems together without butting heads or having any ego problems. So this is one way of interviewing for tech jobs. I'm wondering, is this the only way? Well, that's a really good question. To find out the answer, I wanted to ask a hiring manager directly. So I spoke to Alexis Solanas. Hi, my name is Alexis Solanas. I am a Senior Software Maintenance Engineer in the OpenShift team. What I do in my day-to-day duties is just helping customers to solve the issues they may come with when using OpenShift. So I wanted to know if everyone uses these white boarding interview. It seems like this really grueling kind of process, right? Alexis told me a bit about how he prefers to conduct interviews. I'm interested in seeing how a candidate can think, how they can connect things that have not necessarily connected between themselves to reach a solution or at least to find a work around for a particular problem. They'll talk through how to solve it or how they might address that problem. But there's no whiteboard involved at all. That sounds like my last interview. Oh, say more. What was your interview like Angela? It was very conversational. It was two parts. So part of it was a little technical, but the other part of it was really just talking about the products and understanding what the Red Hat portfolio has to offer. So I think being able to talk about the portfolio and express myself, I think that was probably the deciding factor. It was a really big part of the interview. Just holding conversations with folks, no white boarding involved. So why do you think Alexis does it this way? Why this and not a whiteboard? What is he able to discover using this method instead? The way he explained it to us is that while the technical knowledge is good and he wants to make sure that the candidate has at least some baseline knowledge of the technology there'll be working with. It's not the only point of the interview. The role that I am at the moment is not only having technical knowledge of the product that you're working with, but also you need to know how to handle the customer. So sometimes the customers create a case for a variety of reaons that you don't know and knowing how to handle the customer, how to letting them know that they're in good hands, and at the same time helping them. I think that's the mark of talent for this position. So what Alexis is looking for is the thinking process, right? What he doesn't want to hear is kind of a rote, prepared answer. He wants to really push the candidate to think through a problem because the problems that come up, they're not necessarily going to be the textbook ones, right? Each customer is going to be different and he wants to make sure that the candidate is going to be able to adapt and learn how to adapt to these different situations. This sounds like verbal, pseudo coding. Okay. I don't know what that is. What is that? Well, it's just that. It's just walking through a problem. You're using regular speech. No technicallese you're just literally walking through a problem in how you'd solve it, step-by-step. Oh, that's really interesting. I've actually, I've got one more thing Alexis wanted to mention and that's... I wouldn't like to hire someone who is going to stay forever and ever in the same position, unless that candidate really likes that position and that's the only thing they want to do. He's looking for people who are going to not just learn the tools that they're going to be using, but who are going to learn and grow and grow out of the positions that he's hiring for. Maybe because of my own experience, when I entered Red Hat support, I was first just working with the base OS. That’s what we call the services and just the little things. Then I moved to the kernel team. From there, I moved to the container team. From there, I moved to the OpenShift team. So I think as the more you see, the more you enjoy your job, having all these opportunities, it makes it even better. Ah, the ability to learn and stay curious. On that note, I have one more person to introduce. She's kind of the perfect example of what Alexis was talking about, growing beyond the role she was initially hired for. My name is Ksenija Pelc and I'm Associate Manager for OpenShift technical support in EMEA. What role was Ksenija hired for when she started at Red Hat? Well, initially she was working on the Linux team. Yeah. Well, when I joined, I was first, I was team leader for REL technical support. So I kind of dipped my toes into technology. I know what products we're offering and so on. But about a year and a half after joining Red Hat, she was given the opportunity to become an associate manager for OpenShift. So I was well extremely interested in trying a new technology, learning something else. Yeah, that's, that's how I got there. Now there's some overlap and the Linux team and the OpenShift team, they're based a lot on the same technology, but it's still shifting roles. It needs a lot of education in order to do that kind of shift. And while growth in your career is expected, it's not easy to shift roles. This field requires constant education and learning, regardless of whether you're shifting roles. So to go from one role to another like that requires even more learning. Yeah. So I think I understand what you're getting at here, Johan. So we've been talking about interviewing and preparing for those interviews and studying, but that doesn't stop with the interview. Once you've gotten the job, you still have to keep studying, right? You still have to keep learning and preparing even after you get the job. The way that she and her team do this, to keep learning, is that they actually set some time aside for themselves to study. In our team we have, for instance, two dedicated days just for self study. What's that, 10% of your time during the month where you can fully focus on that also during your working hours. That seems really difficult to do though. Because I don't know about anyone else, but I'm sure everyone's is actually like this, but my calendar gets really full and it's really easy to get kind of bogged down in the work. How do you actually set aside that time and actually do the studying? Well, you actually set the time aside, you put it on your calendar, just like you put anything else on your calendar that's important to you. You'll make that time. So it's really important that you carve it out. Now how important is it to keep learning like that? I mean, I know tech moves fast in the abstract, but how often do you need to be learning new skills? Angela, help me out a little bit here. Is it really constant new things you'll be using all the time or? It is literally all the time. You cannot work in this field, in any branch of this field, without always learning something new, the newest framework, the newest releases, the newest product updates, the newest this, the newest that. You cannot be successful in tech if you're not constantly learning. Always be learning. That's literally should be the motto of tech. If you want to get into it, you can't stay stagnant. You always have to stay learning. I think what I'm hearing from both of you is that a lot of people will put a lot of time into studying and getting ready for an interview. But it's not like once you get the job, you can just kick your feet up. You're like, "Well, I got the job. I'm just going to go about my day and do my thing." That same kind of preparation and that same kind of studying and that same kind of drive, you've got to keep it going. Yeah, you do. You can't take your foot off the gas. Not one bit. If after you get the job, even more so, because now that you have it, now you have to do the work. You have to stay ahead of the curve. So, that was just that small little thing. "Yeah. I got the interview. Yeah, I did great." Now you have the real job and you really do have to stay engaged and passionate about what you're doing. It's like getting the job offer and starting the job is actually the beginning. That is the beginning. Yes. Yeah. That brings us back to our question, right? What are tech hiring managers looking for? Yeah, we've talked about, I mean, basically two popular interviewing techniques. But I'm sure there are many others out there, right? Yes. I have had some really interesting interview techniques thrown my way. So Johan, you talked to a lot of people for this episode, and I'm curious, what, from your perspective, are hiring managers looking for? Well, there's a couple of things, most of these have in common, right? The first one is probably the most obvious. The candidate has to have at least the basic amount of technical ability to do the job. Have to have the skills. Have to have the skills. Second of all, and perhaps more importantly, they're looking for candidates who show their thirst for knowledge, right? Who want to learn and grow in their position. So that means that nailing the interview means showing that you're curious and motivated to learn. That does it for this episode of Compiler. Today's episode was produced by Johan Philippine. Victoria Lawton keeps us curious and striving to learn more. Our audio engineer is Kristi Chan. Special thanks to Shawn Cole. Our theme song was produced by Mary Ancheta. Big, big, thanks to our guests. Eric Chiang, TJ Lee, Alexis Solanas, and Ksenija Pelc. Our audio team includes Leigh Day, Laura Barnes, Claire Allison, Nick Burns, Aaron Williamson, Karen King, Boo Boo Howse, Rachel Ertel, Mike Compton, Ocean Matthews, and Laura Walters. If you like what you heard today, please follow us for future episodes. We would love for you to be here next time. Thanks so much everybody. See you next time.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Articolo del blog

Friday Five — August 15, 2025 | Red Hat

15 agosto 2025  |  Red Hat Corporate Communications

...

Articolo del blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 agosto 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.