July 18, 2022

Are Coding Interviews ACTUALLY Broken?


People are FRUSTRATED with the current state of coding interviews. Down with data structures and algorithm interviews! Why am I being tested ON THE SPOT in the interview, only to have my anxiety spike? Do hiring managers even know what the hell they’re doing!?

We’ve landed on a controversial topic for sure in this video! I brought on 2 hiring managers and put them on the spot with many of the common concerns I’ve heard about the interview process. One has extensive experience training and hiring in the startup world. One has a tremendous amount of experience doing the same at FAANG companies.

I think these 2 were the perfect people to bring on for this. I challenge them with many of these frustrations developers have. Both are VERY honest, so I hope you’re ready. They may challenge a couple of your assumptions about the hiring process. Try to keep an open mind during this episode. Enjoy!

Scott Ferguson (guest):
Linkedin - https://www.linkedin.com/in/scottferg

Daniel Tomko (guest):
Linkedin - https://www.linkedin.com/in/danieltomko

---------------------------------------------------

🤝  Join our junior friendly developer community:
https://discord.gg/H69QqZ8MVJ

🔥  Want more personalized help from me? Here are the paid mentorship and review services I offer:
https://calendly.com/donthedeveloper

❤️  If you find my content helpful, please consider supporting me by becoming a channel member and get access to additional perks. Every little contribution helps and is actually used to pay my bills.
https://www.patreon.com/donthedeveloper

---------------------------------------------------

Disclosure: Some of the links below are affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.

📚  Web development books and other products I recommend:
https://www.amazon.com/shop/donthedeveloper

Dev Interrupted
Behind every successful tech company is an engineering org. We tell their story.

Listen on: Apple Podcasts   Spotify

The Asset Hero Property Management Podcast
Your one stop shop for property investment strategy and management.

Listen on: Apple Podcasts   Spotify

Three Thirty3
Hosting entrepreneurs from the web3 and NFT space to share industry insight and trends.

Listen on: Apple Podcasts   Spotify

End Hype with Callye Keen
Callye shares 15 years experience launching products and growing businesses.

Listen on: Apple Podcasts   Spotify

Transcript
Don Hansen:

Welcome back to our web development podcast, where we help aspiring developers get jobs and junior developers grow in this one. We're gonna be focused on answering the question. Our coding interviews actually broken. See a lot of LinkedIn posts, a lot of Reddit posts. I see it everywhere. Um, everyone thinks that coding interviews are broken. Some people even think hiring managers, um, have no idea what they're doing with hiring, right? So we're gonna dive into that. I invited on essentially two, uh, two people that have hired countless number of software engineers have, you know, trained and helped people through the software engineering interview process. Uh, quite a bit extensive knowledge. Uh, Scott is a little bit more, his experience is really based in a lot of experience with startups while Daniel is more focused on Fang level companies. So we have two different perspectives from two sides of software engineering. And we're gonna get a feel for what they think about it, but let's go ahead and start with our intros. Uh, Scott, would you like to introduce yourself?

Daniel Tomko:

Yeah. Scott

Scott Ferguson:

Ferguson. Um, as you said, I spent about the first 10 years of my career going through various startups, smaller companies. Um, about four years ago, transitioned to enumerator, which is private equity and a little bit of a different, uh, environment, but a lot of hiring over the years, um, worked with a lot of engineers, um, been through a few interviews.

Don Hansen:

sounds good. How about you, Daniel?

Daniel Tomko:

Yeah. Uh, so I've been an engineer and engineering manager at, uh, I was at Microsoft for about 11 years and then Facebook for almost nine. Uh, now I work at a small company called formation where I actually focus on teaching software engineers and aspiring software engineer. Uh, both helping them prepare for interviews, but also setting them up for success once they're on the job. Um, while I was at, uh, both Microsoft and Facebook, I did thousands of interviews. Uh, I spent a lot of time at Facebook actually helping refine their software engineering interview process. So I've thought about interviewing a lot

Don Hansen:

and I know you have opinions, so looking forward to it. So I wanna start out with this, right? I'm gonna start out. Um, I have certain opinions and I wanna hold those opinions. I wanna hear what you guys have to say, but I wanna start out with kind of just some very common opinions around the coding process and, you know, feel free if either of you have a question, you wanna ask each other questions. That's fine. We can dive into it a little bit, but let's start with. Let's start with this data structures and algorithm, coding challenges, don't relate to the job. There's no reason to have them in the interviews. They don't give the hiring manager much information to go off of a lot of people. And I think it really is based around the interviews and the challenges aren't going to relate to the challenges that you're gonna face on the job. So why in the world would hiring managers ever give those types of interviews?

Scott Ferguson:

Kinda want Dana to go

Daniel Tomko:

first. Okay. That's fine. I'll go first. Um, in my mind, it all depends on how you use that question and what your rubric is for how you are evaluating the answer. So it's, if your rubric is, uh, can they get this difficult? You know, tree manipulation question. Well, that's a really bad rubric, but if your rubric is much more detailed and focused around somebody's ability to approach a problem and the way they, uh, break it down the way they understand it, the way they then start to like break it down and, and write different pieces of code. If your rubric is involving, um, their ability to stay organized while they work on a problem, if it's involving their coding, fluency that they demonstrate, then you can actually learn a lot that does directly apply to the job. Even if the question is not something you would code on the job. So if the rubric is just, do they get the question, right? You're not actually learning that much because they may have memorized that question. They may have seen it before they. And, and it doesn't apply to the job, but if you, if you were really looking carefully at the individual skills involved in answering these questions, they can actually be very, very useful, but that takes a lot of effort on the part of both the company to design the rubric and the interviewer themselves to evaluate the rubric. Does that make sense? Yeah, it does. I,

Scott Ferguson:

I agree with that wholeheartedly. Um, it's you can almost, um, make the same claim about any coding challenge, right? When, uh, Don you and I did that, that episode a while ago, and I did my secret Santa. Nobody's gonna come to numerator and program secret. Santa doesn't make any sense. Um, I I've always, I've always liked the, the data structures questions on the lighter side. I've never asked if I do, you know, build trees or anything that, that advance you stick with some of the basics. And actually they do apply to the job. Right? How often in, in normal software development, do you use a queue? Um, it's kind of a common one. it came a couple times in my day to day. Um, and so incorporating that in a way where I like the questions where to your point Daniel, like it, it, it gives me insight into how you're thinking through things. And so questions that I've used over the years, always, almost always have one hook in it where I know it's gonna be a little bit harder. I know that there's gonna be a little bit more of a struggle where I know that there's gonna be this bug, that crops up, cuz it's really easy to, to gloss over, but. How do you think through that? Like what is your method to debugging? Yeah. It's giving us more context, more information about just how you work and that's really

Daniel Tomko:

what we're after. Yeah, that's right. I would add one thing that I agree with with all of that, Scott, is that I tend to ask questions that are not super hard to solve, like to understand conceptually. Yeah. Right. Because I don't want, like, if that's the hardest part of the question, then it really is more of a puzzle than an engineering challenge. I really like what Scott just said about, uh, there being some trick or common pitfall, common bug that comes up. Because, you know, seeing them work through that, that's the kind of thing we do every day on the job as an engineer, but that needs to be somewhere later on in the problem. Right. I wanna see them get there. I wanna see all the steps that have led up to that. And then do they fall into the pitfall if they do, how do they work through it? How do they identify the issue? How do they get out of it? This is all really, really useful information. That's directly applied to the job.

