guidance counselor 2.0 w/eric yager, software development manager at amazon

full transcript

auto-generated from the audio, so expect a few typos. the audio is the source of truth.

But Eric, before we dive in, as we get the people trickling, give a little background about yourself who you are and then we'll get into the topics. Yeah, sure. So Eric Yeager, I currently work at Amazon and Nashville. I work in the Air Science Technology organization. We build out some science models and technology that supports our aircraft movements and move packages from one place to another. Before this, I was a software engineer at Dell Technologies down in Austin, Texas. And that was after about a decade in the Army, where I lived in a bunch of different places and did a bunch of different things. I don't know what else you want to know.

No, no, that's great. No, I love that. And yeah, so Eric, so tell the people, tell the people how we met because I try to practice what I preach. So I want Eric to talk about how we met. And before we do that, pee a good morning from Nevada, I have a good morning. Eric has always good morning. Thanks, y'all, for saying something and not lurking. So Eric, how did we meet? I'm pretty sure we just met up Twitter. We did. I think I just came across to your stuff and started commenting. Yeah, we did. And again, the power of Twitter, Eric popped on this live.

I popped on early before we went live. And I told him, I feel like I've already met him, but I've never met him because of the power of Twitter. So that's why it's so important to network. So let's go ahead and dive in as 930. So for those of you who are watching again, thank you all for tuning in. We appreciate it. Again, add us, comment us, let us know your tune in from. We'd love to hear from you. If you're scrolling, past LinkedIn, either now or in the future and you're like, hey, shirts and like, and here's you talking to what is this? Listen, here's a quick background about guidance counselor 2.0 when the pandemic hit last year, the thing I heard most about the most common theme with job seekers was, hey, I feel like I'm on an island.

I feel scared. I don't know where to go next. And so for me, what my goal was, like, man, like I got LinkedIn live early, which was before really anyone got, which was really appreciative of that. I was like, why don't I just hang out with people every morning? Like not really have a huge agenda. I spoke at code conferences before the pandemic. I was like, why don't I just essentially give that same talk over and over again every morning? And so that's what this is. This is the reason why I tell people to comment, to like, to share this is because this also is an opportunity, right?

Jorge just joined Jorge, can network with Erica, can network with Ivan, can network with Pia, right? Hey, Pia, saw your Taylor's live show would love to connect. That's why I tell people to comment and like this. And so I want to go and dive in this morning with Eric. And so Eric and I have had a lot of great banter on Twitter. And I was like, man, you've had some really, really good thoughts on a lot of topics. And so the two topics we're going to talk about today is getting into tech, right? Like, like, newbies getting into tech, some things to keep in mind from Eric's perspective, from a hiring manager's perspective.

And then also breaking into fang, breaking into Amazon, Netflix, Google, all that jazz. And so we're going to talk about that today. So Eric, enough with me running my mouth, let's dive into the first topic, new tech, or new people getting into tech. Just give me some thoughts and let's chop on this for a few minutes and now I'll see you some more follow up questions. Sure. I think one of the biggest things that I'm asked and what I talk about a lot is how to get in the tech when you don't have an engineering degree. I would say that's probably the largest chunk of people right now that are trying to break into engineering roles, breaking about a management program management, all those different tech and tech adjacent roles.

I think the best way to do this is to A, have something professional that you can put on your resume. You know, you can sit down, you can do leek code, you can do all these other online resources for years and not necessarily have a resume that says, I need to hire this person to take this tech role in my company, no matter what that size is. But there are things you can do that would be annotatable on your resume. So boot camps. I'm a little bit hard on boot camps sometimes. I think a good chunk of boot camps are pretty predatory. It's kind of easy pickings right now.

You can charge somebody a couple thousand bucks and show them how to traverse an array and then do nothing else for them. But there are boot camps out there that have a lot of these B2B relationships that have relationships with companies that can do even placement. Or just by name recognition alone, you can finish a boot camp, put it on your resume. And it's like, okay, this person has this baseline of knowledge that we can tap into in an entry level of renewal. Another thing that, go ahead. Oh, so my, so, most of you are thoughts on this. I preach this, I'm sure you've seen me preach on Twitter.

