Would you like candid advice from a hiring manager about how to get that job?
The latest episode of my podcast posted this morning at 8 AM. In it I interview Dan Crews: hiring manger, principle web developer, and GraphQL architect.
Dan has an atypical background himself. Without a degree or bootcamp, he managed to rise to a position of technical leadership and become a hotly recruited expert in GraphQL.
Web Development is a frustrating profession to define. If it is mentioned in the job description you are applying for, it can still be unclear what the job really is. Listen to Dan’s take on Web Development and why it’s the only profession he can picture himself in.
We also cover how to choose what kind of company you work for first, and what Dan is looking for when he interviews junior talent.
This is season 1 episode 2 of the ManagerJS podcast for students and junior developers.
I’ll publish a transcript at ManagerJS.com before the next episode drops.
Tyler Peterson: The only thing I can promise you about becoming a web developer is that you can't predict exactly how it's going to happen for you. Today we're gonna go through the first part of an interview that I conducted with a friend and colleague of mine who's a web developer a GraphQL architect and hiring manager in Utah County. We're gonna talk about his start and his hiring practices.
Tyler Peterson: A lot of the engineers retiring today got into engineering or computer science programming through unusual paths. I once worked with a guy whose degree was in comparative literature and he was a great engineer. But his degree certainly didn't help prepare him for it. And of course I've worked with people that didn't have any degree.
Tyler Peterson: A lot of people that I've worked with had degrees but they weren't C.S. degrees they were other technical degrees and a lot of this is because when these people were getting their start C.S. wasn't even being taught in universities. So people that are trying to get into programming and web development in particular they at least have the advantage of well-designed classes and well-designed programs to help give them their start.
Tyler Peterson: So Dan Crews is a principal engineer and hiring manager in the Utah County area and he has a nontraditional start to his career. And we're just going to cover a small part of his story which is actually quite fascinating and entertaining but we're going to talk more specifically we're gonna zero in on how he got started in web development.
Tyler Peterson: I didn't know it at the time but when I was interviewing Dan he had just given notice at work. He was not dissatisfied with his job but he came across a perfect opportunity elsewhere based on his experience. And you should always be open for opportunity. And he looked at it and it felt like a good choice for him and his family. So he had just stayed late that day to talk to management about it. Because- I don't know if you've ever given notice but if you're any good when you give notice it's not unusual for people to want to double check that you are- if there's nothing they can do to get you to stick around.
Tyler Peterson: Now I don't recommend you do that as a negotiating tactic. You shouldn't give notice just to jerk people around. But if you're good people are going to not be happy to see you go and that's what- Dan is good and they weren't happy to see him go he'd stayed late. Had some tough talks and he was a bit subdued. So this isn't a completely typical view of what it's like to talk to Dan Crews but his advice is still there and his story is still very compelling.
EFFECT: [MANAGERJS THEME]
Tyler Peterson: Okay. Hey how you doing Danny.
Dan Crews: Great.
Tyler Peterson: [CHUCKLING] You're still at work.
Dan Crews: Yeah.
Tyler Peterson: It's like six o'clock on a Thursday and you're still at work.
Dan Crews: Yeah.
Tyler Peterson: Date night.
Dan Crews: It is date night and I'm sad. But CTO wanted to talk, so…
Tyler Peterson: Yeah. It's not like you get to just be like, "Sorry man. Five o'clock I'm done. Outta here.".
Dan Crews: That's right. I got to go hang out with my lady.
Tyler Peterson: Yeah. Was it at least important.
Dan Crews: Yeah it was. It was a conversation that I wanted to have with him so it was- It was nice of him to give me some time.
Tyler Peterson: Good. Cool. Well you're the first interview for this podcast. I hope to be interviewing a lot of people. I want to interview managers and students and junior developers because the thing inside of me that makes me want to do this is my experience going to career fairs at schools and getting some of the same questions over and over again and wanting to be able to give them better answers and also wanting to be able to get them better prepared for those career fairs so that they can maybe you know get to the next level of questions.
Dan Crews: Yeah.
Tyler Peterson: Does that makes sense?
Dan Crews: Yeah definitely.
Tyler Peterson: So I expect to refer people at these career fairs to do this podcast. Hey Dan you want to introduce yourself.
Dan Crews: Sure. My name's Dan Crews. I am a man of a few hats. I'm currently platform architect GraphQL architect, manager, and a software engineer at Vivint Solar.
Tyler Peterson: And you're also a standup comedian.
Dan Crews: Yeah. So for fun I've got to open microphone a few times. I'm hoping to go enough that the manager Keith will recognize me and let me open up for somebody but no not yet. One of these days.
Tyler Peterson: Yeah I've seen your clips. They're pretty darn funny. I think it's hilarious.
Dan Crews: Thanks.
Tyler Peterson: And you've been polishing your set for quite awhile now. It feels feels like it. It's definitely showing the polish. I thought it was funny the first time but it's getting even more smooth.
Dan Crews: Yeah thanks. It helps to not really be scared of people and being a manager has helped a lot with that actually.
Tyler Peterson: Yeah?
Dan Crews: Yeah like Im running a lot more meetings so I'm kind of on the stage a lot more so. Figuratively.
Tyler Peterson: After I was made a manager there were a few months of just uncomfortableness. Because as an engineer I was kind of protected. I had my teammates and I had a manager. And those are the people I had to keep happy. When I became a manager I was exposed to the entire company more or less. And you just can't keep them all happy. And learning to be OK with people not knowing who you are or knowing who you are and thinking you're annoying or thinking you're wrong. Learning to be OK with that, and just on an emotional level, not just intellectually but to just go to bed every night like, "Yeah there's people at work that aren't in awe of my awesomeness." You know that think I'm just OK so that's probably the biggest gift that being a manager has given me and it's one of the reasons why I say, I think every developer should spend some time in that environment whether it's as a manager or a senior developer, or team lead because it's very freeing when you get through that.
Dan Crews: Yeah definitely.
EFFECT: [TRANSITION MUSIC]
Tyler Peterson: I'm in the mood for something completely different. I'm in the mood for.
EFFECT: [USER JINGLE] Un-solicited endorsements and reviews.
Tyler Peterson: That's right. It's time for me to talk about something special to me without anyone asking me to. And today I am talking about
EFFECT: [THEME MUSIC]
Yeah big bonus points if you could recognize that theme music that is the theme music to the programming podcast, "Detached Head." Which, if you haven't been using the git version control system might sound very alarming but it's really just a really mundane sort of programmer pun that they've chosen to go with: detached head.
My good friend and colleague Kyle wrote the music and edits the podcast and Drew and Dewey are the main voices in that podcast (who are also friends and colleagues of mine). We have worked together in the past and Kyle and Drew still work together with me. Dewey has moved on to another company. I have always enjoyed chatting with these guys talking about shop just talking about life in general or how we think work works and how we can make it better. And I think that you'll enjoy their take as well.
I was a recent guest on their podcast. We talked about the hiring process some mistakes that candidates have made in my experience and things that bug interviewers. A lot of them are things that didn't bug me right off the bat but after doing interviews for a few years they do start to stand out as as problems and I was happy to be able to share some of my own experience with them on their podcast and because I know these guys really well and we are used to sitting down and and talking at length about things they did get me pretty candid and might have said some things that I don't regret. But they got me they got me talking kind of freely so check it out check out their podcast by going to anchor.fm/detachedhead and that detached head is all one word. I think you'll like it.
So thanks for listening to this segment of.
EFFECT: [USER JINGLE] Un-solicited endorsements and reviews..
Let's get back to Dan.
So talking about how you got into software. What got you your first real job. What was your first real job doing software.
Dan Crews: So I did customer service tech support at a web host company down in Provo. I was helping people fix their email problems because I was pretty good at things. I mean I had been doing tech support for my mom for a decade or two. So I was doing customer service and people would call in and they'd have problems with their website. I eventually got to the point where I was like, "OK well I know a little bit of CSS. Let me help you out." And then I would get in and tweak some stuff and it would go well and they'd be happy or they wouldn't and they'd have to send them up to the updates department and the wait time was two days.
Dan Crews: Eventually I got better at that and then I got really good at CSS and HTML. And at that company we had some good designers who knew a lot about design. We had some good programmers who knew a lot about PHP, but we didn't have anybody who knew how to take PHP and make it look like a design. And I was pretty good at CSS. So I started a design integration department. It was just me. And my job was to take the finished PHP that the contractors didn't want to touch and take the finished design that designers already got paid for and put them together. And I was there for probably about four years and then eventually was the lead developer there working my way up from nothing but tech support.
Tyler Peterson: So sweet. Four years there?
Dan Crews: Four years.
Tyler Peterson: Wow you did a lot more PHP than me but we both have PHP in our past.
Dan Crews: Yeah.
Tyler Peterson: It's a- I know a lot of people that hate PHP but a lot of them when you pin them down have used it and made money on it.
Tyler Peterson: Yeah. PHP is an example of that old maxim that says, "You never get fired for buying IBM." Because it got so big that you knew it could always be around. So- So while PHP might not be the best choice you don't have to worry about it just not being around some day.
Dan Crews: That's right. Yeah. I was at a conference in Las Vegas a few years ago and there was a talk by Rasmus Lerdorf who wrote PHP and I walked up to him afterwards and people were asking him like, "hey did you ever- like what's it like being the guy who wrote PHP." And he was like, "I don't know. I don't have anything to do with it anymore. I wrote it for me and people just liked it and went with it. So I guess it's pretty cool now."
Question: What would make you leave Web Development?
Tyler Peterson: What would have to be true to make you re-evaluate being in web development? What would make you go a different direction?
Dan Crews: Oof! I don't know. It's the best: web development and really this whole community as a whole. The passions that I have for creating things that my mom can look at for example. Early on especially was really big for me to say, "hey Mom! Look at this thing. You can still be proud of me." I mean, "you can start being proud of me because look at this thing that I built.".
Dan Crews: And it was built in a way that she could go look at it and she could say, "hey that's pretty cool." She didn't really understand why I was so proud of a blinking light on a web page but like being in the web is so great. And the technology is moving so fast. It's just so exciting. I don't know what else I would do. This is it. This is my jam.
Tyler Peterson: This ship would have to be sinking I guess for you to get off.
Dan Crews: Yeah. And I just don't see that happening. I mean maybe.
Tyler Peterson: Yeah. Yeah. I've looked at Web assembly. I've had people telling me, "Oh get ready to be extinct because web assembly is gonna let us Java developers take over web development.".
Dan Crews: That's right.
Tyler Peterson: And they have tried to do it before. GWT anybody?
Dan Crews: Oh man. Google Dart.
Dan Crews: Yeah.
Tyler Peterson: Have you seen other people moving out of web development?
Dan Crews: Not really. I mean I've got a few friends who just got into web development because it was what was available. Like people who just wanted to be in game development- when the last few years they really wanted to get into machine learning. People who get into embedded systems with the extra difficulty of dealing with low memory and dealing with actually physical devices and getting into the maker scene. That's really the only place I've seen it go.
Dan Crews: I've had several people tell me that desktop applications aren't dead and the fact that they said that made it feel like they were wrong. But…
Tyler Peterson: Yeah, yeah it's like, "why do you have to tell me they're not dead?".
Dan Crews: That's right. I didn't even think it. But thanks for telling me.
Tyler Peterson: Flash isn't dead either.
Dan Crews: Yeah!
Tyler Peterson: It's not dead!
Dan Crews: Yeah neither is FLEX. FLEX is going to be big.
Tyler Peterson: Flex- Flex is going to be awesome.
Question: What is web development?
Tyler Peterson: We've been talking about web development a lot and I'd like to ask you to tell me when somebody says, "what's web development?" and maybe they have some technical background- maybe a college student or a junior developer in another field says, "well what is web development? Could I do it? I don't know what it consists of."
Dan Crews: Web development is… I've often thought that I wasn't artistic- that I didn't have any creativity. But web development is my creativity. It is my art. It's translation. It's being a translator, where someone has some idea of this concept and you get to talk with that person and figure out not just what they're asking for (because they're asking for something very specific) but it's what are they really asking for. What do they want behind what their words are. And then building and creating- It's engineering this thing.
Dan Crews: I mean, most of the applications that I build- People tell me I mother hen my code just because I don't like people coming in and messing with it. Because those are- these- these are my- These are my children. These are my babies. I'm putting so much of myself into an experience for someone else. It's really sharing who I am helping someone else have a good experience. That's just the best!
Dan Crews: And I've kind of faded off from where your question is to some extent. But to me that's web development: It's building something that is available to everyone. Mobile development is valuable and it's a thing. Desktop applications are a thing and they're not dead, from what I've been told recently. But web development! You're building something that anybody can access. If you do it well then you're building something that a blind person can work with, a person on dial up networking in the Democratic Republic of Congo can get on and access it. It's. I don't know. It's just crazy that anyone could use this thing. And I'm sharing my gift with anybody who cares to look.
For Dan, Web Development includes some ability to design experiences or graphic design, not just take a finished visual/experience design and implement it.
Tyler Peterson: You talked about talking to somebody and going from them not even knowing what they want to you creating something that satisfies that need. So it sounds like for you web development includes, normally, turning requirements into the experience not just taking a finished experience from an ex- user experience designer and realizing it. But also being able to interpret that requirement and have influence on what that means. Right?
Dan Crews: That's right yeah.
Small shops can give you broader experience.
Tyler Peterson: And I know that in some big shops, if you have enough developers, the more developers you have the more specialized they're going to be. So, if you have a thousand people working in the same area then you're gonna have plenty of people that are better at design than you, because you're a coder. And so they'll probably end up taking up that space. But if you're in a smaller company then-.
Broad experience without mentoring can lead to bad habits.
Dan Crews: Yeah and one of the things that I would say: in my experience as a hiring manager at one of the things that can be a negative when I'm interviewing somebody- if someone's only been in a small environment it's hard for me to interview them just because they haven't been surrounded by people who… Like, I don't want to be the smartest person in the room. And if you take a young developer who is just starting out– young in their career I mean– and make them "the guy" they're going to learn to do things wrong. Which gets it done. And they'll get better. And that's OK. But it's hard for me coming in with them five years down the line. If they've been the person doing everything they can do everything but a lot of things are doing wrong just because they haven't had senior leadership.
Tyler Peterson: Yeah yeah. And a lot of it doesn't feel painful to them because: doing things wrong a lot of times means when this work crosses the divide it's not going to be maintainable. But because they did the whole stack, they don't even think it's weird, what they're doing. You know, they're dealing with lower level concerns in the higher layers. But because they understand the whole thing, that was small enough to fit in their head, they don't see how terrible that choice was.
Dan Crews: Yeah.
Tyler Peterson: So, I should amend my advice and say look at a shop that's small enough for you to not be pushed out of design, because they have 100 designers, but big enough for you to be working with other senior developers that can mentor you.
Dan Crews: Yeah. If you can find something that's small enough, and you have that opportunity, mentorship is going to be key. Even if you're- like, if you get into development but you're interested in UX development and exploring that space, if you can find a small enough space that you can dabble? Maybe even when you're a senior developer if you're interested in being a junior UX guy for a while be a senior developer and just try to contribute. And try to ask questions and get mentorship from people who are in that environment. I like the idea of being in a small enough shop that you can be "the guy" in your thing… eventually. When I started it was just me as a developer and I did so many things wrong.
Tyler Peterson: I can imagine. I was in that situation too.
Dan Crews: And it's hard.
Tyler Peterson: I was doing it in Perl.
Dan Crews: Oof!
Tyler Peterson: I was doing data processing for a market research company and everybody was using-
Dan Crews: Oh bless your heart!
Tyler Peterson: Everybody was using just word perfect editor and this proprietary language. And so there was a guy in the office that knew Quick Basic. And he was "the man." Like he could get anything done. And my brother told me, "hey if you're dealing with text you should learn Pearl," right? Because he was a computer science guy to. And it allowed me to be a god among men. But I was the only person and I'm sure that I did it wrong. Yeah but nobody else knew better to tell me that.
Dan Crews: Yeah that's right. And as I moved more into the programming department I kind of learned that I was a bit of an idiot. But it was OK because I was learning and I was growing. And hopefully I was fixing some of the stuff that I built early on. But a mentorship is key.
Dan Crews: But sometimes you have to start out being the only person and that's OK, too. That just means that in your next job be ready to be humble. Because you might be told that you were doing horrible things. And you have to be willing to learn. If you're the kind of person who is ready to be stubborn, start out in a bigger company. If you're- if you're ready to be humble and be teachable, be able to be a good team player, then yeah start out being the person. And that's fine. And learn everything that you can because: get experience wherever you can really. But, be careful. If you're stubborn, try to start out in a bigger company and be humbled when you're dumb. Don't try to be humbled later when you think you're smart.
Tyler Peterson: Yeah and when people are already going to say, "well… you know, he just got out of college. It's ok.". You don't- you don't want to be making those kinds of mistakes four years into your career and people wonder, "Well, how did they get this far along and not know that?"
Dan Crews: Yeah.
Tyler Peterson: Especially if you're gonna be obnoxious about it.
How to stand out.
Tyler Peterson: So you said that it was sometimes difficult to be confident when hiring somebody from a small shop. What makes a good candidate really stand out? If a college student is listening to this what could help make them stand out? Or somebody that's got a couple of years in a small shop.
Dan Crews: Well if you've got a couple of years of a small shop, as an interviewer the best thing for me and one of the red flags- Actually let me start with the red flag: One of the red flags I've found is if you're the guy in a small shop you're gonna be slower to say, "I don't know." Whereas if you've been around a bunch of people who are telling you how to do better you're usually quicker to say that you don't know.
And as an interviewer my job during that process is to get you to the phrase, "I don't know." So that I can see where you're at- where you can grow. And I'm gonna help you along the process because I'm self-taught. I recognize that the way I phrase stuff might be confusing, now that I'm into the lang- lingo. And this is where I'm going to help you along. But I need you to be able to say, "you know I'm not sure. Let's rephrase this. Let's just work through it." I'm especially interested, especially with younger people who are a little bit more junior, a little bit more green, I really just want somebody who's willing to learn. And who's going to put their all into getting it done.
Tyler Peterson: Yeah.
Dan Crews: And if someone is willing to say I don't know, that's so much easier on the senior developers on the team. Because they can jump in and say, "OK, well, what do you know and let's start from there." And you can have that conversation. And you can grow. And you can work together. Because it's so important! Because if you're just going to spin your wheels for two days you're going to get fired because I don't have time for that.
Tyler Peterson: Yeah. So, in a interview a candidate would be wise if they demonstrated that they take on assignments even when they're a little bit beyond their capability, and have a way of dealing with that lack of knowledge and overcoming it and learning what they need to know. Taking advantage of their network and getting the work done. If they can demonstrate that in an interview?
Dan Crews: Definitely. Especially when you're- I expect, if I'm interviewing for a junior or a mid-level position, I expect that you don't know the answer. And I'm ready to be your Google. Depending on what problems we're working through. Either, "k, let me see how you search for stuff. Let me see how you Google. Let's get to the solution," or, "tell me what you would google. I'll tell you what you'll find."
Tyler Peterson: Yeah I do that in my interviews pretty often, too. A lot of times I'll have them solving code on a computer and I'll say, "just go ahead: Google. It's fine." Because I want to see how they solve the problem. I don't want them to have it all memorized. It's fine.
Coaching failed candidates.
Tyler Peterson: You know if you interview somebody and they fall short and you have a moment to give them some advice, what would you say to a candidate that fell short and what in general do you say, "this is what could help get you ready?"
Dan Crews: Yeah. So it depends on the candidate. Because sometimes they'll fall short, and- I mean it really depends on the attitude. Like some people just aren't very good at receiving feedback. And while I'm talking with them for an hour, an hour and a half, I've gotten pretty good. Because I've helped them through some things. And I can usually tell if it's going to help. And if it is, it depends on the person and I try to I try to be a little empa- empath- empathetic? That one.
Tyler Peterson: Yeah.
Dan Crews: About like- Hopefully I've learned a little bit about how they learn and I can kind of say, "OK look, here's this thing. First of all…" And again, depending on the person I would either tell him this in person or not, but I would say, "look you're still a little bit green for what we're looking for. But here are some things that you struggled with and if- if you think you're really good at this tell me now. Because I may have missed something. And I can send you some homework and you can do it and just get back to me in 24 hours and see how things are." Or, "it's a little bit green here and this is a place that I think would help.".
Tyler Peterson: Yeah.
Dan Crews: But there's lots of books and sometimes I'll say, "Look the job that you are doing for- this isn't a very good fit right now. But we may have this job, or here's a position that we're planning on opening that's maybe a little bit more your speed or opening this up in a couple of months. If you're still around I'd love to chat. And here are some things…" I try to be really straightforward with where I feel like they're lacking. Whether it's testing. Whether it's just thinking out loud and having the communication aspect of it. So it depends. But I do try to give feedback if they're open to it and they don't seem like the type who will fight me on it.
Tyler Peterson: Yeah yeah.
Dan Crews: Because that's always hard.
Tyler Peterson: That's all for today. Later when I finish airing this podcast we'll talk about some war stories that I rec- that I recorded Dan sharing with me during that interview. But to keep this podcast focused on on just a couple of things we're gonna cut it short there. And I hope that you have enjoyed the podcast.
Tyler Peterson: I hope that you enjoy what you're learning. God bless you. And I look forward to working with you someday.
Tyler Peterson: Welcome to this bonus cast from manager J.S. Just within a half hour of publishing yesterday's post about Dan Crews and how he got into management and his advice to entrants, I got a question from a completely separate direction on the BYU connect hub. It was a question from a recent management graduate looking to change careers and move into development. He said that he had no formal background in C.S. And he's worried that without that formal background, or three to five years of experience it will be difficult for him to get a job in development. It seemed so on topic I just had to put a bonus here. I have his full question and my full response to him published on my ManagerJS.com blog.
Tyler Peterson: I can't get across in writing just how I feel about this. It's so heartbreaking to hear from these people. They *can* get a job. If they keep going they will succeed in getting a job. Because there's just too many jobs out there. And there's too many companies that you've never heard of that you would never think to apply to. Keep looking for jobs. Keep working your network.
Tyler Peterson: It is gonna be difficult. And without that degree: those people with degrees, those people with experience, they're jumping ahead of you in line. The key is that you're gonna have to keep looking and applying. Which is true for everybody. it's just doubly true if you're trying to fit into a job that your resume doesn't make you look right for.
Tyler Peterson: So, you're gonna have to be creative in where you're willing to work. You shouldn't work somewhere that you don't intend to work. And I mentioned that to the questioner. These networks of people are too well-connected for you to take advantage of employers and work there under false pretenses.
Tyler Peterson: That being said, it's totally normal to have a few short stints It's just if you form a pattern of working only a few months, or a year or two, over and over again eventually people aren't going to want to invest in you. Because, you want to have a great career. Well, they have problems they're trying to solve as well. Most significant problems take months and years of training, months and years of investment for you to be really working at your top efficiency and for them to be really getting the best out of you.
Tyler Peterson: So most employers, especially in a knowledge work area, they really want you to stick around for a while. You don't have to be a career employee. It's understandable that you'll work there for four, or five years and work somewhere else. But two years, three years, over and over again, it will start to stand out. So be careful about working places for a short time.
Tyler Peterson: But, when you're trying to get that experience- just like Dan Crews, he worked tech support, and now he wasn't thinking the whole time, "I'm going to turn this into a technology job." It's just he learned the skills that he was interested in and he saw problems and solved them.
Tyler Peterson: So, that's the core way that you're going to shape your career over time. You need to train yourself. You need to seek out opportunities to acquire skills. And you need to have your eyes open wherever you're working to see what problems they have that you can solve. When you can match your skills to problems that they need solved: that's the magic.
Tyler Peterson: You can more or less write your own job description. This is more likely to happen in small companies. Because, small companies can't afford to hire specialists in every field, but they will normally have tasks of every kind that need to be done.
Tyler Peterson: So be creative. Don't just think of places that you know of as a consumer. You're going to need to work the job boards. Work your network. Try to find a company you would never think about. Try to find a position that matches the skills you currently have, not just the skills you wish you were using, but the skills you currently have.
Tyler Peterson: And if it's adjacent, like it was for Dan, to technology then your trip into technology will be shorter. for example my own father he had a degree in management and never really expected to go into software. But there were problems at his work. They were best solved with software. And now at the end of his life- at the end of his job life, he's about to retire, he is an expert that is irreplaceable they're very dependent on him because of all of the software work that he's done and the expertise he's acquired.
Tyler Peterson: Your career is long. So, don't be so worried about going straight from college into a job with "developer" in its name. Acquire the skills that you're interested in, that you're good at. Build on your strengths and get a job that's well suited to what you're good at, and a company that you can believe in and that you can believe you can do some good and just search for opportunities to do the good that you can with the skills that you have. And don't get totally hung up on getting a job with "developer" in its name. Because, there's a lot of development happening outside of those formal roles.
Tyler Peterson: And the best place to switch from one job title to another is inside of a company. Because, inside of that company there are well-connected networks of people that know one another. And you can establish your ability to one person and they can transfer that trust and knowledge to another part of the company.
Tyler Peterson: That's where it's going to be easiest for you to move from one kind of a role to another.
Tyler Peterson: Don't get too hung up on where you get hired into that company. Make sure that it's a role that you can do well. And they should probably have some department, or some people doing the work that you're hoping to do. But don't worry about trying to get directly into that space. Again don't do it under false pretenses. Don't go in with no intention of doing the job you're hired for and doing it well.
Tyler Peterson: It's really tough for me to hear from these people sometimes because I really want them to be able to succeed. There is always luck in your career so there's a chance that you could get right into exactly what you want. But most likely not. Even the people with the best degrees from the best universities have to rely on luck. They just have better odds because of their background.
Tyler Peterson: Best of luck I hope you can get where you want to go. And thanks for listening. To this bonus episode.
Thank you, OP — July 12, 2019, 8:26 AM
You’re absolutely right. It can be difficult to get a development job with a mismatched background. I just published an episode today talking about how one of my friends got into development with no technical background. For him, he started in tech support and then applied his self-taught skills in solving problems when they came up. It took several years, but eventually he was the lead PHP developer. Now he is leaving for California in response to a dream development job offer that a head-hunter tracked him down for.
Getting a formal development job with your background is always a possibility, so keep trying. But it is a distant possibility given how many trained applicants can jump ahead of you in line. The crucial element is experience. Getting paid to write code will make you look better, and be better. Be willing to look far afield for your first paid coding job. In Dan’s case, it was in tech support. For many others, they take a job in their formal training but keep their eyes open for other internal needs that they can fill.
You’ll probably have greater luck pivoting from one formal role to a more development role in a smaller company. In small companies, they can’t afford to hire a specialist for every task, but they normally have tasks of every type. So a capable and eager employee can really write their own job description over time.
Of course, you should never work somewhere under false pretenses. And don’t expect to be able to completely mold your job in a matter of months. But if you add skills to your toolbox and work somewhere that needs those skills, you will eventually be using them professionally. Once you have some real practical experience, you can consider continuing your growth where you got your start, or jumping to a new company where your formal role can be more aligned with your ideal role.
Don’t accept a job anywhere with the intention of working there less than two years without making that clear. People have well connected networks and you can’t afford to burn others. And don’t create a series of jobs on your resume that are all less than three years. People will eventually see you as a career minded opportunist and be reluctant to invest in you.
I hope this is helpful to you. I can’t really tell what stuff is obvious to everyone and what is new. Academic creep.
By the way, is it alright if I use your letter in my blog? I would anonymize you, unless you would like credit for the question. It’s spooky how on-topic your question is.
Wishing you the best,
~Tyler — 9:55 AM
Hey Tyler, Thanks for getting back to me. I will check out your interview. You are welcome to use my letter if you’d wish.
OP is doing just about everything right. He has a portfolio, active GitHub, applying for jobs, seeking out mentorships. I believe he will eventually succeed. Unfortunately, there will always be luck involved.
There are things you can do to improve your odds. Getting a four year degree in a related field from a respected university isn’t nothing. If you have that, you have a head start. If you don’t, you’ll have to work and be creative to make up for it. OP is doing all that he can at this point.
Tyler: So you want to be a web developer. What's the one thing you better be able to do before the interview. That's right. Code. Welcome to Manager J.S..
Tyler: Given how important coding is and how frequently I have to give this guidance to candidates. I felt I had to start this season of Manager J.S. with this cast on learning to code.
Tyler: I've got other casts in production but if you only hear and heed one of my casts this is the one. But of course keep listening. The rest are going to be wonderful. But I'm surprised how often I have to coach people on this. It's part of the job title and yet so many candidates don't come ready to code.
Tyler: For my part the word developer in web developer means coding it means programming.
Sound Effect: Road Noise
Tyler: Like I said I give this guidance all the time but this cast has been hard for me to write. Like a half heard song it got stuck in my mind for days.
Tyler: One day on the way to work I recorded a 20 minute voice memo trying to pour out all that seems important to me on this topic. But when I was reviewing the memo I realized that it actually had the basis for several casts in it. It kept spinning out on other trains of thought related to the entire job interview process but not just how to learn to code. So I'll cover some of that other material in future podcasts but I still needed to focus in on just how do you learn to code. Something that basic.
Tyler: I realized that I had to take another approach. So I switched how I was getting to work. I moved to mass transit and instead of thinking out loud I tried writing down my thoughts.
Sound Effect: Trax train accelerating
Tyler: It was actually really helpful. I could finally start separating out some of the secondary subjects from the primary concern: How good do I have to be at coding before I start interviewing and how do I get that good.
Tyler: Well, here's the first headline: You do need to be a coder to get a coding job. As obvious as it may seem, many candidates don't realize they need to be able to code before the interview. But I can understand. I can imagine them thinking the internship is where they will learn to code. Maybe it is elsewhere. Maybe other places in their coding internships they're taking people off the street that don't know anything about how to code. But almost all of the interns I hire have already been paid to write code somewhere else before we hire them.
Effect: Spoken as if on the phone
Second Person Tyler: Ok. Tyler I get it. I have to be able to code but how am I supposed to get experience coding if you won't hire me without coding experience.
Tyler: If you haven't had a job coding it's going to be OK. You just need to bootstrap yourself. Once you've got that first real coding job, your growth is going to explode. You just need to get good enough for the first real job.
Effect: Spoken as if on the phone
Second Person Tyler: Alrighty then. You mean getting certifications and taking classes. I'll go to school or a boot camp and then I'll be able to code.
Tyler: Not entirely. I've met plenty of seniors in college or graduates from boot camps that still couldn't do well enough in the interview to become an intern which is heartbreaking. There's more to it. So right up front here's how I recommend you prepare yourself to code during your interview. These are the headlines and they're in priority order — most important idea first.
Tyler: Number one: Write everyday code every day.
Tyler: Number two: study theory and opinion.
Tyler: 3. Be prepared to demonstrate skill.
Tyler: And number four: Optional! Optionally, you can study tricky code.
Tyler: In a moment I'll explore each of those ideas in greater depth.
Tyler: Sometimes you come across something so helpful that you wish you'd heard about it years earlier. And sometimes you have that annoying friend that tells you all about those kinds of things without prompting or cause. And I'd like to be that annoying friend for a moment. It's time for unsolicited endorsements and reviews.
Tyler: Uh, Wait actually I have a jingle for that:.
USER Jingle: Un-Solicited Endorsements and Reviews!
Tyler: That's right. It's time for me to tell you about something special to me without anyone asking me to. And today I'm talking about this.
SOUND: Pages being thumbed rapidly.
Tyler: Yeah that's right. That is the sound of a big, thick, tech book that I'm never going to consult again because it covers an obsolete technology. In this case it's Expect. Which, you probably don't know about. But as the title says: a TCL based toolkit for automating interactive programs. Yeah for a laugh. You can look that up. It was a while ago I used that.
Tyler: An obsolete hard copy book is one of the saddest things. And a library full of them? Forget about it. The first personal monument to antiquated knowledge that I came across was in my first married ward. I served a proselytizing mission for the Church of Jesus Christ of Latter-day Saints, came home in 2001. And by 2003 I was a young married college student, several years into an engineering degree. And about this time I was asked to help an unemployed programmer in our congregation (or ward) with some cleanup around his house.
Tyler: I heard something about a bubble that burst a couple of years earlier. And apparently bubbles can make you unemployed when they pop. So when I went down to this guy's basement, at first I was impressed. There were shelves and shelves of books on programming. Then I realized one after another they covered old versions. So much invested in his library and now they weren't resources. They were just trophies or maybe even just boat anchors or millstones depending on how you think about it.
Tyler: And here's what I've learned: Some books will always bring you pleasure to peruse and reread and some just can't. That's why I don't buy technology books anymore. Or at least not the ones that cover a specific tool or version of a changing language. I rent my technology books with a subscription to Safari Books Online. It's from O'Reilly. And they're that book company that's always publishing new technology books but with covers that look like antique engravings of animals and people in cultural dress. I love their books but I know I'm never going to open a book for Java 6 once Java 8 is out.
Tyler: Make use of online libraries. That's my suggestion to you. Your school might have some. The ACM provides access to a selection of Safari Books Online with your membership and a student membership is particularly affordable. Even if you're not a student anymore I recommend that you find a budget to pay for that membership because it has a lot of resources. There are other services that provide access to books like books 24×7 but Safari is my favorite largely because it's O'Reilley. And I just really like O'Reilly.
Tyler: And if you do buy a tech book, like I do sometimes when Manning has an irresistible title, get it in e-book form. Much better for it to take an inconsequential amount of space in your Dropbox account than taunt you, night after night from the bookshelf in your bedroom, or office, or unfinished basement.
Tyler: So thank you for letting me get that out of my system and listening to this segment of.
USER Jingle: Un-Solicited Endorsements and Reviews.
Tyler: Ok the first two ideas (write everyday code everyday and study theory and opinion) are the most worth following because they don't just help you get the job they help prepare you to do the job.
Tyler: The last idea might help you do the job but it mostly just helps you do well in job interviews and at parties. Well coding parties I guess. Or at reviews. Uh, at conferences where there's other people that will nerd out about how to solve some complex coding issue but most of those challenge problems don't really help you do your job better. But if you are in an interview that requires you to solve one you'll be happy that you're prepared.
Tyler: So let's cover the first idea. Again the first two ideas are the most helpful because they are real preparation that counts on the job. It helps you get the job and it also helps you do the job well. Idea number one. Write everyday code every day.
Tyler: I know that's kind of cute to have the repetition of everyday code. It was originally "code everyday everyday code." So I tried to take a step back from the cute– off of the cute spectrum. It's still a little cute but hopefully it's memorable because that everyday code is important. It's what makes this first idea different from the last idea. The one that I kind of pooh poohed about doing coding challenges.
Tyler: I want you to focus on everyday code.
Tyler: I've heard it attributed to Jerry Seinfeld. I don't know if it really is Jerry Seinfeld that said this or if he said it first or if he ever said it but people say that Jerry Seinfeld says: the way that I became a great comic the way I became a great comedian is I did the thing that is hard and that is core to my profession everyday and that is write.
Tyler: It's hard to write. And so he wrote every day. He wrote jokes every day. Well you're a coder or you want to be. So you should code every day.
Tyler: And you should focus on practical applications not on CS– computer science theory– solving red black trees, or implementing a faster sort. That's all good. I think you should do it once as part of the curriculum as directed but probably not the best thing for you to be doing every day. Because when you do everyday code it prepares you in a different way.
Tyler: So what should you do for that. How do you find it. Because I think one of the reasons why people do coding challenges is that they're easier to find. You've– you go and buy a book or you sign up at a Web site and they deal out to you a challenge every day. And that's nice because. You know what you're supposed to do. And it's easy to get into a habit. But you really do need to get into the rhythms of solving the actual problems that you're going to have on the job because that's going to shine in the interview.
Tyler: So what problems should you solve. Well you should solve something that you're interested in. It doesn't have to be amazing. It should be solving a need filling a need somewhere using coding skills. So scratch an itch. Fill a need.
Tyler: Do it for free on your local host. Do it for free on your laptop because just about none of the web technologies are expensive or even pay for. Or there are a lot of free hosted options. So you don't need to pay for any of this. If you want to it's a good idea to set aside a budget– a monthly budget to pay for hosting, or to pay for resources to improve your career. Because it is your career. That is going to pay itself back. But don't get caught up on buying stuff.
Tyler: Just start coding every day. Everyday code everyday. Right.
Tyler: The reason why everyday code is going to shine so well in the interview– especially if the person interviewing you is a real practitioner and really has done the job– is that there are these well-worn parts of any technology. Parts of it that in order to get anything done you have to trod that path over and over again. And if you're ignorant of that well-worn path that's going to stand out.
Tyler: If you don't know the boiler plate. The… the bits of syntax and characters that it takes just to get anything done… Or if you're not familiar with the vexing little quirks in the API that people trip over, over and over again because they weren't quite designed perfectly, or they're designed differently in every language, then that's going to stand out. Because during the interview you're going to… you're going to show that it doesn't just come to you… that the name of that thing is misspelled or it's a method instead of an attribute, et cetera. Right?
Tyler: So solving practical problems will force you through those paths. And it'll make you better at performing in a coding interview– even better than solving game problems– unless in that interview you're actually given a game problem. In which case, hopefully you're familiar with that particular game problem, or you've just done enough coding and you're familiar enough with it that you genuinely solve the problem. Which would be ideal– is that you actually are good enough at coding to solve that game problem that they gave in the coding interview.
Tyler: Personally I don't use complicated game-like problems. I use everyday problems in my coding interviews because I think that's more representative of the work you're going to do on the job. And I also find that it still separates the wheat from the chaff pretty effectively.
Tyler: So that's that, right? Everyday code every day.
Tyler: Idea Number Two: study theory and opinion.
Tyler: So in addition to coding every day you really do need to read. And you need to read more than just the minimal docs to solve the problem.
Tyler: And that's one of the reasons why writing everyday code every day is so powerful: because, it will force you to look up the answers to problems that you run into. Problems that you won't look up if you're just doing toy problems– especially toy problems in a sandbox. Because a lot of times, those sandboxes have bumpers on them that protect you from the mundane everyday problems that pop up when you're trying to use technology to solve problems. So you need to read more than just that bit of documentation. The great thing about everyday code is that it forces you to at least familiarize yourself with the documentation for whatever major technologies you're using so that you can get up and running. But you have to do more than just read documentation for the technology.
Tyler: You also do need to familiarize yourself with the theory and with the prevailing winds in the industry.
Tyler: So you need to do it all the time not just for some class not just as assigned in class. You need to have your feelers out to identify things that seem useful and learn about them.
Tyler: And don't despair if it's hard. Some ideas take time. For example, raise your hand if learning to code has ever made you sick.
Tyler: I know I can't see your hands but I expect that anybody that's seriously tried to solve problems with code has gotten sick on code. The first time I made myself sick studying computer science was the summer after graduating from high school.
Tyler: I was lucky. I had a brother that was in the computer science program and he was two years ahead of me. So he identified a text book that would help prepare me for my first semester at school.
Tyler: So I took that to my garbage job where I was doing account management for a credit card and taking inbound calls with questions about their accounts. And I took that book with me and read it on every break, every lunch. Read it while I was waiting for my ride home. And frankly it was fascinating and painful.
Tyler: It made me feel slightly nauseous that if I read it long enough. And the ideas would just stick in my head and my mind wouldn't– it would refuse to stop thinking about it, until it would just wear rut in my mind. And make me feel physically ill.
Tyler: It was Object Oriented Programming. The metaphors were so plain– they seemed to make sense. But turning that into a real understanding of how Object Oriented Object Oriented Programming could be used to solve a problem? That was hard. It was slow. It was painful. But it was so helpful that I had exposed myself to that information before I started my first class.
Tyler: I found that when I would learn things in class now because there were already these little footholds in my mind it just was much easier to learn. And it wasn't because I had learned all of the content that I ended up studying. It was just that my mind had been exposed to it before and it was prepared to absorb more knowledge in that realm.
Tyler: I made myself sick in college studying a lot of things and almost none of it, after that, was something that was part of the curriculum. Instead it was just something that I would learn about and it would fascinate me. And I would read up on it.
Tyler: So I made myself sick studying XML on my own. It was such an alluring idea: self documenting, or self describing, data. It was so promising. And it would be many years. And some of it in XSLT or XML styling- style sheet language tool– transforms… It doesn't matter. If you know it XSLT is you're with me. Your feeling it. It's a purgatory. It was several years in that purgatory before I understood how much more complicated the problem was– how much bigger it was than just coming up with a syntax for describing data.
Tyler: Nevertheless I made myself sick trying to figure it out and there's a really cool article in the ACM, Communications of the ACM called XML Fever. If you've got a subscription look it up. It's pretty funny.
Tyler: The next thing that made me sick was UML: universal modeling language. It was so promising. Again a good diagram– It does so much to make an idea accessible. Unfortunately learning the visual syntax of a diagramming convention is one thing. Learning to make a good diagram is vastly more difficult.
Tyler: It takes time. You need multiple exposures. You need to study it. Try to use it. Study it again– right away, or years later. But with every turning of that crank you learn more. You get closer to telling apart what is sexy from what is powerful. Don't despair if you don't understand it all the first time you read the article, or the first time you're exposed to a concept or a tool.
Tyler: I had a really great statistics professor named Professor Tolley and he said, you know you guys– And he was just speaking to the to the class because he knew it was a difficult class. He says, if you don't get a good grade in this class don't despair. It doesn't mean that you can't learn statistics. It just means that you couldn't learn sta-, you couldn't learn statistics in the amount of time allotted for this class. Try again. You guys are lucky because if you don't learn it you'll get a bad grade and you can just take it again and that will replace it on your transcript. You can learn this. It's not like when I was going to school. And if you got a bad grade they would ship you over to Vietnam because you had to drop out of college.
Tyler: And it was meant to be comforting. But it really wasn't at the time. I was pretty obsessed with my grades and the idea of being ok with a bad grade really just wasn't acceptable. But it really is a good point that you shouldn't despair if you don't understand something in a certain timeframe.
Tyler: You should give yourself a break. You should come back to it. You should keep trying. You're going to make it. It'll get better every time. And these concepts really are hard. They are difficult learning to program is hard. And a lot of people that can do it can't remember how hard it was but it was hard.
Tyler: I had an intern once that got hit by a car and he survived but he got a head injury. And he was fine for the most part but he had enough brain damage… I don't like that term. It makes it sound like he was… brain damaged. But he had some sort of trauma to his brain that the doctor said, you can't-, you can't go to work anymore. You can't program anymore. You need to not program and you need to take a semester or two off from college because your brain needs to heal and it can't do it while you're you're using it that heavily.
Tyler: And I thought that was really cool. I mean, sad that he got hurt. But it was an interesting insight that the doctor would proscribe thinking. Because it is hard work. And your brain is like a muscle. It will get stronger if you use it and it will definitely atrophy if you don't. So don't give up. It's work. Learning is work.
Tyler: To learn more about this you should read Daniel Kahneman's book Thinking, Fast and Slow. He has a fascinating section where he talks about how they could quantify the amount of work that a mental task was by measuring the dilation of pupils. They would ask people to perform math problems. And simple ones were clearly different from complex ones because the pupil would… I don't remember if would dilate or constrict but it would visibly change. And it would change in a way that was well correlated with the difficulty of the problems.
Tyler: And that's because your brain really does take energy to run. It is hard. So give yourself a break.
Tyler: I know I said that a lot of times. But I've met so many young people that took one class in high school or they took one class in college and they said, oh it was a lot- It was just so hard I can't figure it out.
Tyler: Maybe something else is right for you. But don't give up just because one class was hard.
Tyler: I was lucky because I had read that book before I took my first class. And it was so helpful. Because I had all of that pain of being first exposed to the weirdness of the way that programmers think– I got that in the summer. And I could do it at my own pace. And when I got in class it was just fun. But- and I'm, I'm, I'm a pretty good programmer. Pretty smart guy. It wasn't just easy. It didn't just come to me. It took work. So don't be afraid of work. Don't feel bad if you don't understand the first time. So that's all about study theory and opinion.
Tyler: So how can you go about finding the theory. Well obviously if you're a student you should go to class. If you're a professional you're already on the job: pay attention to principles that seem to guide decisions at work. Like Big O or principles of optimization.
Tyler: Pay attention to what comes up: coupling, cohesion. Pay attention to what's being spoken of. And look up some articles on that topic.
Tyler: You should get some classic textbooks. You should have them and you should at least flip through them and read the headings so that you can know what the- what that text book's view of the body of knowledge was. Because those keywords– that understanding of the shape of the landscape is going to help you understand conversations that are going on. And it'll help you know how to search when something becomes important.
Tyler: So just knowing keywords is so important. Without keywords you don't know what to google. And that may sound too trite. That may sound like it we're not taking our job seriously because we're going to google the answer. But honestly you do spend a lot of time looking up stuff using search engines or documentation and if you don't know the terms you're still not going to find it.
Tyler: So get a text- get a classic textbook. You could read a syllabus. Ask a friend. Ask Google.
Tyler: Computer science or I.T. training is worthwhile. I've had coworkers that didn't have it and did just fine. But some bits of the practice will elude you until you learn the theory. It will show that you don't have that depth. It won't show every day. But it is going to be apparent to those that understand.
Tyler: And that doesn't mean that if you don't have the degree you can't possibly succeed. But if you don't have the degree you should be trying to make up that difference. You should be paying attention to what principles are brought up by the other senior engineers and go and do your study. Study up on it.
Tyler: How about for studying opinion trends. You should have a variety of curated feeds- curated sources of articles that you look at. Probably on a daily basis. At least several times a week. OK?
Tyler: It's not because you have to stay that up to date on the trends, but because you just need to have a habit. It shouldn't be something you do every three weeks or every other week. It should be something that you do routinely and by routinely I mean on any given day you're likely to do it, right? That's why you need to do it that often. It's not because something is- some landslide change is going to happen in the tech industry and if you don't find out about it for 72 hours you're gonna be sunk. That's not why.
Tyler: So on these feeds you need to at least read the headlines. You need to read those headlines so that you can learn keywords. Read it. Click in. Read the articles.
Tyler: Be smart about the way you spend your time. Not all of the content is of equal value. Learn how to skim. Learn how to to determine the structure of the- of that article– see if the most important thing is at the top. If it's at the bottom because they're holding back… Just get what you need to out of each article. The more you read the more it'll become apparent how to do that.
Tyler: So get into a habit of reading those articles and don't let it wear you down. Declare bankruptcy often. It's better to have more input than you can possibly completely consume than to prune your sources of insight just so that you can read them entirely.
Tyler: There's gonna be some things that you'll want to read every article in that newsletter every time but not likely. It's more likely that you're going to read two articles here, the first half of that article in a different newsletter, and the others you just read all of their headlines– that you can pay attention to how frequently they're mentioning a different technology and what sort of connections are being made between the different technologies.
Tyler: So sign up for these sources. Sign up for book offers from reputable publishers. Sign up for their newsletters. So I'm thinking like I said Packt, O'Reilly, Smashing Magazine, Manning, Addison Wesley… Get on their mailing list. And you don't have to read the whole thing but at least skim it every time it comes in. It'll take you two seconds a day.
Tyler: There's also tool vendors that will have good newsletters. I've particularly liked GitPrime's newsletter G-I-T-P-R-I-M-E. Sentry has a good newsletter. There's independent newsletters and conferences like Dev Digest, or no fluff just stuff.
Tyler: And of course you should really think about getting membership in a professional association like the ACM. The ACM gives you access to curated collections of training material– both courses and books. So that is a goldmine for especially fundamentals and the center of mass for the entire industry. It can be a bit behind on web development itself but it's good for foundational material. And as a side note I myself have found that the ACM is a better value for the money and more relevant than the IEEE because my degree was in computer engineering and it qualified me to be a member of both for some time and I just found that I was always using stuff from the ACM. Not so often from the IEEE.
Tyler: OK so those are the first two ideas and those help you do the job and they help you be prepared for the interview.
Tyler: Now let's talk about a couple of things that really just help you be prepared for the interview. The first one is be prepared to demonstrate skill. And this is important.
Tyler: Recognize that they're not going to just read your resumé or read your course listing and say, oh clearly they know how to do it because they they've taken a class.
Tyler: No, you need to be prepared to demonstrate skill in the relevant technologies. So read the job description. Use the headline technology from the job description, or technologies, for a few hours within the days before the interview. Preferably the day of or the day before. And don't ask me to just trust you, or even your references, that you did it once and I'm sorry I can't remember anything about it.
Tyler: Finally, the last idea: Optionally you can study tricky code. You can go and do challenge Web sites like Code Wars or hacker rank. But I think that games are less helpful than coding everyday code everyday. I prefer study and practical applications to these sorts of cracking the code interview books where you've got those curated little chestnuts– the difficult little problems.
Tyler: You should- you should be aware of them. And it's not a waste of time to do them. But I don't think it should be your primary form of preparation.
Tyler: So, to repeat: you number one need to write everyday code every day.
Tyler: You need to study theory and opinion and you should be doing that about every day.
Tyler: You need to be prepared to demonstrate skill by refreshing your skills within 24 hours of your interview.
Tyler: And finally you can optionally study tricky code in dedicated cracking the interview books or coding games websites. But that's the least important thing in my opinion.
Tyler: Well that's it! That is how I would recommend that you learn to code. There's a lot more where that came from. But if I limit myself to just how do I encourage intern applicants to learn to code, that's what I tell them.
Tyler: I'm Tyler Peterson, this is Manager J.S. I hope you enjoy what you're learning. God bless you and I look forward to working with you someday.
The latest episode of my podcast posted this morning at 8 AM. I give four suggestions to help you be adequately prepared for your first technical job interview. This is the guidance I’ve given to hundreds of applicants when recruiting on college campuses.
This is season 1 episode 1 of the ManagerJS podcast for students and junior web developers.
I’ll publish a transcript of the podcast at ManagerJS.com before the next episode drops.
I’ve been working on this new podcast for a long time. ManagerJS has always been about helping students and web developers be successful professionals. Learn more about the format and content you can expect from the new ManagerJS podcastby listening to the trailer or reading its transcript below.
How do you become a successful coding professional? I can help you. I’ve been a professional coder since 2003 and in 2013 moved into management. Now I work with and hire web developers to work in an established technology company on Utah’s Silicon Slopes, in Lehi. I interview about 50 candidates each year, from students to senior engineers. It has taken me years to develop my system for identifying the best candidates. And my team is awesome! I recruit in colleges up and down the Wasatch front. From Brigham Young University in Provo to BYU-Idaho in Rexburg and colleges in between: the University of Utah, UVU, Utah State, Weber. I meet hundreds of students at career fairs, each year. I love being a part of their first steps in their careers. Interviews and fair booths are fine, but my favorite part of recruiting trips are the last half of classroom visits or information sessions. Introductions are out of the way. We’ve covered the details of the job and general information. Now people start asking fun questions, and if they ask right– they uncover really fun stories and wisdom from the recruiting team. That’s what you can expect here: candid advice, and stories that stand out—from other hiring managers, current developers, students, and myself. Sometimes it will be in interview format — I will record a conversation and present it here for you. Sometimes it will be a confessional from myself based on past experiences — some of them recent, some of them years past. Always the goal is to present the candid view of what it is really like to be a professional. And what it takes to be successful. I’m Tyler Peterson, this is ManagerJS. I hope you enjoy what you’re learning. God bless. And I look forward to working with you someday.
My wife, Ann, has recently gone back to school. There is a university in Idaho (Brigham Young University Idaho or BYUI) with an incredible distance learning program. It is designed for adults who wonder if maybe it is time to get their degree.
Ann started college when she was 19. She didn’t finish. Not having a degree has never been a clear problem for her. It probably never would be. That made it difficult for her to decide to go back. College is expensive. It is time consuming. It is much more difficult to go back as an adult. Why bother now?
Why invest in learning when you don’t seem to need it?
Today’s summary from Disciplined Dreaming gets beyond the fool’s choice between following rules and being creative. It’s a fools choice because you really need to do both. I’ve seen many promising, ambitious web developers accidentally sabotage themselves by holding too tightly to one or the other.
I was struck by the sound advice from Disciplined Dreaming. A model for achieving breakout creativity without being branded a heretic and losing influence.
Remember how the free summaries work: ReadItFor.Me has a library of hundreds of book summaries. I share one at a time for free at https://readitfor.me/ManagerJS. If you take too long to follow the link, I’ll have changed it to the next free summary. Contact me if you really want an old summary and I might work out a free coaching account with you to give you access to custom summaries.
No Profit For Me
ManagerJS provides free resources to web developers. The only way I could share free ReadItFor.Me summaries with you was to join their affiliate program. I donate any profit to the LDS Philanthropies Humanitarian Aid Fund.