Don Hansen:

I like that. So the focus should be more on discovering the process of that individual actually solving the problem and, you know, Daniel and other episodes you've even talked about like communication with the interviewer, how much time do they invest in actually understanding the problem initially? Or do they just dive into it? Right. Um, so it's fo focused on the process. So there are companies that are like, you don't pass this challenge. You don't, we're not gonna talk to you. Right. And maybe. Maybe we should challenge those kind of interview processes and the rubric is what you said. Maybe those are the types of things where a lot of this frustration really is warranted. Um, I love the idea of really focusing on the person's process, um, and going through the entire thing, you can learn a lot more than them just solving the problem, but

Daniel Tomko:

yeah, whether did they solve the problem or not like exactly

Don Hansen:

whether they did or not. Yeah. Um, but the argument that's gonna be made for that is, well, I do have a process and I do think I probably critically think about things enough and like even start off trying to understand the problem enough, but that all goes away when I'm on the spot, I'm nervous. Everyone else is nervous. And like, I, and I'm actually gonna share my story. When I interviewed at Twitch, it was my dream company wanted to work there. I was using react for a while. I knew nothing about react in that interview. Everything went blank, right? I was just nervous and that is my fault. A hundred percent. That's what I truly believe. And I, that's a confidence issue I had to continue to work on, but this is a very common problem. You guys have probably seen this in your interviewers or interviews. So when you do these coding type challenges, they seem to bring on more anxiety and more blockers, mental blockers. So are these coding challenges actually exposing that process and showing you how people are tackling that

Daniel Tomko:

problem?

Scott Ferguson:

I think I mentioned it too before. Um, there is a certain acceptable loss when you of no interview process is perfect. Some people are going to get nervous and feel under pressure. And for us as the interviewers. We are using a lot of our time to try and, you know, close these roles that we have open because there's things that we're trying to get done. And so, you know, candidate experience is one of the highest priority things in my mind, always, uh, when going through the Berg process and you try to make it as, you know, friendly as inviting to them as possible. And sometimes it works and sometimes it doesn't. Right. And, and, um, you'll try to coach the person through the problem or, um, you know, you'll just strike up a conversation with them or whatever it might be icebreakers.

Daniel Tomko:

Yeah,

Scott Ferguson:

yeah. Really important. Sometimes at the end of the day, People are gonna slip through the cracks though. And it's just it's it never is perfect, but what we are trying to do and what we are tasked with is in a finite amount of time. Um, and depending on the company that you're interviewing with that, that amount of time is gonna obviously grow or shrink, but in that finite amount of time, we need to understand as much as possible about your capabilities as an engineer. Yeah. Um, and so that kind of, that, that constrains our ability to, um, give you another interview, for example, right. And see, give you another chance or, or extend the amount of time, um, that, that we're doing that interview.

Daniel Tomko:

Um, a couple things I would add to that, I is that. Number one, that pressure actually is realistic. And seeing somebody perform under some amount of pressure is important. Like how many times in my career has some important bug or customer issue come up where there was a real deadline or real like harm being done in some way. And we had to work through it productively and quickly, you know, there's real pressure. One of the things I've seen countless times and interviews when things kind of go south is that when pressure is applied, you know, there's a time limit. And, you know, just like Scott said, candidate experience is like, well, that's a whole other topic we could talk about, but I'm also super, super passionate about that. Um, I want it to be an inviting environment, but there is that time limit and the candidate wants the job, right? So there is this natural pressure that I see people time and time again, let their process break down in the face of that pressure. They, one of the biggest mistakes I see is people rush to writing code before they thoroughly understand the problem or thoroughly understand the idea of the algorithm before they start to write code. If you don't understand the algorithm before you write code, you are vastly more likely to write code that's wrong. And I'm not even gonna say a bug at this point, cuz like a bug is sort of implies that it's a little bit accidental, but this isn't an accident anymore because you didn't have an idea going in. Right. Because you didn't take the time to crystallize the idea in your mind in order to then think about the next step of how do you translate that idea into code. So like the big, one of the biggest pieces of advice I give people is to not lose sight of your process in the face of, of a, of a deadline or, or some pressure that's you know that yeah. it's probably the number one mistake I see in interviews or the source of number one source of mistakes

Scott Ferguson:

in interviews. There's a, um, Extended portion of, of our interview process, where a candidate has, um, several hours to work on something mm-hmm . And one of the things that I always do because I've seen candidates and this wasn't their fault, they didn't have the right guardrails going in, but they, they spent a lot of time working on parts of it that just weren't valuable. Wasn't getting really to what we were after. And so, um, I have like three or four bullets that when I go and introduce 'em to 'em like, here's what we're looking for. We wanna talk about this. This is the important thing. Do not focus on this. Like this is it as much as you need to do, because if that's the way that, you know, you're gonna feel comfortable with your debugging and then, and you're writing, cool does not need to be perfect. Don't focus on that. Gotta harp on those points. And it's one more of, of, of going back to that rubric. It's one more metric there of. okay. Coming back, like we had that conversation and usually you check in with the person, you know, midway through this whole process and see how they're doing. And if you got to reinforce those points, don't, don't focus on this, don't do this. Um, there's a non-real amount of candidates who still get to the end of that. And they did exactly what I asked them not to do. Um, and it's, that's just one more thing of just understanding, you know, if, what are you gonna be like to work with? Um, you know, is it gonna require a lot of handholding? Like, are you able to take a set of requirements and work against those while in this case, you know, not, um, and I am positive that a lot of those cases where we see this happen, it is candidates that just are nervous. They're feeling the pressure. They're not thinking clean clearly. Uh, they may not have even heard what I said. Um, but yeah,

Daniel Tomko:

but that, but that happens on the job. So I think that's valid signal that we're getting as the, you know, the evaluators. Um, you know, the other thing that I, I re remind people of all the time is that, you know, when you're on, when you're on the job and we're colleagues, like you're at the desk next to mine. Right. Um, we ask each other questions all the time. Right. And I try really hard to treat interviews the same, the same way. Right? Like I'm part of the, of me as the interviewer, sort of putting myself in this mindset of like, what if you were at the desk next to me? What's it gonna be like to work with you? Right. Do you ask good questions? Do you raise your hand when you're stuck? Cause we all get stuck. I still get stuck. I mean, I don't know everything. Um, and when that happens, what do you do? Like that's one of the most important parts of the interview. It's not even just like, can you fluently write code, but what do you do when you get stuck? Um, you know, at the end of the day engineering, we're, we're out engineers because we're building things that are new, so we don't have all the answers going in. So what do you do when you don't know the answer up front? Um, that's actually a critical part of the interview. You know, you're not expected to know the answers. You're expected to have a process that's successful in finding answers and producing answers and you know, not knowing everything up front is okay. Um, calling out what you don't know is great, right? Because that's now something on, like, if it was on the job, that's now something on the checklist to find out. If it's something that's critical to solving the problem. Right. That gives me confidence in your engineering process, you know, every now and again, it's something like, yeah. It's why do they not know about hash tables? That's a little bit weird, you know, if that's the thing that's now on the list of like, I think I need to learn about this thing. Right. But at least they called it out. Right? Like that's. Positive signal and a little bit of a question. Why have they never used a hash table before? Um, there might be some, there might be some answer. Right. But I'm learning things through the, through this process. Right. Um, and yeah. Oh man. I love seeing people get stuck in interviews. Not because I'm a jerk because seeing them work through it and actually like talking through it together collaboratively, like that's a realistic simulation of how the job works. I about

