guidance counselor 2.0 · episode 102
w/alishah novin, director of engineering
key takeaways
- skip take home assessments and whiteboarding. ask candidates about projects they built, problems they solved, and what they'd change
- review portfolios and github with written explanations of what the person tried to build and challenges they faced
- pair programming or conversational code review shows how someone thinks and collaborates better than solo performance
- resumes need clear language, years of experience plus project count, relevant accomplishments from any field, clickable links
- look for desire to learn shown through blogs, github activity, and honest discussion of struggles and current work
listen or watch
listen
about this episode
how to evaluate engineers fairly through portfolios and conversations instead of stressful coding tests and whiteboarding
If you like what you hear connect with me...
Website
full transcript
auto-generated from the audio, so expect a few typos. the audio is the source of truth.
Hello, hello. Thanks for listening to Guidance Counselor 2.0. Listen, I want to give you a quick rundown of what this podcast is and what you're about to get into as you listen to these episodes. We had Guidance Counselors in middle school. We had Guidance Counselors in high school, but we didn't really have Guidance Counselors in college and now as professionals, we don't really have anybody to turn to to ask a quick question to learn something about the job search or to navigate your career. And so that is what I want this podcast to be for you. I want it to be a tool for you to navigate the job search and your career.
So that being said, I hope you enjoy this episode. And if you need to reach me, Taylor at vaco, VACO.com is how to get in touch with me old-fashioned email, social media at tdesintd E S S E Y N. And finally, please rate and review this in the app store because I want this to be discoverable for others so they can navigate their careers. Hope you enjoy the episode. All right, so Alicia, quick background. Who are you? What do you do for all the viewers watching us this morning? Hey, everyone. So I'm the Director of Engineering at Salero Commerce, which is a FinTech company. It's a pretty exciting one where it's a startup company, but without all this stress and risk that can usually come with startups because most of their clients came through acquisitions.
So really exciting, fast paced kind of place, really passionate about agile and lean kind of development. So did our large agile transformation. I've been in tech for 15 to 20 in the year and 20 years, not quite there yet. You look great. You look great. You look great. Yeah. I don't show my stress other than gray hairs that I'm getting here. But yeah, so I've been in tech for quite a while. It's one of those kids that grew up coding. And really, the biggest thing that I realized was that as much as I love coding, management is like something that I love even more because it's substituting code problems with people problems or process problems.
And I love doing that. It's a love being problem solver. That's awesome. So again, a few more people coming in. Dorian, Dorian goes, I suck at tech assessments. That's great. and talk about that. Dan, what's going on? Glad to see Alicia on the show. Love this problem. Saw me. Hey, look, look at that. Hey, look at that. I love that. This is why we do this for Robert. Good morning. It's good to see you. I think it's Sean. What's going on? All right. So Alicia, so for those of you that don't understand Alicia's dad's relationship, basically, I'm an outlet for Alicia. Alicia likes to brain dump.
You should see our text messages because what Alicia does is Alicia texts me and goes, hey, Taylor, get ready. I have lots of thoughts. And usually I don't respond. and he just continues to just fill up my phone. And so I did the live show, I think a week or two ago, about technical assessments. And then right afterwards, he sends me this novel, and I'm looking at it now. And I was like, man, this is so good. We need to have you on again. And Alicia and I think similarly, but also, we're on two different ends of spectrum. So Alicia's a hiring major. I'm the lowly recruiter.
And we both kind of bring some interesting thoughts. So today, obviously, the technical evaluations, My biggest thing is stop with the take home e-vals, right? That's where I'm coming from. Stop with the take home e-vals. So Alicia, I want to kick it off high level. What are your thoughts on technical evaluations as just a macro? And then we'll go from there. Yeah. Let me quickly start with my background with that whole thing, because I went through the ringer. Like I did, I've definitely white-boarded in interviews. I've had like the really kind of weird bizarre brain teaser type things thrown at me. And then when I started interviewing, I kind of based it off of everything that I knew, which is what I experienced, both in terms of the positive and the negative.
And over the years, I've adapted my style because I've just found that it didn't really give me when I look back at who I gave assessments to, whether it was in the interview or beyond the interview, the caliber of the individual in terms of a team member didn't really tie back to that assessment. It tied back to so many other things. To the point where sometimes I'd say I probably just it ends up wasting people's time, including mine, but more so the candidates, and I'm not interested in wasting people's time anymore. But so, yeah, I think today, especially the way things work, there's just so much easier ways of really kind of finding out how someone knows about their craft.
And the best way I'd explain it is like, if you have a carpenter coming to your house, you're not gonna be like, hey, man, build me a chair. Let me see. Let me see what you can do, right? No, no, it does that. They bring you a portfolio, or they'll show you like they're on their phone, all the different things, or they have it on the website, and you can see what they can do that one. And some of it's based on trust, and some of it's, you know, you're kind of going on your gut based on how well they do. But I think that when you take that analog to actually interviewing it works a lot better, and it builds a better relationship with that candidate.
Yep, I love that. And again, I want this to be very interactive. I know a lot of people have thoughts, have a lot of concerns, have a lot of pent up frustrations. Again, part of the reason why this is guidance counselor 2.0 is an elevated guidance counselor. I joke that I'm part time psychiatrist to a lot of people. And so again, if you all have thoughts, comments, questions, I have a hiring manager. I have a director of engineering on this call. This is now a time to ask good questions. So please ask good questions. Throw them up in the chat and we'll get to them as well.
So Alicia, so let's talk about one thing you talked about, your portfolio, right? A carpenter comes into your house, or you evaluate a carpenter like, hey, what can you build me? Why do you think companies, and I'm curious, there's no wrong answers, why do you think companies try to grill with code assessments? And they get no right or wrong, but just in your thoughts, why do you think some companies are so tied to that? And other companies are saying, hey, let's have a conversation. I think they just don't know how to assess someone's ability. I think that, so this is, you just opened up a box here.
So let me, I'm gonna be texting you while I talk. How about that? So here's the deal. Like I think that, I think everything boils down to the complexities of what writing code is. And you can take everything from like, imposter syndrome to interviewing. And it all kind of stems from the same problem, which is, as far as I know, it is the only discipline or area or job where you are taking your brain and you are showing someone else how your brain works. There's usually other examples, like if I'm doing carpenter carpentering in front of someone, they'll be like, why are you using a, I don't know, a 16 millimeter chisel?
I'm not a carpenter, so I'm gonna throw it. You're literally talking, I can't do anything with my hands. Right. So like but but but if I let's take like a deck of cards and you can say hey go sort these cards out right? I'll start sorting them and you'll start to look and go okay I kind of see what you're doing and why are you sorting it that way right but code is like It's removing all barriers because I'm writing exactly the way my brain is working to solve a problem and It gives insight but it also opens you up to criticisms and when someone criticizes your code it feels very, very personal because that's your brain being criticized, right?
But I also think that when we do technical assessments, we're trying to assess, you know, how does this person think through a problem and how do they know their craft and they're having to do it often, regardless of whether it's an interview or outside of an interview, it's a stressful situation. And so, you know, the brain plus stress doesn't ever equal anything to it. good. So I just think that it's kind of a, it's not a, it's not effective. I mean, it's not a thing that never produces good results, but I think that there's much better ways. But I think it's all just like an inability to be able to easily assess how good someone is at something.
So this goes with Steven's question. I kind of want to, Alicia, what do you look for? So let's talk about like let's say like like just you what do you like to see the people who are watching this obviously range from very junior to senior level to hiring managers like yourself what are some things that you look for from a candidate perspective let's start there and then what should hiring managers look for so let's start on the candidate side job seeker side what are things that you like to see from job seekers when they are in interviews or how you evaluate job seekers yeah so I I think if you're depending on where you are, I mean if you have, so I obviously love seeing portfolios and I love seeing get hubs.
I like to see, but I don't like to just see code. I think that that doesn't tell me the full picture. And I love it when I see someone do like a quick write up, even if it's a paragraph that says, here's what I was trying to solve, over here's what I ran into. I don't even care if it's a full complete product. If you're tinkering with graphic libraries and you're like, oh, I rotated this image 90 degrees and I compressed it or I took any image and blah, blah, blah. If you do that and just kind of explain what your process was, that's a lot more interesting than the code.
It's so hard these days to truly know what code someone wrote versus copied off of Stack Overflow or some other website, right? You know, I never realized you could copy code until I had one of the guys I placed on contract, I copied a bunch of code. Yeah. And I didn't know that was a thing. Yeah. I mean, there's a good story of a guy who got a job and all he did was he sent his projects to someone else offshore and he just made bank on it. Right? We had to have him before with our consultants. But I mean, like, so there's no, it's hard to truly tell how much that person's written if you're just looking at code.
But if you look at what they've written, you have a better sense of that. So I like to just see that kind of activity. I like to see more frequent activity, obviously, but I know that some people just don't have the time and that's easily like just giving me the explanation and I'm good with it. But if I'm in an interview, that's usually my line of questioning. It's a lot more about what did you build? What were you trying to build? What was the problem you were trying to solve and talk me through what you ran into? What did you do wrong? What would you change if you did it again?
You can learn a lot just by those questions without having to be like, take this string and reverse it. You get so far with that. The only time I will ever these days throw out a whiteboarding question is if I really like the person and I really think that they've got the right attitude and everything, but I'm really on the fence in terms of their skill set and everything I asked, they just sort of weren't quite hitting it. And there are people like that, right? There's people who just don't, they overthink or they stumble or they don't know the key terms and so they'll just not get it out the right words.
And so I try to do them a favor and usually there that's when you'll start to see a little bit more of a glimmer. Yeah, I try to really kind of get it conversationally over this district question. So Casey asked a great question. Casey, what's going on buddy? To play devil's advocate, what value do you hire a manger see in a take home assessment? What does a take home assessment offer the other forms of evaluation doesn't touch? I also have some thoughts on take home assessments versus like live kind of coding pairing things on. So, yeah, at least you crack this. Take a crack at this.
Yeah. So, honestly, like at this point, not to sound like totally blunt about it, but I think that I would highly question how many people do a good review of what they get from a take-home assessment. And I'll tell you why, because I bet you, and I've never had it done when I've done them, I bet you they don't sit down with you and say, walk me through your code. And so if you're not doing that, like how much are you truly learning from that person? You can probably get an idea of, okay, it's now they structure their code and other. Got comments, they're just good.
And like, oh, they follow this sort of style. And, but that's like basic stuff. And you're not gonna get that in like that internal monologue a person had in terms of when they bring out the solution. And so they're either doing a quick pass at it just to see, okay, do they have a skill? They'll probably just, you know, compile and run it and say, okay, yeah, it works and it doesn't work. And they might look for, if there's like an interesting hook to that problem that they sent you, they'll look for that and say, okay, they took this approach rather than that approach. But again, you're kind of like, you're looking at a very binary and maybe you get a lot of candidates and maybe you have to find a way of filtering them out and maybe this is your way of doing it, but you're losing out on a lot of great people that way.
And so I think that it's just, it's a technique, but I don't think it's providing much value. I've never had, like I said before, I've never found a candidate that did a take home assessment and was exceptionally better than someone who didn't do one. I think that there's a lot more that you can glean from it beyond just like technical scale. Do you think, like if you were to pick take home test versus live coding? Which one do you think or maybe another one I'm missing? Which coding? Often three. I'll tell you what option three is and I love this. What is option three? It's when, depending on the candidate, it depends on how prepared they are.
But I love being able to look at someone's code that they wrote on their own without having me ask them a question about it or to do what I mean. And they come in and they're like, this is one of the projects I did. And they start telling me about it. And some of the challenges that they ran into. And some of the, oh, I didn't know about this library. Or I didn't know you could do it this way. And so afterwards, I ran into these issues. But I went back to my Kickstarter and did this thing. Because then it's all of theirs, right? And they can talk through it logically.
And you can tell if someone's phoning it in or being phoning about it. But usually then it's like, I don't have to do the work Let me find a problem that is a fair problem that is going to be like there is no standard question because people are there's no standard person right so you're not going to be able to like measure people equally in that way and the key is not measuring equally but it's measuring fairly and so you have to find the thing that is going to get that person to show you their skillset. There's a reason why they got to that point of the interview with you.
And so now you want to, you as the interviewer, you want to let that person do their best and show what they can do because think of the situation. They're nervous, they're anxious, they want to do well. Everything at a work, inside your work is probably going to be not as stressful, right? So. Right. I love that. A lot, again, if you all have questions, the questions are coming, this is great. Muhammad goes, Alicia, does a resume matter to you? How do you value a developer? I do like resumes. Maybe I'm old school, but I do like them because here's a here's a thing that I Heard one a while back and I absolutely love it like I think a lot of people call themselves perfectionists And they kind of wear that as a bat to pride and I heard this saying that says that Perfection is procrastination in disguise and I think ever since I heard that it really kind of changed my world of view because The key is that I do try to make things perfect when I don't want to do something else.
But there is an important part in there which is like the seeking of trying to do something great. So from that I heard this other thing which is this idea of signing your work with excellence. Which means if you're going to give me an email or if you're going to give me an Excel document or you're just quickly throwing together some fonts, sign it with excellence. Which means do a good job at it. everything that you do presentable, almost like the final draft of something, don't give me the rough draft. And so with your resume, I can always tell who is spending time on it versus who is just sort of like, oh, this is, you know, like I just quickly threw things in there.
So obviously like what I love to see at the top is your programming proficiency, what languages do you know, what text, do you know what platforms and everything that you've used and those kinds of things. I'd say put those at the top, make them the most visible, followed by your experience and make that extremely quantifiable. I know that a lot of people like to take. It almost sounds like everything I've been saying. Yeah, no, I know. That's why that's why we definitely agree. I think a lot of people are kind of like trying these new formats and new styles where you put your headshot up on there and all that stuff like.
Stop it. go with like the 1980s like American Psycho like nice, nice font all that stuff. Yeah. Nothing fancy. Yeah. Well, because I played that well. I interviewed Josh Carroll who is CTO out Knoxville and he was like, I'm telling you, he goes, if I see color, I reject it. He goes, it just, it literally takes away so much. He goes, I don't have time to sift through it. He was my hiring junior developers. I guess like a hundred resumes since like it goes if I immediately can't tell what you do I am declining it in the system and it's usually around color or a bunch of odd spacing stuff like that So and you don't don't do this do not put like JavaScript four out of five because I don't know what your five is.
I don't know what your four is Yeah, I I got in the conversation on that on Twitter the other day Like the way I do it the way I have the summary portion of your resume The way I like it is like kind of writing a paragraph when we were in high school, right? Start very general and go specific. So 10 years of overall engineering experience, seven years of development experience, three years of net core, two years of angular and a BS in computer science. Like that should be the summary because you open that up and be like, all right, literally, I know what this person does.
And so, and that is obviously lines up and I think it's very effective. Can I add on to that? Sure. years, like years don't always correspond to experience, right? Sure. So say how many projects? If you say 30 projects in two years or 30 projects in one year, actually I'll tell you the quick story of like how I went from graduating to working, which is like that was the beginning where everyone was like, oh people are graduating and they're not finding jobs, they have no professional experience, they don't know how to work in their workplace and that was me and I'm going to try and keep that story short, but like I was freaking out because someone else had graduated with a physics degree, I graduated with a physics degree, he was a year earlier than me, and he was having such a hard time finding a job and I bumped into him driving a tour bus at the time and I was like, I didn't have a license because I lived in a big city and so I had no reason to drive and I was like, I won't even be able to drive a tour bus.
So I like went on Craigslist and just took every single possible job I could and charged very, very little in terms of just because I just need that experience. But I came out of college and I had a resume of like 20 projects and I went into an interview and I wrote my last exam and then went into an interview and I got that job. I know that like that was a luxury that I had because a lot of people don't always have that chance to you know go and pursue work and not get much money for it. But the point is not necessarily like charging a little for it that's more about build your experience in any way that you can and reflect the number of projects that you have because that'll speak to your experience overall.
If you've done 30 projects versus two, that's way better. I love that. Victor goes love this insight, Alicia. That's why I got him on. I had to Google this because I know what it meant. Data algorithms, data structure, algorithm interviews. I had to Google DSA just now. I'm just gonna, I know what it meant. What are your thoughts? As a recruiter, I hear hiring managers talking about algorithms and data structures. Why is that important? I know when I interviewed Eric Yeager, engineering manager at Amazon, they're really big around the Amazon. They're not interviewed in an agency, Byron. He's like, that's dumb, right? So this seems like a very divisive subject within hiring managers.
I'm interested here the Alicia thought. I hate them. I do. I've done them. I have given them. I'll admit regretfully. I don't wish that I didn't. The reason why I don't like them and this is not my brilliance is something that a guy that I really respect James once told me, which is that if you just look at when those kind of like data structure algorithms and like let's just take sorting because that's a big popular one that the people throughout there, right? You look at when people like devise these sorting algorithms, like that was academic research. They spent, you know, a couple years trying to figure out like these different ways to optimize for memory or optimize for, you know, speed or whatever it might be.
And they, you know, that was a very academic pursuit that didn't just take 10 minutes in an interview in a high stress situation, right? And if I'm asking someone to do that in front of me, I'm asking them to do one of two things. Either be smarter than some academic PhD student who is like, you know, changing computer science for the better in some way, or I'm asking them to just rehash something that they've just memorized. And that's not going to be a skill set that I'm going to really value in the long run. Best interview I sat in, or the best interview I gave when I was asked this kind of question.
The guy was helping me out throughout where I would run into something and he'd say, Well, you could Google that or you could like, what if you change this or have you factored this in? And so he held me out along the way. And that was much better because he was assessing how well he could partner with someone on his team to troubleshoot or to problem solve. And that I think was a lot more illuminating and he learned a lot more as opposed to just, you know, write this thing out. Like, the equivalent of asking someone to say very ABC's in front of you. It's like, what does that show you?
Right. No, I get it. I get it. Um, some more thoughts coming in. Let's see here. So John says pivotal now VMware has had the best tech part of an interview. I've ever had pair programming. They write the code that you express the idea. Take out the gotchas of riding on the spot and blanking on some syntax. Yeah. So I'll tell you the, the, the, what makes that interview work well is not the style. It's not like even if you do it in the whiteboard in session, right? It's all down to the style of the interviewer. Because I've done one where I literally have the guy tell me that what I wrote on the whiteboard doesn't work.
And it was insistent. I didn't back down. I said, this is going to work. He pulled up at the time, it was MSDN. It was like Microsoft's resource for code. And he looked up and he said, that function that you're calling doesn't exist. And he pulled it up and there, he said, it's not there. And I said, I don't know what to tell you. It's a problem with MSDN. Go code and you'll see. and he finally coded it and he ran it and it worked and then he looked him and he said you've won this round and that was not a positive experience that sucked and so like what is you got it comes down to the style of the person not the style of well and that's where too and again we're we we can go on this probably all day like a telethon type situation so I do I do want to wrap up here with a few more questions and thoughts and here's my big thing why do you think the interview process is not accepting and more denying?
Right? Because like for me it's like it's not inclusive hiring. It's like hey like you need to prove to me why you need to work here. It's a very like beat them up mentality and it's like man like I don't know to me that just doesn't make sense. So what are your thoughts on just a general state of interviewing and how it can improve? So I don't think that's, part of me wants to say that's exclusive to tech, but I think it's also like, think back to high school where it's like, there's that band that you like, and there's two types of music fans. So there's a kind of like, I'm gonna go with this.
There's two kinds of music fans. There's the kind who's like, this is my band. I don't want anyone to know about it because it'll make this band sell out. I don't want to share them with anyone. And then there's the type who's like, you've got to listen to this band. Come be a fan. see the show come do this right and those are the inclusive bunches and I think that that's like I think that's just ubiquitous across any kind of industry and I think that tech just happens to be like in terms of personality types arose out of those kinds of personalities where they wanted it to be more exclusive and they wanted to kind of keep people out and so those practices arose out of that but I think that you know I think that shift has happened over time where people are a lot more, you know, they want to share their passion.
And so when you like, when you bring someone in for an interview, oftentimes you want them to succeed. And the question is, I want them to succeed, but then will they succeed with our team? And that's the critical question that they have to be asking. Because sometimes I turned away people that I absolutely love because I knew I didn't have tools to support their, their needs within the team. And that's, that's the challenging question. I love that. So we're gonna go lightning around here, Alicia. So real quick, Andrew, how important is attitude and eagerness to learn when trying to break an attack from another career?
Wildly, but part of that means that you will have shown it by having a pretty awesome portfolio or a pretty awesome project that you can show me. I love that. Kio goes, good morning, Alicia, following up on Muhammad's question, should we include accomplishments from non-tech previous positions or exclude them and just have company position dates. So I guess a little bit going from junior dev. Yeah, if it's relevant, absolutely. Like I've especially for the role, right? If there's like there are coding roles where you are somewhat customer facing. And if you've been in customer service, if you've been a waiter or anything like that, I mean, that is a relevant skill set.
I don't care what other people say. I mean, there is value you get out of that for sure. Awesome. And the modern day of resumes on PDF, do you prefer URLs you can type in yourself or readable and clickable links. Readable and clickable links. I love it. Just don't recall me. Let's see here. Last question and we are done for today. Which quality do you value most in junior developer? What is the best way to illustrate this quality? So quality that I value the most is that I mean that that's not anything future. It's just desire to learn and that their ability to show that.
And so One of the best things I saw on someone that I hired had great time with while I work with them. They had a blog that just showed me the new things that they were reading about. They weren't even successful. They were like, I'm trying to build this thing out and I'm struggling. But it just showed me that they were not only in turn, like it wasn't just an internal thing that they were doing. They were out there publishing it to say, this is what I'm working on. It's the struggle that I have. And usually that comes out in conversations too that I have with people in interviews.
if you are throwing up your portfolio or on your GitHub, it's that kind of like what I'm reading currently, what I'm working on currently, what I'm struggling with currently, and you show those things and you kind of get a sense for that person. I love that. Well, Lisa, thanks, man. That was awesome. I knew it was gonna be awesome. So, Alicia's gonna be a mainstay on Guy's Council 2.0. We'll get him on once a month. Because obviously, again, can't hear the music. Of course, I can hear the the music. But again, thank you opportunity and I appreciate it. Alicia, thank you for coming on, buddy.
I appreciate you a ton. Y'all go care cliche. He's one of the good ones. And I will see y'all tomorrow morning, 9 3 a.m. Central joined the texting community. Check out my website, Taylor Dustin dot com. Also to have a few more guests this week. So Thursday, unicorn finders, I have basically somebody who's getting the blockchain. So check that out. My company getting into blockchain. And then Friday, I was on a panel with Mint Bean. And I have a engineering manager from the Clorox company, Joey Shakespeare. That's gonna be Friday talking about hiring and hiring junior devs. Check that out. So y'all, thank you again for tuning in.
Andrew, I see the fire. I'm using your hookup with the cables and things. So thank you, Andrew, for doing all that. I appreciate y'all telling y'all a good one. Hey, you did it. You listened to an entire episode. And I am very grateful. Because you know why? There's a a lot of podcasts out there. There's a lot of episodes, and I myself rarely finish an entire episode, so I appreciate you so, so much for listening. Quick reminder, please rate and review this podcast in the App Store. I want this to be discoverable to others, and the only way that happens is if you take the time right now and rate and review it.
Please, like, right now. Unless you're driving, then don't do it. So, thank you again. If you need to reach out to me, Taylor at Vaco.com, or at T.S. and on all social media handles, and I hope you have a fantastic day.