Even if you code in boot camps and you have capstones and you have projects, no tate it essentially as like professional experience on your resume. Because I think what happens is, and I'm interested here thoughts, right? Because for me a lot of times as a recruiter, I see side projects, you know, whatever. And my eyes glaze over, right? Like your professional, your job right now in code school is to develop a capstone project. And hey, listen, I put out something the other day on LinkedIn that was crazy. I said, hey, devs, on average, what percentage of time are you hands on the keys? You know what the answer was?

Like a ton of people across the country, 20%. 20% was the average of devs. I will tell you this, some of y'all on boot camp are code more than 20% in the day. So like put it down. And so I'm interested here, thoughts on that topic. And if you disagree, that's fine. Yeah, I mean, it's a tough subject. And kind of the second thing I was gonna say was to take actual side projects with like startups or anybody that has an idea. Oh no, yeah. If you have a buddy with an idea, you know, take that person's hand and say, hey, I'll write the website for this idea you have.

I'll do this thing that can go on the resume as like actual professional experience because then you could say you're software engineer. Now that's not gonna help necessarily in an interview, but it is something on your resume that says, I've done this thing. Here's a demonstrable thing. Maybe here's the code base for it. And that says I have some experience. So I think those two things put together should be at least the initial foundation for people that are breaking into the industry. You know, buying, it would damage courses, kind of help teach you things, but you have to have those demonstrable experiences that you've been through.

Because that's gonna give an interviewer that's gonna give a company something to kind of pressure test when you're in an interview or you're being courted for a role. You need to make it, and this is kind of, you know, may not sound good to some people but you need to make it easy on the company to say, this person is what they say they are. We need to hire the person. Sure. Because you are competing against people with degrees and people with experience. So you need to just have that ability. Yeah. Anyways, you're sure. No, no, no, that's good stuff. So I just had a question pop on my head.

So let's talk about like, what do you look for when you interview junior devs? So this is the question I get all the time. Right? And like for me, I've talked a lot of engineer managers, a lot of tech leaders on this show. And they're pretty consistent the answer. So I'm interested to hear yours. Like what do you look for? So if you have these junior devs wanting to get in a tech and they're like, hey, tell me, what do I need to practice? What do I need to get better at? What do I need to bring in interviews? What would you say? Sure. So I'll start just with the first part of the question.

What do I look for when somebody's looking at a role? And this isn't just software engineering. This is every single role I think that I've conducted interviews for or I've hired for. What I'm going to look for is I have a job requisition with basic qualifications for third qualifications. I'm going to look for a plurality, probably a majority of the basic qualifications and maybe some of the preferred qualifications. I'm going to look at a resume and just make sure that that pings off of what the requirements say. Some people kind of get intimidated and say, I have to have all the basic requirements, right? All of those that have to refer to requirements.

I don't think that's necessarily true, which you have to have a majority. You have to be pretty close to the realm of the basic qualifications. Now when people are kind of further to the left of that and saying, what do I have to do to get into a role? And I might talk outside of Amazon hiring right now, or at least what I do for Amazon. But it kind of goes back to you have to have a certain amount of those basic qualifications, which is kind of a chicken and egg scenario, which kind of presents a bit of a wicked problem, which is you need to have experience or a degree and you don't have four years to get a degree and you don't have, you need the experience to even get experience in the first place.

And that's kind of the tough scenario. But that's where I go back and say, if you have somebody with an idea or you have an idea yourself, maybe consider doing something towards that idea in a professional realm and incorporate something, do something in there to have some sort of like business impact with the software you're writing. But it is a little bit tough to break in. Now with Amazon, I'm not, I'm not going to talk for Amazon across the board. I'm talking to my experience in Amazon because I wouldn't do Amazon justice. I worked there for a year. It's taking me 10 or 15 years to get to know probably half of Amazon and by then it's all going to change.

But what I'm looking for with external candidates is normally going to be more of a mid-career level engineer. So I'm looking for usually the baseline is going to be a degree plus three or four years of experience, including design and architecture experience or enough experience that covers all of that. So I'm not going to say you have to have a degree. But if you don't have a degree, I'm going to look for a good chunk of experience. That experience needs to be pretty deep. You do have driven architecture for a team. You need to have written software for a number of years. You know, you need to show that you have that mid-career level of experience just because that's the direct that I have for my team is a mid-level wreck.