Scott Ferguson:

to say it gives you something to talk about. yeah, yeah. What best, what

Daniel Tomko:

good for that. Yeah, yeah, yeah, exactly. You know, and that's, that's all like getting stuck isn't, um, deal breaker, getting stuck and being absolutely paralyzed as deal breaker, but getting stuck actually is a great opportunity for me as the interviewer to learn something about you. That's quite frankly gonna make the difference on the positive side. If it, if it goes well. Okay.

Don Hansen:

I like that. So when I have this conversation with aspiring developers, a lot of the focus is on being able to, um, essentially live a balanced life to ground yourself in anxious situations and deal with anxiety better. I think really focusing on having a balanced life can help and apply towards going into the interview where like, if I go into an interview now, um, if I don't know something, if I get stumped, I don't have this huge amount of anxiety that just blocks my thought process. Um, sometimes I'll kind of make fun of myself or I'll do something and be like, I use this every day, but I have no idea. I actually did that in the Twitch interview. Um, it, it helped a little bit, but that, that was a long time ago, but I feel like, kind of just reminding myself that, like you said, um, Daniel even just. Admitting when you don't know something, it might bring up another question, but that is a, that's a good start to the process of yeah. Recognizing something that you need to learn more about. Right. Um, mm-hmm, , I, I wish I wish people could see that process as more of a positive, collaborative, fun experience that they can actually learn from. And I think way too many people, like, I think you should respect the interviewer, but I think way too many people put you too on a pedestal, like you're this amazing, super intelligent human being, whereas like, you know, more than they do. Right. But you can go into that interview with this mindset of. W, you know, you can learn something with you and also collaborate with you. Like you're, you're another developer on the team to finally get to that resolution, which is, that's a realistic scenario that's gonna happen on the team. Right. Um, I think part of the problem is putting you guys on pedestals too much. Um, and that people just get super anxious and nervous when you were at that spot some time

Daniel Tomko:

ago. I mean, how long ago? Not even that. Yeah. Right. exactly.

Don Hansen:

I think it's fun. I think it can be fun. Yeah.

Daniel Tomko:

Yeah. I mean, I, I sort of hope it is. Well, not sort of, I hope it's fun. I'll just put that stake in the ground. I hope it's fun. Right? Uh, we do this, I hope all of us got into this because we enjoy building things and we enjoy writing code. So, you know, what you're gonna do in one of these interviews is you're gonna like solve a problem and write some code. And I do that cuz it's fun. And if you don't do that, cuz it's fun then maybe you should think about a different career. Um, you know, even when I get stuck on something I'm fascinated by that process, why did I get stuck? Why did I make that mistake? If I think carefully about, you know, where I got stuck and where, or where I made a mistake, I'm giving myself an opportunity to learn about how I might not make that mistake or get stuck in that way next time. Um, so whether that, whether I get stuck in an interview or it's like working on something on the job, um, I treat that as an opportunity and not as a, as a failure, you know, I, I hypothesis here is, is that I have a lot of issues. We had to do a whole other podcast about this, but it's way off topic, but I really don't like how math education is done in, in this country in particular. Right. There's. And I think that sets people up in a bad way for these coding interviews, even from a mental standpoint, there's so much emphasis on knowing answers, but that's actually not what the goal is. The goal is, I think I said this before is like knowing how to find answers right. And knowing that process to, to find them. And, and I, my hypothesis, anyways, it just sort of goes back to this, you know, too many people are learning too many things by rote and know, focusing on knowing answers rather than knowing how

Scott Ferguson:

a, a friend of mine went through. Um, Uh, a bootcamp up here, Don, you got a lot of bootcamp. So I won't name which one , I don't know much traffic you get, uh, that would, that would care. But, um, he was not an engineer by trade. Um, and, and to his credit, he's, he's done a phenomenal job of sort of leveraging that bootcamp experience and two, um, more project management and is able to speak to engineers and, and has done incredibly well. But as an engineer and as I was coaching him through his interview processes, he was doing exactly what you're talking about, Daniel. It was like, I, I kind of talking through a prospective problem at him and he's thinking like, well, I'll need to use a loop and I'll need to use this variable and I'll need to use that for, but he's, he's pulling the tools out the toolbox, but he's not really thinking through like how to actually get from a to Z. Um, and it was, it was a very clear disconnect from what the, the job actually is, which is being able to think through the problem and solve it. Yeah. Yeah. As opposed to just trying to copy things that, you know, he was, he was shown in, uh, in, in his course.

Daniel Tomko:

Right. Yeah. I had a friend recently that went through through a bootcamp and I don't even remember which one, so I can't mention it. Um, but he was studying for some interviews and, and he told me one day he is like, I just, I have to know all these things. And I kind of looked at this list. I'm like, actually, you kind of don't, you need to know all the tools that contribute to helping you solve those things. You know, and I, when I'm, when I'm teaching with formation, I'm I often use this analogy of a tool belt. Like I wanna make sure that, you know, the engineers coming outta the program have a well stocked tool belt, and they know when to choose each tool and they know how to apply those tools creatively. And at the end of the day, what we use on the job as software engineers, there's, I don't know, 20 main tools that we use all the time. Um, and everything else is just, you know, constructions of those tools. You know, I'm gonna nest this inside of a loop and I'm going to, you know, apply this pattern or that pattern. Um, you know, you're putting these things together in creative ways and the ability to select those tools and then adapt them. That's huge, you know, knowing how to reverse a link list. don't really care. , you know, knowing what patterns and tools might help you get there and then be able to apply that creatively. That's huge. I agree.

Don Hansen:

And yeah, even when I talk about react, I mean, even just understanding the concept that it's just a bunch of lists inside of list. Like when so many people have focused on the very specific intricacies of it and how data's passed and all the attributes like. But they don't really recognize how, what the architecture looks like and how a lot of stuff is passed out. But like, when you do hear the phrase of like, it's just list instead of list, you can visualize that a little bit more. And I think it does help people comprehend concepts like that. So I like the idea of like really just getting you're essentially saying focus on a lot of the foundations that you're learning and then those foundations will expand and become more complex to create more complex features and tech solutions. Um, Scott, you had mentioned, you had mentioned that you there's a finite amount of time and you're busy. And a lot of engineering managers are gonna focus on Essent. You're. Some people are gonna fall through the cracks focused on avoiding false positives. And I hear that a lot, avoid false positives, um, as much as possible, that means some people are gonna slip through the cracks. A lot of engineering managers seem to focus on that. Why is that?

Scott Ferguson:

By false positives. You mean we gotta filter two people out, right? Well, you're gonna filter two people out. You're gonna filter out the people that are not qualified on that small number that are, I get that right. Non-qualified and the qualified, right. There's a small number of qualified folks that won't make it through for whatever reason. Those are the false

Daniel Tomko:

positives. Yes. Thank you. It's

Scott Ferguson:

been a long week.

Daniel Tomko:

Elaborate

Scott Ferguson:

um, so, you know, focus on, can you clarify the question? Like why do we focus on which aspect

Daniel Tomko:

of that?

Don Hansen:

Yeah, so, um, a lot of times, so let me even give the argument. A lot of aspiring developers kind of feel like this is probably a different argument, but like engineering managers are, are too strict and need to give, especially more junior people, more of a chance, even if they screw up in the interview. Whereas a lot of hiring managers are so booked up with. They're okay with letting people that are qualified pass through and slipped through because, um, but yeah, that's essentially what I'm talking. I'm I think I'm tripping myself up, but does that answer a good question?

Daniel Tomko:

It is right. I,

Scott Ferguson:

I, I don't personally, I don't do that deliberately. Um, but you're talking about two very different things, right? There's junior level developers, you have to interview them differently and that. Because they're not as experienced, you have to treat them differently. You have to send 'em to a different standard. That's that's just being courteous to them. Um, and generally speaking, I always find hiring junior engineers is much harder, uh, because it is harder to focus for the voice there. Um, because there's not as much to, to work off of. Right. They just don't have the experience and that's fine. Uh,

Daniel Tomko:

but that's part of the process, you know, and you're trying to assess potential, right? Like if I'm hiring a junior developer, I want, I'm asking myself the question. Do I imagine them getting to mid-level and senior in an appropriate amount of time? Do I think this person is coachable? Do I, you know, not only do they have enough skills to be some level of productive, you know, quickly, but do I think they'll get there eventually, right. Like hiring a junior developer is, is an investment, right. I wanna believe in the person and the, and believe in the person's. Career trajectory, whereas hiring a senior person, you know, you can ask a lot of questions. You, you mean, obviously you wanna see them, your right code and, and demonstrate a lot of the same skills, but you also have a body of work that you can talk to them about and, and evaluate. And that's a lot easier than these hypothetical, like

Scott Ferguson:

looking forward. Yeah. The, the advice I always give to everybody on my teams when hiring is, and I, this is, I stole this from, I think it was like a Joel Spolsky thing from ages ago. But if it's not a yes, it's a no. So that's definitely a Joel S Spolsky thing. Yeah. You can totally spend hours arguing with yourself over, you know, the nuances and this, it always pans out. And I've always told people this, and then that one candidate comes through and they're like, this is the person, this is the right one. Right? Like, and they, they get it. Uh, the seniors are the ones when that, like, it is extremely bright lights. Like, God, this is, this is the right person. But the juniors, it is a bit dimer and it's harder to, um, to follow that, that, uh, That guide, but, um, but it, the, in terms of, you know, being okay with folks falling through the cracks, right? It, it, I think there's also a lot of Varis there and, and I'd be interested Daniel, from your perspective to come from the, the Megacorp side of things. If you are interviewing at a place that is a startup, they probably don't have a dedicated recruiter. They don't have a recruiting team. They may have a head hunting team, but the overall funnel that's coming through that top of funnel's much, much smaller than what is coming through at a larger organization at the much smaller funnel. I'm very desperate to get those engineers, those roles hired. And so I'm gonna be much more lenient in how I'm, I'm focusing on, you know, who I'm gonna hire and what the skillsets are that I'm looking for. Um, and that's just the, machine's not quite operating as well as those larger tier companies are. And I just don't have as big of a pool to pick from, but I gotta get it filled. Where I am today, private equity, world numerator. We are definitely more of the mid-size company. We have a massive funnel and it is huge. So I can only imagine what the Microsoft and the Facebook, the world are, are dealing with. You have a way higher misrate as soon as the funnel gets a lot bigger, because we do need to just get through the noise and I'm talking about thousands upon thousands, thousands of applicants, and there's the first round there that is recruiting and they're doing that. And then the next round there comes down to the engineering managers. My engineering managers have a lot of things that they need to get done. They can't be spending 100% of their time and interviewing there, spend a lot of their time doing it. And so for them too, it's getting two quick answers. Like I just gotta know, like, I wasn't so sure about this one, but no, I'm just gonna pass or,

Daniel Tomko:

and you can afford to yeah. And you can afford to do that when your funnel is really big. Yeah. Because you're, you're gonna find the, the people, you know, it's a, it's a luxury that, you know, the companies with a large funnel have to be able to, you know, optimize how they spend their time. And so they're gonna have a higher tolerance for, you know, these, um, False negatives, right? People you said no to that maybe you should have let through, you know, the opportunity cost of those false negatives is lower when your funnel is really large. Now, I don't think that's a good excuse not to have a good rubric for these interviews,

Scott Ferguson:

but it, it comes back to the, the hiring team at the end of the day, which I think is the first point that you made. Like you have, you, you are responsible as the, the hiring manager to provide the good experience, provide the correct rubric for finding the right credentials that you're looking for. You still will miss at the end of the day. And it still is not fair to that certain subset of people, but you, you optimize for it. And you try to reduce that as much as possible. And at the end of the day, you know, I have no idea how many folks fall through the cracks, uh, that I've spoken to, that you know, were more than capable. Um, but we just know that it happens. Um, and the best we can do is just try to continue to refine that process and make sure the way I, I view it is. What is the, the caliber of the team that we have that we've built. And that is sort of a good way to measure whether or not that rubric is while calibrated or, or not.

Daniel Tomko:

I like it.

Don Hansen:

Okay. Definitely. So it sounds like the size of the funnel will definitely influence that and how lenient you are to letting people fall through the cracks. That makes a lot of sense. Um, well,

Daniel Tomko:

I, so I think it, so there's false positives and there's false negatives, right? The larger your funnel, like the bigger the company, the more tolerant you can be of false negatives, the smaller , the smaller the company, the less tolerant you can really be of false positives because if you hire somebody and they're, and they're really not good, they're really not right for the team. The impact, like the negative impact, number one on the team and the lost opportunity cost of having, if you'd hired the right person is a lot bigger. So these things actually kind of go in opposite directions, like your, your tolerance to false positives versus your tolerance to false negatives as, you know, company size or size of funnel changes. That makes a

Don Hansen:

lot of sense. Thanks for clarifying. Um, what do you guys think about take home projects? What do they tell you in comparison to like the live coding challenges?

Scott Ferguson:

I, I don't like have a strong opinion. I, for me, I like our process. Like I said, we do have, have, uh, a point where we will have candidates spend some time working on something. It is take home now cuz COVID um, I. I mean, I've never seen one that was convincing enough to me that like, yeah, giving a candidate a week to work on this is, is remotely valuable. Um, I would hope that a candidate doesn't spend that much time on it. Um, that is, is a huge part of this, right. Is you're wasting their time. We're wasting your, uh, our time's getting wasted here. Um, so I, I, I have preference towards the shorter end of, of the longer projects. Um, clear, concise, get to the point, go, no go decision. Um, but candidly, I've never really weigh that very heavily. I. Could be convinced to go

Daniel Tomko:

by the way. I'm, I'm also not a fan of the take home projects. Um, there's so many ways that they can be gamed and it's hard for me to just have confidence in what's going on now. I have used them, but in a very different way than, uh, I think a lot of people use them. I think it's becoming more common to use these take-home projects as sort of an initial filter. I actually will sometimes use them at the end. And the reason for that is that let's say you've already done three, four coding interviews. Like you've done a full onsite. And there's a bunch of really good signal in there, but there's a couple of like, weird, like we're not sure maybe we didn't get the signal for whatever reason. Sometimes a take home project that's focused on filling in our knowledge, filling in the signal can actually be useful. Right. Cause, and I'm not gonna give somebody a take home project if I didn't see them write some amount of reasonable code. Right. I wanna believe when I get that take home project back that they actually did it. And if I know nothing about them, then I don't know anything about the take home project code when I get it back. But if I have some signal, I can sometimes use these things to fill in. And then kind of again, like, especially for, for a more junior candidate where it is. Harder. Um, you know, maybe I'll give them something that's a little bit stretch and I'll see like, well, can they, they'll probably need to look up some step on stack overflow for this, or they'll need to like consult some documentation about something like, Hey, build something with this API, you know, build something with my company's API, right. Read this documentation and do something that might actually add the kind of signal I need. But it's building on top of a foundation of signal that I already have of from them, not, um, like my first, like here, try this as an initial, like, you know, pass, fail, filter to get through to the rest of the interview process.

Scott Ferguson:

It's interesting. Uh, take, because we actually, we don't, we do it, um, further down the, the process you've already gone through, um, screens at this point. Uh, but I wanna think more on that. We, so what we will do is you'll have the screen. You you've spoken with a recruiter. It's more of a personal thing. You've done a technical screen with a, a, uh, engineering manager. We have this longer project where we'll go through that whole process. And, and you've now seen a lot of those signals. We then custom tailor the rest of the interview at that point, because then it's sort of like, okay, let's have some more digging conversations. What do we wanna get into? What do we wanna, well, they talk about this. They talk about, I wanna dive more into this, or when they were talking about their project, I didn't really get a good vibe on, on that. Um, and we'll dig in further, um, rather than using the, the code to actually do that. But it's kind of an interesting, uh, perspective to flip it. I

Daniel Tomko:

like that.

Don Hansen:

I've, I've never heard of that. I love the idea of using it to supplement. Cuz when you were saying you did it at the end, I. Oh, no, I can already see people getting frustrated. I've already done these coding challenges, done several interviews. And you want me to do another take home project? Do you even value my time? Like, I've seen tons of threads about this and stuff like that, but you worded it in a way where like, you're kind of like you, there's a little bit of a gap you wanna figure out. Right. And maybe it's that last gap. And so maybe you give them a specific project that's going to help assess that. That to me, that's legitimate. Right? Because you could, if you're unsure, you know, Scott, you said, if it's not a, yes, it's a no Daniel. You could take that stance and be like, you know what? No take home project. I'm unsure about you. I'm gonna move on to the next candidate. Yeah, exactly. And so you're giving that candidate a more of an opportunity and it's up to them to decide if that's worth their.

Daniel Tomko:

That's right then they can always bow out. I mean, that's something else that like more candidates need to understand is like, and this sort of comes back to the nervousness thing too. Right? There's a perception when you're interviewing that the interviewer has all the power in the room and that maybe is the case. If you're thinking only in that one narrow moment, but if you think a little bit bigger picture, the candidate actually has a ton of power in the room, because at the end of the day, they either, like, if I make an offer, they have to want to accept it right now they have all the power it's completely flipped. Right. Or they can say no, like they don't wanna continue on to whatever the next phase is. Right. So it's on, you know, us as the interviewers to make that experience really great to make. You know, to sell our teams, to sell the, to sell the companies. Um, at the end of the day, they have to wanna continue and they have to want the job and they have to feel like it's worth their time. Uh, you know, and we have to set up that, um, environment, right? We have to set up that supportive environment and, and if they don't like where things are going, they thought the question was a bad question. For whatever reason. I mean, they might not know what our rubric is. They might not actually know if it's a bad question or not, but if that's their opinion and they bow out, you know what, we, we maybe just lost somebody. Good. So, you know, they do have, they do have some power. Um, they should potentially use it more. Um, I actually coach people at formation about this all the time. Like people will come to me, like I just interviewed at this company and this happened and this happened and it was a really bad experience. What should I do? I'm like say no, Like, like, this's just real easy. Don't go there. It's a pretty clear signal right there. yeah. Like you should be interviewing as the candidate. You should be evaluating the interviewer and the company, as much as they're evaluating you really, really

Don Hansen:

important. You're a hundred percent, right. The problem I see is people do it because they're told to do it and they don't genuinely wanna know about the company or the process. And I think like it, it can take some time to instill the confidence that they should care about how they're gonna grow at that company. They should care about the team and how they're gonna be treated. Um, and even just something else that you mention. It's like, I, in my opinion, the further you get into the interviewer interview, the more power you start to have. And I, I see so many aspiring developers that are just scared to negotiate. It's first job. How D like I don't provide much value. I'm lucky you're hiring me and they will not negotiate that final. That's like, actually, that's a question for both of you. Um, how do you perceive that when someone does negotiate that final offer, that's fresh to the industry, how do you perceive that? Uh,

Scott Ferguson:

negotiation's a tricky thing. Um, some people are good at it. Some people are bad at it. Um, there's a lot of nuance there. I've had cases of that where, um, the person just priced themself, astronomically high, and it's like, you're, you're no . Yeah. And we're closing out at that point. Um, if they're smart about it and they know like where, where the right numbers are to, to be negotiating around then. I don't honestly think, I even would think twice about it, to be honest, to be completely honest. I, I'm not thinking about their years of experience at that point. It's just simply, there's a range that we have to work within. And any, any mid to large size company works this way, that there is a, a framework around compensation. It is on us to be correct about it. There's a framework around compensation. We're going, you know, staying between these lines is what we've got to work with. Um, and that's, that's what the negotiation comes down to. Uh, as long as you're doing staying here and that's the conversation we're having and you're not on Saturn, which has

Daniel Tomko:

happened. Um, yes.

Scott Ferguson:

not, not worried about a negotiation. Yeah.

Daniel Tomko:

Yeah. Like the, the, where it gets tricky is yeah. Like, like Scott was saying, if what they're asking for, like puts them in the next level band and the, and the signal we have about what they're capable of, doesn't support them being in that level band. And it's like, Nope, we're willing to make you an offer at this level. You know, we, you know, there's will room on, on compensation within that level band. But, uh, you know, by the time you get all the way through the interview to an offer, we feel like we have a pretty good, good idea of where you will fit in and be successful in terms of how this company evaluates engineers. Um, and, and we're unlikely to, to, to change to the next band at that point,

Scott Ferguson:

that works both ways. Right. I have had actually somewhat recently had a candidate come in at a much lower, um, Title, then I'm sitting in the interview. I'm just like, who is this person? like, oh my God, like, whoa, you know, the follow up, this is one of these ones when I'm sending through the interview and I'm already sending slack messages to the recruiter of get the offer letter ready. Like this is, you know, we keep this moving, but I'm also sending another note to the perspective manager of like, what do you think about this title? Like, that's gonna put 'em up into the, the higher, um, higher price point as well. Um, so it doesn't always have to work against

Daniel Tomko:

you. No, it doesn't one, one thing to, one other thing to call out there though, is if there's, if somebody's on the border between two level bands, my advice independent of cost to company, like whatever is actually to start at the lower band. Yes. Because, and this is mentally really hard for people because some people get really like tied up in these labels and levels and things, but here's, but here's what happens if you start out too high. when that first evaluation comes around, you might get hammered a little bit, right? Cuz you were sort of barely squeaking into that level. And as much as this sucks, first impressions matter, right? Your first evaluation, your first review at a company, you want that to be good? Right? That's gonna set up trajectory. That's gonna set up expectations. You change teams, your new manager is gonna look at your reviews. You're like, you really want that to be good. I've seen it work out such where people who start down a level actually make more in total comp over time because they kick ass on their first review. Right. And remember bonuses and things are based on your reviews. Right? And those bonus curves are generally not linear. They. Quadratic or potentially exponential as you like get to like these higher and higher performance levels. So starting down a level, your salary might be a little bit lower, but if you were on the border and you're sort of on the upper end of that band and you do really, really well, those first couple of reviews, well, number one, you're probably gonna get promoted. Number two, you've set up these expectations of like, Hey, this person's a rockstar. Number three. Now you're getting equity, refreshers and bonuses on the higher end of these curves. So your total comp is different. Your total comp is higher. Your career trajectory is better. And it it's just sort of like the long term. Better strategy, but you have to sort of take a step back from like, oh, I got a, you know, mid-level offer instead of a, a senior offer. Like, oh, I really wanted that senior offer. Well, you're going to a new company, no matter how good you are, you're gonna have things to learn, set yourself up for success. Give yourself some wiggle room, you know, oh, put yourself in a situation where, you know, you're gonna be able to like ramp up quickly and meet and exceed those expectations if possible. So also far

Scott Ferguson:

less red tape in a raise when I'm promoting you versus you just want more money.

Daniel Tomko:

Yes,

Scott Ferguson:

I will. I be able to give a much bigger

Daniel Tomko:

raise for promotion

Don Hansen:

so that that's definitely a thing. And the problem with startups is I think a lot of startups don't have a good system in place for promotions. And I think startups in general can take a little bit longer to develop kind of just that, that pipeline of going from junior to mid to senior and different levels within, uh, What people are finding, and I'm finding this as well with a, especially a lot of startups and mid tier companies, it's way easier to bump up my salary if I just joined a new company. So I'm gonna aim for the highest salary possible. Like Daniel, I think F level companies are probably more equipped to be able to do that. You're at numerator Scott. You're probably more equipped to be able to do that, but even think about like Aly health. Think about like the, some of the previous companies that you've worked at, like smaller startups. I'm telling you, that's not a reality at most startups. That's not what I've seen when I've talked to different hiring managers. And that's why, like so many people will just, first of all, I think they underestimate the value. They don't ask for enough initially. But secondly, like I just a, of 80, 90% of developers that I talk to that have some experience they've, um, they, they truly struggle even with promotions to get the salary bumps that they can get by joining a new company.

Daniel Tomko:

I think that's an in, so I'm just gonna assume you're right. I'm not, I don't have experience in a lot of startups, so I'm just gonna take that as as fact for now. Well, actually that's true

Don Hansen:

before you do, I wanna hear Scott's opinion on this cuz he's more in the startup world and then we can dive into that. Oh

Daniel Tomko:

sure. Well,

Scott Ferguson:

the reason I got outta the startup world is because it's high risk high reward, right? So think of the high risk areas of startups and, and you're talking about candidates that aren't doing a lot of research into the actual company. There definitely are startups up there that have a lot of potential where you can make a lot of money and you can, you can, you know, put yourself out there with that kind of an offer most are not that case. And you should not expect that they're gonna have, it's just the unfortunate reality of it. They're not gonna have great career ladders. They're not gonna have great salary structures. The salary structure is probably all over the map. If you actually gotta peek into what's going on there. Um, I don't, I wouldn't put startups on. As a, I would consider a startup as predictable in that sense. Yeah. That's fair than I would. Any other company you get to the mid-size companies, it's a lot easier to, to work within those parameters. You get to the bigger companies. It's a lot easier to work in those parameters because they have structure and they know what they're doing and they have money. unfortunately not always the case of startup.

Daniel Tomko:

Yeah. Okay. I'm glad we let, I let you go first. Cause I'll cause I can just add something simple which if it's a startup that's, even if it's small, if it's actually on a growth trajectory, it's in the management's interest to retain good employees. So if you, if you deserve a promotion or you deserve a raise, it's on it. It's good management to see that that happens. And if they're not, if a company's not doing that, they're shooting themselves in the foot and absolutely those people should go somewhere else and get that higher salary. But I'll hire that person. Yeah. Yeah. Same. Exactly. It literally be competitive yeah. Yeah. That's right. So if they're, I think that's fine on some level, right. Companies that are gonna do well, like it's gonna be more efficient for them to retain their great employees and support them in their growth. Then it will be to go back to their potentially small funnels and try to hire somebody else. So, you know yeah. They should leave those companies if that's not happening. And I think that's okay.

Don Hansen:

Okay. Okay. That makes a lot of sense. I think that definitely differentiates between what a larger and smaller company can simply offer. Right. And so, um, okay. So we talked a lot about like salary stuff. Um, now we're starting to branch into more like mid to senior level, how you can progress. So I want to bring it back to like entry level for the people watching this. Um, as far as. as far as take home projects, it, it almost sounds so there is my LinkedIn feed is 90% coding interviews are broken. Give us take home projects. Why aren't you giving us take home projects, take home projects relate. I feel like you've kind of answered why already, right? For the take home projects. I add one

Daniel Tomko:

succinct there. Succinct thing there. I wanna watch you do it. It's about the process. That's it.

Don Hansen:

And I, I mean, I've already given you the devil's advocate with that. I think, you know, both of you had a lot of good reasoning around why you like sharing the process. Unfortunately, there are managers not like you. Um, cause I've gotten to know both of you, but there are managers, not like you, that it's not as much about the processor. They don't even have that strict rubric. They don't, they they're looking, but I don't think they really have a strong idea of what they're looking for. I've seen this much more of a startup managers that are kind of just some are panicking. Some just want someone on the team and they're just trying to do the best job they can. And maybe some people are getting pushed into leadership positions way too quickly for hiring engineers. Um, but for the take home projects, it's, it's really interesting. Cause it almost sounds like you both are against that for the most part. If you can't really see the process and you I'm telling you, I know many aspiring developers, they're cheating, they're trying to cheat their way into interviews as take home projects. That is one of the easiest ways to cheat to, oh yeah. Spend three to five hours to his take home project. I'm just gonna, well, actually my one question for that is, is there any way that you can kind of spot that cheating? I've heard a lot of hiring managers will get them to like really dive in into the detail of the implementation. Walk me through your project as a very common question. Is that, is

Daniel Tomko:

that how you do it? I had a recent

Scott Ferguson:

experience where we had a candidate who was presenting and, uh, I had to like go watch my kids or something on this. So I like muted my camera, muted, my, uh, microphone. And I go back and walk through, walk through the house and I'm just listening back of my mind. I'm like, sounds like they're reading this for the first time. Like the way that they were describing it. And, uh, , I can get a slack message from, from the manager. Uh who's on that team who was hiring this person and he. So it sound like, like they're reading this for the first time and I'm literally Googling. I picked like a one giant, if statement was on screen that I was gonna get a nice big match on, uh, if it was, if it was a copy based and there it was, I got like three, uh, examples on GitHub where this had clearly come from and, you know, yeah. It's, I don't see a lot of that, but it happens,

Daniel Tomko:

you know, I,

Don Hansen:

if the company

Daniel Tomko:

doesn't have a good rubric and you know, I, I, I think those coding interviews are broken, you know, and you're, you know, all these people you're seeing complaining about this stuff on LinkedIn, like don't go to a company where you think they, where you think it's broken. I, I challenge you to go to a company that thinks really deeply about its interviews in the interview process. And tell me that that's broken, like, yes, there's gonna be false negatives. Um, that's that's humanity. That's, that's, we're never gonna get away from that. Um, but there are companies out there that think about this really, really deeply, and it interviewing there will be a great experience and you may or may not get the job, but, you know, I challenge you to like come up with a way that, that those well designed interviews are broken.

Scott Ferguson:

Also go back to the startup point, right? You're correct. Don like engineering managers all the time are getting promoted in startups when they're not ready for it. I was, um, it's, it's just a common pattern. It's I think probably less common these days now that the industry is kind of matured and then settled into, uh, roles and titles, but it it's certainly still a thing, but you go into the start world and you're gonna have less of that structure. You're gonna have less of that thought process. Um, You know, when we were at Aly together, one of the things that, you know, I did with engineering leadership was career ladders. Cuz we didn't have anything. It just wasn't there. Right. And it was a, it was a piece that was missing so that we could have those conversations start and start introducing that structure. It's always gonna be hit or miss in the start off world. One of the things I think you and I have talked about this before, but you know, one of the areas where I think. From what I've gathered of your audience. And, and specifically the, the entry level folks trying to get into the industry is these junior level roles. In some cases may be too high of a bar for where they're at, but internships are a great way to position yourself, to getting, uh, starting your career. And it's usually not the startups they're looking for interns. It's usually the bigger companies that do have the structure, have the better PA patterns and pathways to getting into the organization. It's a much lower bar that is far more accepting of somebody who is fresh outta school. Doesn't have a ton of experience and you're gonna come out of it with that experience, whether you convert at the end or not, you're gonna do a hell of a lot better on the, uh, the interviews that you go into, which comes from the confidence you earned during the internship. Um, and then, you know, leads the lesson of the nervousness, the freezing up. I completely forgot all about react type of, of experiences.

Daniel Tomko:

Mm-hmm I like that.

Don Hansen:

I have two more questions. We're definitely gonna use a full amount of time. You guys have 15 more minutes.

Daniel Tomko:

Sure. For you, Don. I got. Love

Don Hansen:

it. All right. So you had mentioned Scott, that internships are a really great way to kind of break in when you're definitely newer. I love that the problem I've always had with it are internships are very competitive. They're hard to find, but like you said, larger companies, mid-size companies, they're more open to that. And I think a lot of people are probably looking for internships in the wrong, at the wrong companies. They're looking at the wrong companies to find those internships. So definitely aim for a larger company, but there's also big

Daniel Tomko:

push

Scott Ferguson:

quick, add that also wrong time because internships are often seasonal. So I don't know how many are looking in the middle of winter.

Daniel Tomko:

Gotcha. So summer. Well, you need to be looking in, in like September through January, because the summer in intern, the internships are mostly in the summer, unless it's a really big company that has a, you know, enough of a support program that they can kind of run it year round. You know, for cuz typically these internships are targeted at university students and of course more and more people are not coming to software engineering through, uh, you know, a big university kind of program. But the reality is that these internships are typically on a somewhat of a university schedule. So the companies are hiring in the fall into early winter semesters for internships in the summer. Got, and if you're not looking at the right companies at the right times, you're not gonna get through. Not because. You don't meet the bar, but because you're just, they've given out all their summer internships already, or they don't have a winter internship, like you're ready now, you're graduating out of your boot camp now and looking for something, you know, starting in October while the companies that have fall internships, they started in S and you know, you know, so your next possible chance is maybe to get hired for a January start. Um, and then for all kinds of reasons, they want those interns to be in cohorts. Because they can sort of evaluate groups of them. It makes it easier to compare. It makes it, it makes it easier to support. It actually makes a better experience too, because they can organize intern events for the whole group rather than like, oh, we have one intern right now and we've got another one starting next month. It's streamlines, onboarding. Like it makes everything more efficient. Um, so I don't think that's gonna change. And like, so I think Scott's point that like, if you're going for these things, you have to, especially if you're not in a university environment, you need to kind of set your expectations relative to those kinds of timelines and programs designed for those people. Okay.

Don Hansen:

That's really helpful. Yeah. That's, schedule's super helpful. Um, I didn't even know that. So it was my, uh, original question. It was. Let's see, we were talking about internships. Oh. So with a big push, big push is a lot of these positions. A lot of these entry level positions are labeled as entry level. And I want to tell you why I think that is and why they're rejecting so many entry level applicants. I want you to correct me in elaborate. Um, if you have ideas, but a lot of people hate that all these entry level positions have so many requirements. They say like two, two years of experience, three years of experience, et cetera. And I think there are legitimate positions that are labeled as that are labeled at as entry level. And I sometimes I do think that bar is too high, but I think the primary issue people have a misconception when applying for positions. I always say that position is for the ideal candidate. You're never, almost never going to meet all of the requirements. If it says three year as an entry level, you should apply. Especially if it labels it as an entry level. That's I, I think there's a misconception, but I also think that each company has a different bar of what entry level means at that company. And I also think that there may be thinking like for my second position, for example, um, it was considered junior position. I went from AATE health, worked there for a year. They're like, yeah, this is a junior position. I'm like, well, I have a year of experience. Like we still see as a junior. And like, it, it took me a while to like, it's almost an ego check and it took me a while. I'm like, okay, Maybe I am still a junior and I went to that and they upped a bar quite a bit with react. Like we really dove into react. I'm like, oh, okay. I didn't know as much as I thought I did. Right. But that was entry level for them. And that's also why I believe some of these positions can be confusing to new people coming in because the entry bar is just higher. Those are my two beliefs about it. But what, what do you think about that common complaint entry level isn't really entry level and companies aren't putting their job postings online accurately.

Daniel Tomko:

I think it's definitely the case that the job descriptions are always aspirational. I think that's just, you know, and I have, I actually think this is a bit of a problem, but it's gonna be a really hard thing to, to fight. Um, I actually think it's, it's a bit of an equity issue, right? There's all kinds of research that says that, you know, Men will apply to positions. Aspirationally women tend to not like the psychology research has been relatively consistent on that for a while. So by writing job descriptions that are so aspirational, you are potentially preventing otherwise great candidates from applying. Um, so I, I do think that's a bit of a problem, but I also think it's, it's definitely the reality that we have today. Um, but if the position says entry level, what that means is that they're expecting to pay that person in that salary band. And so that actually means something real that actually behind the scenes, that means dollars. Um, so I trust that a lot more than I trust the job description. Okay.

Scott Ferguson:

I don't think I can even add anything to that. It's it's. Kind of sucks to like, like boil people down to just buckets of dollars . But at the end of the day, that is like a lot of where, um, some of the decision making comes from, like, especially as you get into some of like the salary conversations and things later on in your career, uh, and you might get, you don't realize that you're getting sized up behind the scenes with, well, this person's making less than that. And you know, they're doing far far more. Um, I, I agree. I don't, if you're asking for entry level, you're looking for entry level, um, where you price that is probably a much bigger concern than, um, than the actual specifics there. I've seen some hilarious ones too. I don't, like I came across one that was like entry level. You needed 10 years of, of like Excel. Okay. I was doing Excel when I was 11 it didn't make any sense. Um, so yeah, I wouldn't trust them.

Daniel Tomko:

Okay.

Don Hansen:

Uh, yeah. And you know, like you said that actually, I do remember, I do remember seeing some, a couple studies on that, Danielle and, and, um, there's even like, even if we expand past just like the way, uh, women think versus men with that. And cause I have heard of like, um, men are gonna be they're, um, gonna be applying to something a little bit more ambitious that is aspirational where women are a little bit more conservative with that. And just even the way what they should apply to, but that expands even to different personalities. Um, as well, it's like, there's some people that are just gonna be really good engineers that don't have a lot of confidence and that's a problem. A lot of aspiring developers. They don't realize. Well, yeah, they don't realize it is aspirational. They should apply to those positions. Right. Um, I think there are extreme examples where like, okay, this is getting ridiculous, like 10 years of what? 10 years of react are you sure? Right. French. So only four years old,

Daniel Tomko:

you know, one, one place, those, those job descriptions are really useful though, is in imagining yourself doing the things that they describe, ignore the year's experience, blah, blah, blah, blah, blah, blah. Right. But what they're telling you is something about the job content. Do you like if they're expecting 10 years of Excel experience, do you want that job? Do you want, that's telling you, you might be spending a lot of time in Excel. I personally do not want this job. Right. That's giving me useful information. Right. I just sort of scratch all those, all those years experience, blah, blah, blah, whatever out. But it is telling me like, this is what this team does. This is what this team values. This is what, you know, can I imagine myself doing these things right? And, and

Scott Ferguson:

on that same line, there's a very honest parts about it too. Right? Here's some experiences is really subjective because some people are just far more talented than others and some move 'em more slowly and that's kind of a, I've never actually measured a candidate up against that specifically on the, uh, as it's, as it is in the job wreck. But, um, it tends to be why I keep them out of, uh, career ladders as well, but run for the Hills of its Excel SharePoint.

Daniel Tomko:

WordPress

Scott Ferguson:

WordPress, uh, uh, Salesforce, right? These are bad things. You don't want this, but otherwise it is also telling you a lot of the things that the team is doing. We're not gonna put technologies in there that we're not using. Like, this is, this is a lot of helpful color and context into, um, what should you study up on before? What, what are some of the things you should be learning? Um, you know, what you should, should be thinking about? What are the questions you could be asking? Uh, yeah, a lot of the entry level candidates to your point, they don't really care about the company. They're asking more about technical stack questions, but, you know, come prepare with a couple of those maybe and use the, the rec to, to help guide.

Daniel Tomko:

Yeah, I like

Don Hansen:

that. It's good advice. All right. Let's move on to our last question. This is all good. It's all really good. It's a shame. I'm not gonna be able to release this for like, at least a few weeks. Um, so let's end with. Advice people constantly wanna know how to prepare for coding interviews. Like, I mean, anything could even mean, you know, a project that could mean data, search and algorithms. Maybe that even means you, you realize that you're eventually gonna get a take home project. I, I think the trickiness is everyone does it differently, but for aspiring developers that just wanna know how to prepare for coding interviews coming up.

Daniel Tomko:

What's your advice?

Scott Ferguson:

I've I've. Talked about this on here before, but my advice is the advice. I can never give anybody who works for me, cuz I can't ask em to do work out of hours, but don't stop writing. Always have projects, have something that you're doing on the side, just a passion project, whatever it is, something you don't know, uh, something you can learn with something it's all practice at the end of the day. Um, the more you do that, the more confidence you're going to get, the more that you're connecting those wires of the tool chest that, that Daniel, you know, you were talking about earlier, all those things start to make a lot more sense. And then you're going into that coding interview and you're speaking fluently. You're not freezing up because you know how to do this. That's just practice. And I, I feel like from what I hear and I've learned from you over time is it sounds like a lot of folks go. To their bootcamp, where they go to school and they think they have the skills and they, you know, get put in, in this place in an interview where they just don't feel, uh, equipped to do that. You have to work towards it. It is a very competitive industry and it has gotten a lot more saturated in the last 15 years that I've been in it. Uh, it was much simpler to penetrate back then, um, when I got involved.

Daniel Tomko:

Yeah, I'll I'll second that, you know, practice is really key. And I think, I know there's this perception that I hear this phrase, grinding lead code. Like I gotta, I'm gonna just grind a ton of lead code for, you know, end months or whatever, to like prep for these interviews. The problem with the problem with leak code is that the problems are all of a very particular style, or most of them are a very particular style. And quite frankly, like leak code medium is already generally harder than the work you typically do on the job in most software engineering roles. So they're not terribly realistic. Number one, And number two is if you're just coming out of a bootcamp, Lee code medium is probably above your level and spending all of your time working on those is not effective practice, right? Mastering the fundamentals is the way to build up to those things. So like, you know, if you're lucky enough to get an interview at a company like Google or something where, you know, the bar is really high, you know, you're, you're, you're fresh out of a bootcamp and you land this interview at Google. There's this perception that Google's gonna ask, you know, lead code, medium to hard level questions. The, that might be true. But the way to prepare for that interview is to master the fundamentals, to practice the fundamentals, to be completely fluent in the basic tools. Because like I said earlier, The more difficult problems are generally just compositions of the easier ones or compositions of the patterns you learned in the easy ones. So being super fluent with the fundamentals is the way that you'll be more effective at tackling a, a novel problem that you've not seen before. That might even be a little bit harder than what you're used to, you know, um, okay. You know, Scott and I are both musicians here. So I, I use this analogy all the time. Even the top performers on whatever instrument they still practice the basics, they still practice scales. They still, you know, whatever, or, you know, you see baseball players on the sidelines, throwing the ball back and forth at various distances. They still practice the fundamentals. So diving into Lee code mediums and Lee code hards is not gonna be effective practice for most people.

Don Hansen:

I love it. that's good advice that a lot of people need to hear. Um, that's even coming from someone that helps people get into Fang level positions too, because you don't often hear that advice from someone in your position, Daniel. Well, and

Daniel Tomko:

that's where I see most people fail is that they didn't, they failed on like, even if they conceptually understood the idea of the solution to a problem, I see them failing to code it because they weren't able to, you know, constructively put the fundamentals together. I like it. Exciting

Scott Ferguson:

to just run a marathon when you haven't done any training.

Daniel Tomko:

Yeah.

Don Hansen:

All right. We're gonna wrap up with that advice. This is good. I honestly, I have no idea how this episode's gonna be perceived, but I honestly think this has tons of good advice. So, you know, if you're watching on YouTube, definitely let me know when the comments you completely disagree. Agree. Do these two hiring managers sound reasonable or do they sound like the same hiring managers? Don't know what they're doing with the hiring process, but, uh, let me know when the comments, uh, Scott, Daniel stick around for a couple minutes, but thanks so much for coming on.

Daniel Tomko:

We.