But how do you, so today I'm talking about resumes on Twitter. So how do you gauge that though? Like what do you like to see? I talk about like having project-based work, having quantitative information. What do you like to see as a hiring manager? Sure. I think project-based work is extremely important. So I'm going to look for, and I don't really care if it's a native project on care if it's a web project. I'm going to look for something that shows that you wrote some code. The code was safe. You wrote test for the code. You did all those things with code that shows that, if you come into this organization, you're going to write safe code.

You're going to elevate the engineering experience with the team in the company. And what I kind of tell people, when it comes to your resume, your resume is the chance we have to say what you've done. The interview is where the interviewer should be validating what's on your resume. So as the resume says, you have the baseline requirements for this role, the interview is going to take the time to dig into your experience and validate those experiences that you put on your resume. I know as an interviewer, I could tell pretty quick if somebody was actually the lead developer for this piece of software, or if they were a technical program manager, international technical program manager capacity, as opposed to just saying in the resume.

So that's, you know, when it comes to the resume, I wouldn't really lie. I wouldn't embellish. I would tell the truth. And then if you don't match what the company's looking for, try to find out what you didn't match on and build up and try again. Yeah. And so going back to, because I really want to key on on this, I know you're hiring mid, but what would you say junior devs when they interview need to bring to the table? Yeah, they need to bring to the table a pretty deep knowledge understanding on data structures and algorithms. I don't think you're going to get away from that, especially in FANG.

That is kind of the quintessential method that's used to test problem solving and then test kind of code knowledge. There's a lot of arguing back and forth on the validity of that in the industry. I hear a lot about, I get tested on DS&A and then I never do it again in my career. I think some of that might be true, but I also that ask a question like, what else would you want to do that efficiently test your, but I don't really get a good answer back and it's kind of tough to, I don't know, some bit might be habits. The fastest method to test whether somebody knows how to code, but you're not going to get away from that.

You're not going to be away from data. Men, at least for the foreseeable future and answer questions about traverse using the clients E kind of on the spot. I'm also going to, especially Amazon, we're pretty much focused on the leadership principles. For a lot of the examples of the leadership principles and you're going to be asked a lot of questions around that. They ask leadership questions like, did you come in and positively affect a team or did you just kind of take the, and just say, okay, this is the process and go forward with it. We're going to look for some level in kind of that realm.

We're going to look for people that aren't just satisfied with the sad quote, that are going to come in question why things are done and then maybe provide a new way forward. So we're going to look for some, along those realms. I think that's for a junior dev that that's probably a big chunk of what you're going to do in terms of what's going to happen in the interview. A little bit. Yeah, I mean, Casey, yeah, Casey right here, again, so we just kind of touched on this. What kind of projects do you want to see an important folio? What specific skills you're evaluating? Yeah, I mean, it's like Eric just said, again, it's wants to see project-based work, but wants to see obviously, from his perspective, some data structures algorithms.

And then obviously, I think from a specific skills perspective, what Eric was just saying was around, hey, you need to be able to communicate effectively around some leadership stuff. And also I think the big thing too, Eric, and I'm interested here, it's all like, people just don't really don't have to talk about themselves. It's, it's, it's, it's, it's great. It's true. Because you get an interview, it's like, yeah, yeah, here's your time, people are like, what? It's like, bro, come on, let's talk about yourself. People are like, I can't. And it's like, oh no. So like, I thought it's thoughts on that. Yeah, I did do it.

I thought a little back before we had on Twitter the other day. It takes practice. You have to get really good at a talking about yourself, talking about your experience, answering questions, but also be reading the people you're talking to. Make sure that they are engaged with what you're saying. Cause that kind of tells you, okay, this is what that person's looking for as opposed to, maybe this is what's boring the crap out of them and I'm not getting their interest. Cause I think at the end of the day, a lot of interviewing and a lot of, a lot of the skills behind that kind of go back to maybe some subjective things and keeping your interviewer interested might be one of those things.

So, you know, practice. And I think one of the comments I made there was you should be interviewing as much as possible. You should be taking one-on-one. You should be doing this. Even if it's at a company or a role you don't wanna do, there's a lot of muscle memory that goes into talking back and forth. I know for me, I haven't practiced it very much at all. So I feel like I'm talking 10 miles a minute right now. But this is something that I need to do to practice. And be good at engaging people and keeping people interested. It's something that you need to practice.

It's definitely, so Casey asked another follow-up question. Again, Casey, thank you for the questions. Again, if anybody's watching, if you're lurking in the shadows, this is your time to ask a dev manager at Amazon questions. So do it. What type of leadership principles are you referring to? Are there anything that you like to see just with your team? Again, we're gonna talk about your team. Is there anything you like to see specifically? Yeah, I wouldn't mind. Casey had another really good question too. I wouldn't mind hitting that and then hitting the LP Quads. He's done my work. He has a question with Project Based Work.

What would I look for in Project Based Work? Oh, yeah, right here. Yes, yeah. So for a portfolio, depending on the, if you're going to a full stack role, the projects that I'd want to see in a portfolio are gonna be full stack projects. A lot of times I'll have people that spend a lot of time on front end that reach out for a full stack role. And front end is important that's your presentation layer. But the projects I want to see in a portfolio are really gonna be projects that show a lot of back end knowledge and a little bit of probably front end knowledge.

So I'd like to throw out just the unofficial statistic. I think full stack engineering is 70% of the back end and 30% of the front end. And the back end is gonna include the APIs that serve data from a back end up to a presentation layer. So I'm gonna want to see some really good examples of somebody that makes a presentation layer has connective tissue between their, the fact of tissue is efficient, that's written well, and then they have good back end knowledge and how to manage data, manage files, things like that. So we're really gonna look for good examples of full stack projects. I love it.

Now going on to the leadership principle question. So the interesting thing with software engineering is a lot of leadership principles don't necessarily dig into software engineering specifically. So I'd almost take software principles and technical proficiency as it's only to ship principle that is probably gonna be towards the top four software engineering role. In terms of other LPs, we're gonna look at least, I know I'm pretty partial to like disagree and commit, having a backbone, having people that aren't just gonna come in and I referred to this before, but aren't just gonna come in and do the workflow and do the bare minimum to do something.

I'm looking for engineers to come in and kind of tell, I'm hiring somebody at a certain level to come in and tell me what to do. At the end of the day, I'll make a decision, but I need a team that's going to be made of people that aren't afraid to say, this is wrong, do it this way. This timeline doesn't work. We need to have more time to do the software or we're going in the wrong direction. We need to either refactor something or do something different. So I think that's probably the one that I'm looking for in addition to technical proficiency for a software engineer.

If that makes sense, that's your question, Casey. I love that. I love that. Casey, let us know. So let's hit Tiffany's question then, let's bounce to our final topic for today. Because I knew I had to feel that Eric and I could go nine hours but we all have work to do. So Tiffany goes, how do you recommend that, and it's looking for the first software engineer will stand out. Tiffany, we hit this definitely on the first part of this live show, but Eric, if you want to recap this one more time. Sure. And I might give an answer that we didn't talk about yet.

Right. The key to standing out is to not just be a resume. And you're going to, I'm going to have a pile of people that are just resumes. You're a piece of paper with a name on it. The people that are going to stand out are the ones that effectively, and it is kind of tough because the hiring process is going to be you apply, the stereo typically you apply, you do a phone screening, you do on-site, you get a hiring decision. But way back in the beginning there is all of the applicants and kind of weeding through them. I'm probably going to see somebody that did a one-on-one with me that I had a discussion with, that I kind of pre-vetted as standing out more so probably than a pile of resumes.

It wants to get a face to a name and you get kind of a backstory from their own mouth. That isn't just bullet points at a resume. All of that. A lot of it. That's probably the best way to stand out. That's awesome. I'm going to be able to do a mentorship with people to transition from the military. And it's the same thing there too. You can be a company commander. You can be a brigade commander. But none of that matters. You have to have a conversation with somebody to explain to them what you mean by what's on your resume. And that's how you stand out and kind of push into the industry.

I love that. And Tiffany, no worries. No worries. I'll just let you know if you want to go back and listen to the first part of it. Eric Gates and great answers. So all right, let's talk this last topic. And then we'll bounce for the day. And again, Eric, thank you for coming on. Everyone, thank you for the questions. If you have more questions, comments, add us. I mean, again, this is the time where you get a hiring manager in front of you per se to answer questions. So let's talk about getting into FANG. Breaking into FANG, breaking into Big Tech, whatever you want to call it.

What are some suggestions? Is it for everybody? Like do you have to have experience? Like just chop on that for a bit. Yeah. So I have a couple of different answers on this. One, no, it's not for everybody. I personally love it. I tend to go for the biggest, most recognized name. But once you're in, there are things that some people really love. And some people won't love so much. And I think it's really up to you to do a lot of the one on ones with people in FANG to even gauge if you want to be there. Because I know a lot of people that have come into Amazon, come into Google, Facebook, and just haven't enjoyed it.

And went back to a smaller company, because they either felt more of a kinship with the company. They felt like they were more engaged with the C-suite. That's things that people like that's a little hard to do in FANG companies. One of my biggest answers for new engineers that are looking to come into Amazon is if you are something before and you have a breadth of experience in program management, product management, something other kind of adjacent role to software engineering, it may not be a bad idea to come into your target company in that capacity and not necessarily software engineering capacity. And the reason I say that is once you're in the company, it's a lot easier to look up hiring managers, to look up software teams, to get a mentor who knows that you pass a certain hiring bar.

You're already in. We have some time. And I'm doing this right now with a business analyst that works on one of the mice, mice, stakeholder teams. He wants to be a software engineer. So working with him to build kind of a ramp plan, you know, here, try writing some of this software, try doing this thing, engage this person. And then when the time comes, it's going to go into Amazon has a technical academy for people that are beyond one year, where you go into this academy, do kind of apprenticeship and come out as an SD1. So it's cool kind of doing those activities. But coming if you can't get your target role at your target company, at least get a role at your target company, or get your target role somewhere else, build up experience and then go for your target company.

So that's kind of my one minor about how to get into FANG if you're on the outside looking in. I love that. I love that. So let's see here. Any more thoughts on FANG breaking in any more suggestions on that from that perspective, Eric? Yeah, I would probably suggest people to try. If you assume you're not qualified for a certain role, you may be wrong. Now try doesn't mean blindly. Because I don't think that really does much for anybody. I believe I blindly apply to Amazon a few times before a recruiter just got a hold of me and the stars align. But try to build up a network of people within Amazon so you can just run by them.

Here's who I am. Here's what I want to be. And then get there. I put them inside on what you need to do to wrap up to it. So I would say keep trying. Try to find higher managers with roles open. I know I'm linked in. If somebody reaches out to me, I'll be open with them about where they would fit with the role. Good. If it's not a fit, here's what you know you could try to do. Or if you're fit, you know, let's let's chat and get you into the pipeline. But build up that one on one network. And then you know, ancillary to that is building up that Muslim memory of talking to people, which is very inherent in the whole process itself.

So you said something that I want to key on and key in on and we'll finish up with this because this is this something I'm really passionate about. So you said network with hiring managers, DM hiring managers, connect with people on Amazon, build a relationship online, ask how you can get connected. So you're totally cool. If someone DM's you go, hey Eric, you know, saw your hiring, your profile pictures got the purple thingy. Like how can I apply? What are your thoughts on getting on Amazon? You would help that person. I respond to everybody. You know, I may not be for a couple days, but I respond to everybody.

You sure. I love it. You know, I mean, I'd have an answer that's too helpful, especially if somebody that's like, I've written code for a week. I want to be an SD too, but I will kind of be open with them on that. And I'll keep the dialogue going, you know, as much as I can. So I'll help anybody that that's reached not to me. Twitter, not so much. I think I don't get notified quite as much on Twitter. And I get a lot of non value ad, mayo on Twitter, but LinkedIn our sponsor. I love that. I love that. Well, everybody. Thank you all again for tuning in to guidance counselor 2.0.

Today we appreciate air, I appreciate to air. Thank you for coming on, man. Real quick. How can people best reach out to you or find you? Yeah. So I'll give my personal email address and my LinkedIn. So LinkedIn, if you find, if you just search for my first name, Eric, your I see last name, Jaeger, YAGER, I should be one of the first ones to pop up. You'll see this face all the purple thingy like Taylor said. And I think I put my MS and MBA effort. So be Eric, Jaeger, comma, MS MBA. I love that. I don't remember my actual URL. Personally, email, just hit me up first name, Eric, eric, eric, I see a dot p as in Paul dot last name, Jaeger, YAGER, and I love that.

I love it. I love it. Well, again, thanks y'all for tuning in. Go, Ken, ex, Eric. He's a wealth. He's a gem. Eric, you have a great Wednesday buddy, and I'm sure we'll talk on Twitter today. Hey, send to you. All right. Sounds good. Catch you there.