The Scrimba Podcast

Ian Douglas (00:00):
You need to be open-minded about how a company does things and operates. What you learn in school or your bootcamp at Scrimba, how you actually do the job once you get into a company could be different. And being open to, "Oh, that's how we do it here. Okay," as opposed to, "Wait, that's not the way I learned it. I can't do it that way." Having that growth mindset is really important.

Alex Booker (00:21):
Hello and welcome to a special episode of The Scrimba Podcast. Now, ordinarily on the pod, I interview developers about their experience learning to code and building a lucrative career in tech. We're doing things a little bit differently today. In this unique episode, I invite one of the most experienced devs and mentors I know to teach how to successfully onboard at a technology company and make a great impression on everyone around you.

(00:48):
His name is Ian Douglas and he's my first repeat guest on the podcast. With 27 years of professional experience under his belt and a penchant for teaching juniors, Ian is the perfect person to explain how to make an impact in your first 90 days at a new company. Jan, the producer is here as well.

Jan Arsenovic (01:07):
Hello.

Alex Booker (01:08):
Hey, Jan.

Jan Arsenovic (01:09):
Using my producer voice.

Alex Booker (01:10):
Jan's going to help us thread the tips together to make this episode as easy to process as possible. The aim here, of course, is to create a mega resource of actionable tactics that you can use to get ahead in your new role when you receive your next job offer.

(01:26):
At the same time, if you're still learning to code or maybe gearing up to apply or interview at companies, this is still a great episode to listen to because it's going to give you a sense of what to look out for and in turn, a vocabulary that you can use to ask probing and thoughtful questions during a job interview.

(01:44):
You are listening to The Scrimba Podcast. Let's get into it. All right. So Ian, welcome back to The Scrimba Podcast. It's so nice to have you.

Ian Douglas (01:54):
Hey, Alex. Thanks for having me back. I appreciate it.

Alex Booker (01:56):
You are actually the first ever repeat guest on The Scrimba Podcast.

Ian Douglas (02:01):
Wow.

Alex Booker (02:02):
Which I think can only be a testament to the great advice you shared last time. Maybe you can quickly remind everyone about your experience in development and just how long you've been at it professionally.

Ian Douglas (02:13):
I've been at it a really long time. This past April, celebrated 27 years professionally in the industry.

Alex Booker (02:20):
Congrats.

Ian Douglas (02:20):
Mostly in backend engineering, working with scalability and architecture, certainly starting out as entry level developer, working your way up into senior developer, working into architect type of roles. I've also been in management as well. I've held a couple of management roles, a couple of director level roles, done lots of hiring, lots of interviewing. I've been a professional independent interviewer for companies for, gosh, seven years now. I do lots of mock interviews with people to help them get ready for jobs. I do live-streaming around career prep and live programming and things like that just for the sake of education.

Alex Booker (02:55):
And where are you working today?

Ian Douglas (02:56):
Right now I'm doing developer relations work for Postman. It's an API platform that a lot of developers are using. And I've been having a great time. I've been there about a year and a half now and really love it there.

Alex Booker (03:07):
I really thoroughly enjoyed our conversation last time. It was one of those where we schedule, I think an hour for the interview, but I still had a list full of questions. I'm sure we could have kept talking. And we'll just touch on this briefly because anyone listening is welcome to go back and listen to the previous episode, but I remember at the time, you were taking a bits of time to find your next role and you were being very deliberate about it, often publishing to LinkedIn, telling little stories about your various experiences interviewing at new companies.

(03:37):
And you were almost sharing, I feel like, your own pipeline as to how many companies you applied to, which of those turned into interviews and then final interviews and then offers. I was just fascinated by the transparent process. Are you still posting on LinkedIn as much as you were back then?

Ian Douglas (03:52):
Not as much as I did back then. And I think a lot of my motivation for posting that was to tell people you're not alone in this. Even senior developers get ghosted. They don't get the calls back that you would expect, or sometimes interviews don't go well, or sometimes you talk to a company and you find out they've got 10 interviews in their process. It's like, "What's going on over there that you need that many interviews to make a decision?" So I just wanted some transparency around this is what happens even to people that have been in the industry a long time, who have a lot of varied experience where it could be in demand with a lot of companies.

(04:25):
In the end, I interviewed with close to 30 companies and had 6 job offers to choose from. But through the process of that, just figuring out myself, what kind of job do I want? Do I want this kind of role, that kind of role, this size of company, what kind of company? So yeah, there was a lot going into that and I just wanted to be really transparent about my own journey to really help people know you're not alone in this.

Alex Booker (04:46):
That's the thing, isn't it? Even after so many years in the industry, there's still a bit of work to fine-tune which opportunity is not just right for you but right for you at the current stage of your career. It'd be kind of wild if you were a new developer and you came out the gates with this perfect clarity about what it is exactly you want to do, and not only that, but once you arrived there, you find it was actually perfect. That must be a really rare thing to encounter.

Ian Douglas (05:10):
It's almost never what you think once you get into it. The job interview is a lot like the dating life, of course, I've been out of the dating life for quite a while as well, but everybody puts on their perfect happy face and everything seems glamorous and glorious until you get into the job and you realize like, "Oh, this isn't quite what I thought it was going to be."

(05:27):
Sometimes though, you do land in a job where you're like, "This is exactly what I wanted. This is exactly where I needed to be in my career," or, "This is exactly what I had hoped for." Not just the fact that you're getting a paycheck, but that you're satisfied in the work that you're doing, that you're happy about the people you're working with and so on.

Alex Booker (05:42):
I've interviewed people on the pod who took what they described as an in-between job that turned out to be their dream job. Or they took something not fully knowing what to expect, and then it turned out that even though it wasn't a prestigious company that everybody had heard of, maybe they were originally striving for the people and the culture and the values and the customers and the work, they were all perfect. And so it turns out the thing maybe they were looking for initially didn't matter as much.

(06:09):
But here's the thing, you don't really know what you're going to get until you get there. I feel like that's quite a good segue into our subject today, which is onboarding as a new developer. After speaking to some new developers and some experiences myself, I realized just how challenging joining a new company can be.

(06:29):
We know it's hard to learn to code. We know it's hard to succeed at the job interview, but joining a new company can still be really scary probably because it's a high-stakes situation, will you pass the probation period? Can you learn everything there is to learn? Will you like it there? Will they like you there? And are you performing well in line with the expectations of your manager and the team?

(06:52):
So I thought, okay, I have some experiences, but I need a veteran over here, someone like yourself, Ian, to talk a little bit about your experiences onboarding at companies and what we can relay to new developers.

(07:05):
I hope that someone listening today, if they're learning to code, you can get a bit ahead of the game, maybe anticipate what's to come and incorporate that into your learning plan. Maybe you learn something today you can start working on or keep an eye on ahead of your interviews.

(07:18):
But also, I hope that you come back to this episode so when you get a job, when you sign the offer and you're ready to onboard and get started, you can come back to this episode where Ian and I are going to talk about onboarding and our top tips for someone onboarding at a new company.

(07:38):
In my experience, the onboarding process is usually a 90-day period broken into 30, 60, and 90 day milestones where you as a new joiner are going to learn about the company, the technology, the company's mission, and you're going to integrate with the team both functionally, as in you'll get up to speed doing the work, but also culturally. So you'll learn what everybody's doing, how to get on with them, some of the unspoken rules as well as some of the procedures like recurring meetings for example.

(08:06):
It could be a little bit different in North America, but in Europe this 90-day window is also usually a type of probation period where you can be let go on a shorter notice. So maybe during the first 90 days it's a two-week notice period, and then after 90 days it's a one-month notice period. This is another reason why joining a new company can be scary, especially if you're leaving a previously comfortable job.

(08:29):
And the reason I felt like it was a good segue is because it is in my view, an extended type of job interview. If you pass the interview process, then it's very likely that you will be successful in the role and they obviously believe in you.

(08:41):
I think much more people pass probation than fail it, but ultimately this is where you really get to see how the sausage is made and how good of a fit you will be at the company. And that comes from both sides, what you think of them, what they think of you.

Ian Douglas (08:54):
Depending on the size of the company and the culture of the company, sometimes that onboarding is not quite as formal. A lot of companies will have expectations about when they hope you're going to start contributing. The more senior you are in your career, the sooner they're going to hope you're going to contribute.

(09:11):
I've been at companies where they expect you to be writing code on the first day, which means you're very quickly thrust into, "Here's a laptop. Here's your environment. Get set up. Here's a bug that we need you to fix right now. Hurry up."

(09:23):
Other companies that I've been at, your first day is just paperwork of get all your agreements and contracts and non-disclosures and all your human resources paperwork taken care of and set up the banking and so on for your paychecks, and sometimes that can take almost a full day.

(09:41):
So it really varies from company to company. I would say many of the startups that I've worked at in my career have felt very rushed like, "Okay, quick, how can you contribute?" because that's how smaller companies tend to be.

(09:56):
Some smaller companies though, if the people at the company have an extensive background, they understand, oh, there needs to be a more formal, not ease you into the job, but make it a process of here's some step-by-step instructions on how to get set up. Here are the first few people that you need to talk to about the architecture and what you're going to get into. Or maybe they have a buddy system where you pair up with someone for a period of time to answer questions. Some companies though, they're just like, "All right, let's go introduce you to the 15 people on the team and hope you remember their names." And it starts very quickly.

(10:33):
Now, as far as a probationary period, a lot of areas in the United States are what we call at-will employment, which means they can let you go at any time for any reason or no reason with or without notice, the same way that you can also leave the company without any notice. You can just say today's my last day and walk out the door. It's generally discouraged to do that unless something really bad happens.

(10:56):
But the idea of that 90-day probationary period, it still can be a thing in the United States. I have seen companies where they will hire you as a contractor for 90 days and then say, "After that 90 days, now we'll bring you on as a full-time employee." That's also becoming a little less rare.

(11:11):
But it does cost the company a fair bit of money for benefits and all the HR paperwork and so on that I mentioned to get all that kind of stuff set up and get accounts set up on various platforms and things like that. They have to start paying for all that stuff right away.

(11:25):
And so some companies want to take a less expensive route where it's like, "You know what? We're going to pay you as a contractor where you pay your own taxes for a period of time and then if that works out, then we'll convert you to a full-time employee."

(11:36):
And so I've seen contract-to-hire type of roles that will last three months to six months. It really depends on the company and the culture of the company. A lot of places will just hire you full-time right away understanding that it's at-will employment, that at any point they could just say, "Hey, this isn't working out. We're going to let you go."

Alex Booker (11:55):
Wow. As a European, it sounds like the Wild West over there. It's hard to really imagine. I think you're spot on, of course, this 90-day period and the checkpoints, I think that's often an aspiration for startups and bigger companies, but providing a fantastic onboarding experience is a really dedicated effort. And in a startup a lot of the time, they're very much focused on being scrappy and putting out fires and taking the product to markets and working with partners.

(12:23):
And frankly, it's not until you reach a sufficient headcount that the startup hires somebody, for example, in HR that might take some ownership over this process. And I think this is a great point to make clear, there's certainly no expectation that you'll get such a clear framework.

(12:39):
I think it's a good thing because I think the key possibly to joining a company successfully is really making sure that you understand the expectation of you and having that dedicated check-in points allows you an opportunity to check in with your manager and company. But there's no reason you couldn't do that without such a formal framework.

Ian Douglas (12:58):
Yeah, and one piece of advice that I like to give people is ask how frequently you can meet for feedback. Not so much like, am I doing a good job, as far as working towards a raise or anything like that, but just to be able to set those expectations in the first place because how are you going to meet the expectations if you don't know what those expectations are?

(13:17):
But also just to follow up with leadership and management around, am I onboarding at the pace that you expected me to? Is there anything extra that I could be doing or am I doing enough? How am I doing in your eyes, I think is an important kind of check-in to have where you don't have to wait for a 30 day or 60 day. It can be just informal conversation and just say, "Can I meet with you every two weeks just to see how are we going? Are there milestones that you want me to meet by a certain date and time?"

(13:47):
The sooner you know that, the faster you can correct things so that you're not surprised by, "Hey, you know what? You're not meeting our expectations, so today's your last day," or something like that. Having those conversations early and often I think is really important.

Alex Booker (13:59):
Do you think that there are high expectations of newer developers during the onboarding period?

Ian Douglas (14:06):
I would say most companies are going to have an expectation that you're going to be learning a lot in your first probably six months. Yes, they are going to expect that you're going to contribute, they are going to expect that you're going to learn quickly, but that you're not necessarily going to be fully independent for a period of time.

(14:24):
And again, that period of time is going to differ from company to company and the newer you are in your career, the more forgiving they're going to be about mistakes that you make as long as you're not trying to hide them, if you're like, "Oops, I dropped a database," or something like that. But chances are pretty good they're not giving you that level of access anyway, so those kinds of mistakes are not likely to happen.

(14:43):
But I think there's a lot more leeway and forgiveness for newer developers in their career for sure, as well as just new developers within a company. Even senior developers are given some amount of leeway early on in the job. It's like, "Okay. Well, you've only been here for two or three weeks. You didn't know that that's how we do a thing." Six months down the road, it's like, "Okay, you should have known by now that that's not how we do this."

(15:05):
But when you're new in your career and you don't even understand the process and you don't understand all of the ways that they need to do certain things or that you need code reviews or you're supposed to write software tests in a particular way, they're a lot more forgiving about that too, to work with you and coach you through those.

Jan Arsenovic (15:22):
Tip number one, don't rush your onboarding.

Alex Booker (15:27):
I think when you join a new company, there is a hell of a lot to learn from the different people, their names, their roles, their responsibilities, the org chart and how they relate to each other as well as cross-functional teams, what projects people are working on, the history behind those projects.

(15:45):
Then you add to that possibly, especially in a bigger company, not necessarily in a startup or a smaller company, but sometimes you'll come across an internal wiki of sorts, which could be tens if not hundreds, maybe even thousands of pages in a big organizations of information about the company such as the history, missions and objectives and things like that, KPIs potentially, but also maybe some historical things that are important to understand, to realize why the company is where they are now and where they're going. It's all just a lot.

(16:14):
And at the same time, you might feel this pressure to start contributing and earning your nuts, so to speak, right? You want to be delivering value in some way. How, Ian, would you suggest finding a balance between learning about the company and finding your feet?

Ian Douglas (16:30):
I think a lot of the company culture you can learn over time where the technical skills, they're probably going to want you to pick up on those much sooner because again, there's an expectation of how soon you're going to contribute to the company and to the progress of what your team is trying to build. I think the culture side of it can come a little slower where the technical aspect and the team culture, like how you're getting on with your teammates, I think that's more important to happen faster.

(16:58):
There is certainly an enormous pressure, sometimes just our own internal pressure that we put on ourselves of, "Gosh, I feel like I'm not contributing enough. I'm not writing enough code," or, "I'm not even writing code yet," because you're in this constant learning state. Like you say, there might be a lot of documentation or there might be no documentation and you just feel overwhelmed because you don't even know where to look for things.

(17:19):
Don't feel like you need to rush the onboarding. Don't feel like you have to contribute day one. Just being there and asking questions and being part of the team and learning, that is contributing because that is part of your growth as a developer within the company. Whether you're a junior developer, whether you're a seasoned veteran developer, it doesn't matter, there's a lot to learn.

(17:40):
And I think it's important that you take your time to really understand things, really study things and really understand who do I talk to about certain aspects of a system or who do I talk to about this or that? That's probably the most important part, understanding who do I go to for help?Being able to ask for help I think is important too. You shouldn't be made to feel like you have to do it alone. You're part of a team.

(18:06):
Even in smaller companies and smaller startups where there are fewer people in the engineering department, I think it's still important that they take the time to make sure that you are adequately trained and equipped with the time needed to properly onboard. That way you're not making mistakes as often or you're not repeating the mistakes, as you say, that you know who to go talk to, that you can get coaching and mentorship and so on.

Alex Booker (18:31):
I think when you're more mid-level or senior, there's perhaps a greater expectation around your resourcefulness and your ability to hit the ground running or at least find information when you need it because the alternative to that is you potentially being a drain on someone else or maybe just not being too proactive, like having someone always delegate to you or hold your hand to complete tasks.

(18:52):
But as a brand new developer, especially hired under the premise that you're still a learner essentially, there should absolutely be that support and those frameworks in place, I think. I would actually argue that during the interview process, this is something you should be evaluating in the company because if you're a brand new developer and you get there and there's no real help available, that's probably not that great for your career in the long term.

Ian Douglas (19:13):
Yeah, and to use the word that you used, if you're made to feel like you are a drain on someone, then that's a sign of bad company culture, "Oh, Alex is asking me questions again?" It's like, "Well, yeah, Alex is new. Alex is supposed to be asking questions. That's Alex's job at this point."

(19:29):
So again, that probationary period can also be you evaluating the company to go, "This is not the role or not the environment where I'm going to thrive. I'm made to feel guilty about asking questions. That's not a healthy environment to work in."

Alex Booker (19:42):
I think that's a very pertinent point. What you should be demonstrating I think from the beginning is trajectory and progress, because even if you're not quite where you need to be, it's very good to demonstrate that you're further along this week than you were the week before in one way or another and asking questions is the surest way to guarantee that progress as a starting point. Of course, then you're going to read and get involved and join meetings and things. But I think that's fantastic advice.

Ian Douglas (20:08):
And to be fair, it's not that that first month you're not going to be contributing in a meaningful way as far as writing code, but I think just making sure that everybody has the expectation that you're there to learn and you're there to grow and you're going to be asking lots of questions, I think is an important evaluation and expectation for everyone to understand.

Alex Booker (20:27):
Absolutely. The easiest way for me to talk about this, I think, is also the most vulnerable way because it's just easiest to talk about my experiences and some of the mistakes I've made, and it basically comes down to going too fast. When you type really fast, you end up making more typos and you have to go back and correct them? It's a little bit like that with onboarding.

(20:47):
Oftentimes there is quite a lot of information or resources available for you to work from, yet you might have this determination to move forward quickly, at which point you end up making typos in a sense, right? My point ultimately is that sometimes it's better to slow down to speed up and by using the permission you have to take more time initially to read through docs, get to know people, and onboard truly, you will actually reach the point you want to reach a bit quicker, I think.

(21:13):
I've certainly been guilty of that before, my ambition causing me to move slower, almost counterintuitively. In that same vein, another thing that can be tempting, I think, is to put your head down a bit too much and focus only on a goal like delivering your first feature or getting your first PR accepted. And when you're putting your head down, what you're not doing is engaging with people at the company.

(21:37):
Now of course, there are going to be some meetings, for example, a standup, and there are going to be meetings around projects, and of course when you're brand new, people will take a bit of time, I think, to say hello and just do a quick intro. But in a busy company, those meetings have usually been scheduled to achieve some kind of objective, and so it might not be so informal to get to know people.

(21:55):
And frankly, you might not get any help with that. I've gone into a company and felt like, "Oh, as a new joiner, it'd be really nice if everybody introduced themselves and showed some interest and got to know me and learned about my experience." It's important, I think, in that situation that you take control and you make the proactive effort to reach out to people.

(22:15):
In a remote company, maybe that's scheduling coffee chats or a little one-on-one, for example. In an office, I would personally make an effort to sit at the canteen every day and just get to know people, not just learning their names necessarily, but getting to know them a little bit as well.

(22:29):
It could be on a slightly personal basis at first, just learning where they're from or what area of the city they like to hang out in, but of course this is a segue to learn a bit more about their professional responsibilities and some of the challenges they're facing.

(22:41):
This doesn't necessarily sound like the most productive thing you could be doing in terms of getting from A to B, but it actually pays dividends as you build a support network.

Ian Douglas (22:49):
And it helps with learning the company culture a little bit as well to engage other people at the company and see what they're like to communicate with and how open they are to sharing that information. I think that also tells you a lot about the company. If everyone's rushing around and it feels like nobody has time to talk, then again, that could be a warning flag too of like, "Wow, everybody here is so busy. They don't even have time to stop and greet the new person on the team."

Jan Arsenovic (23:15):
Tip number two, find a mentor.

Ian Douglas (23:20):
Having a mentor, not so much a buddy, but someone that you can go to within the company to really learn from and really absorb their information is really important. As you are documenting things for yourself, you're asking them to check things for accuracy and maybe they can fill in gaps in your knowledge.

(23:37):
But it can also help them understand from a different person's perspective where those gaps in knowledge could be coming from and go, "Oh, you know what? As part of that onboarding, I realize you didn't get to learn about this particular kind of system. Maybe we need to add that to our onboarding." That can be an important realization for the company as well. Not just for your own learning, but for the company to learn as well, how do we better onboard our own employees?

(24:01):
I think it's also important that you have a mentor outside of the company as well. And this is something that I often tell people when you get a job, find somebody within the company that can mentor you. And whether they leave the company or you leave the company, maintain that professional relationship with them because it's important that you build that network and maintain that rapport with them over time.

(24:23):
Every company that you go to, you're going to learn how that company does something. And this is something that I see a lot in junior developers, they go heads down, they put on the blinders like a horse on a cart where they put the little blinders next to the eyes and so the horse can only see in one direction.

(24:39):
And when you're a junior developer and you're being taught this is how our company does a thing, you build this automatic mindset of this is the only way I'm supposed to do this thing. And maintaining these mentorship relationships outside of the company can help take those blinders off.

(24:56):
Now you have to be careful, if you have an external mentor, that you're not betraying any non-disclosure agreements or secrecy agreements and things like that that are in place. So maybe you can't show them the code, but you can say, "Hey, Alex. I'm having this issue at work where I'm trying to talk to a database and I'm getting this weird kind of error and I'm not even sure where to start looking for a solution," and you can describe things in more vague terms.

(25:19):
But if you maintain those relationships, you can start to gain other perspectives on other ways to do things because maybe they've solved a similar challenge where they work or they've got experience working with those kinds of databases. So I think it's important to maintain those relationships even outside of where you're working. So any mentor that you have, keep working with that mentor throughout your career.

Alex Booker (25:41):
How, Ian, would you go about identifying a mentor or buddy internally?

Ian Douglas (25:46):
Some companies when they onboard you, they will assign you someone to pair or program with you or to say, "I am your person to ask questions. So if you have a question, you come to me. That's my responsibility while you're onboarding. You are allowed to come ask me as many questions as you want." And that can start that mentorship kind of relationship.

(26:07):
But I think it's also important for you to understand when you have other interests within the company and say, "You know what? I'm working as a front end developer, but now I'm really curious about how that database actually works."

(26:19):
If Alex is my go-to question person, I can say, "Hey, Alex. Who can I talk to at the company about this part of the database because I'm actually curious how that part works? Is there someone in the company that I can talk to about more of the internals about that, just to learn a little bit more?" It doesn't mean that you're going to become a database administrator.

Alex Booker (26:37):
I like that.

Ian Douglas (26:37):
Ask the people within your immediate circle within the company to say, "Who else can I talk to about this particular thing?" And get a name, reach out to them and say, "Hey, Sam. Alex mentioned that I should reach out to you to talk about this kind of database thing. I'm curious how this part works. I'm doing front end, but I'm curious about how the internals of this mechanism work, if you have a few minutes for a conversation." I think that that's a very healthy thing to do.

(27:02):
And again, if there's good company culture around being able to ask those questions and help one another out, it just increases everybody's knowledge. It helps people teach, it helps other people learn and we all get better at doing that.

Alex Booker (27:16):
I wonder, when does a coworker become a mentor?

Ian Douglas (27:19):
I think as you ask questions, you'll start to recognize who's answering your questions in a respectful way that they don't make you to feel like you're being that drain that we talked about where they're like, "Oh, here comes Alex again. He's going to ask me a billion questions." You can get that sense from somebody, you feel like you're wasting their time. That's not the kind of person that you want to talk to.

(27:40):
You want to talk to someone and build up that mentor-mentee kind of relationship with someone who is happy to share their knowledge with you, like they see that sort of spark in you of, "Alex really wants to learn this thing and I happen to know this thing." That gets me really energized if someone comes and asks me questions about something that I'm genuinely interested in, it gets me that much more passionate to share that knowledge with someone else.

(28:08):
That's a good sign of how to find a mentor, just seeing when they are happy to talk to you about something. It's like, "Oh yeah, let's dig into that database internals thing again. That was a lot of fun last time." It's meant to be a five-minute phone call, but it goes on for half an hour, kind of like these podcast recordings that I do with you.

(28:24):
I think that's a good sign of when it feels like a friendship and a comradery as opposed to an interrogation of, "I'm going to ask you a question, you're going to give me an answer. And then I'm going to ask you another question, you're going to give me another answer." That's not as good of a relationship. But you want to make sure that they are treating you with respect and they understand that you're there to learn.

(28:44):
Now, if you're asking them the same question over and over and over again, like if I come to you for the fifth time and say, "Alex, can you show me how to do that thing again?" then I'm probably going to get annoyed. It's like, "Dude, take some notes next time so that you don't have to ask me this thing again and again."

(28:56):
So my expectation when I meet with mentees is like, "All right, you got a notebook? Write this down." And I'm going to expect that you're going to write this down. Not that I don't want you to come ask me that again, but I'm hoping that you're going to build up this sort of library for yourself of how to approach things.

(29:11):
And then if someone else has that question, you're like, "You know what? I've got some notes about that. Let me share those notes with you." And now you're making everybody better as a team. I've just expanded my knowledge into you and then you've shared that with someone else, and so it becomes an exponential kind of thing from there.

Alex Booker (29:24):
I think that's the fuel for a mentor when they give you advice or show you how to do something and then you come back and show them how you've actioned that or implemented it or how you've helped them rather than just drinking from the knowledge while you're building a relationship. And I think that's such a magical thing that can happen and in a company.

Ian Douglas (29:42):
Yeah, I think the other thing that's important with that mentorship too is there are going to be times in your career where you're feeling down like, "Oh, I can't solve this problem," or, "I had a really rough week," and sometimes you need someone to remind you of all the good things that you've accomplished too.

(29:57):
And so having that really respectful mentor relationship with someone else that they can prop you up when you're feeling a little down and say, "Hey, Alex, but remember that time when you did this thing and you totally crushed that problem last time? Don't give up on this. You can do it. You did it last time, you're going to do it again."

(30:14):
And just having that kind of motivation, I think, can really help too. And that's also a sign of a good mentor that they're not just there to share their knowledge with you, but they're there to motivate you when they sense that you need a pick-me-up.

Jan Arsenovic (30:26):
Tip number three, ask lots of questions.

Alex Booker (30:31):
Ian, what is the importance of asking lots of questions when you're new to a company and a team?

Ian Douglas (30:38):
I think first and foremost it's to obviously build up your own knowledge, but I think that as you proactively write those things down and document that for yourself, I think you can also make the team better by sharing that documentation as well. That way you're also not asking the same question over and over again.

(30:57):
So I think that what's important there is when you're asking those questions and you're getting answers, you're writing them down, but then you're double checking with that person later on like, "Hey, Alex. When you said this thing in the conversation that we had, I actually wrote it down this way. Does this look accurate? Is this an accurate way that I wrote this down? Should I reword it, rephrase it?" That'll help them understand their own communication pattern around, did I communicate that well for you to understand it and document it, and then is that accurate?

(31:26):
And that also then helps someone else on the team because if I know that you've documented that thing properly and someone else comes and says, "Hey, have you got a minute to talk about such and such?" It's like, "You know what? I'm really under a lot of pressure right now, but I just helped Alex with this a couple of days ago and I know Alex took really good notes. So I bet Alex can help you with that."

(31:43):
That helps you teach them. It also helps cement your own learning when you can then turn around and help somebody else out with that same thing and you can work through that problem together. So I think it's important to take notes when you ask those questions.

(31:58):
I like to talk a lot about the impact that you have at a job, not just the things that you do, but the impact that that has. And I think that as you document that stuff and people know that you're writing things down and that you're making sure it's accurate, even though systems change over time, they know that the notes that you took are reasonably accurate, you're going to grow a lot faster within the organization because they know that you're going to be that go-to person.

(32:21):
And it's not so much to put extra work on you, but as part of your onboarding, if you can start documenting some of that, then the next person they hire, they can continue that as well, and maybe that can become part of the onboarding.

(32:33):
And you can talk to management and say, "You know what really helped me over the past 90 days was actually writing all this stuff down. Here, let me share these notes so the next person that you hire can continue on with these notes." That's going to really wow them. That's going to knock their socks off and go, "Wow, look at how proactive this person was."

(32:49):
And that's the kind of impact that you want to have. That's what you want to be remembered for. And you're going to really make a name for yourself by showing the initiative of taking those extra steps. You're going above and beyond, and that's what's going to make you really stand out. Those are the kinds of people that I would want to hire again.

(33:06):
I can count on one hand some people that I've worked with at more than one job that I would absolutely work with again at future jobs because we work really well together. We have that trust, we have that respect with each other, we know how each other works, and I would absolutely work with these people again. And that's the kind of reputation that you want to build for yourself, and it can start really early in your career.

Alex Booker (33:27):
I love this. It's just fascinating that as you describe the traits of those people you would work with again, you didn't once mention that they were the most amazing coder you've ever seen. They might happen to be, and I'm sure they're very competent, and likewise, coding does matter, but what I really like is how you're emphasizing the importance of a soft skill, like listening, and how yes, you do need a foundation of technical knowledge, that's non-negotiable, but oftentimes the way you stand out is with these soft skills like active listening, note-taking.

(33:58):
People sometimes might not know much about what makes a great listener. It's not just smiling and nodding. It has to do with asking probing questions and taking notes and things like that as well.

Ian Douglas (34:09):
Yep, and I think a really good set of questions to ask are things like, why do we do it that way? Not in a critical sense of why do we do it that way, but from a genuine point of view of like, "Oh, can you tell me a little bit more about why the company or why the team decided to implement it in this fashion?" It helps bring more context into what you're building to know the why and the how. I think it can give you more perspective.

(34:35):
Then as you're going through and you're uncovering some of the architecture and uncovering some of the code, you can understand like, "Oh, this is what Alex was talking about. When I see this block of code, I've got a better understanding now of how this fits into the bigger picture."

(34:47):
So yeah, I think those soft skills are absolutely critical. I mean, certainly you need to have the hard skills, but those soft skills just make you a better teammate overall. And so the more that you can exercise those and flex those muscles, the more people are going to want to be around you as a teammate.

Jan Arsenovic (35:04):
Tip number four, make it easy for people to give you feedback.

Ian Douglas (35:09):
When I ask my team for feedback, one of the first things I do at every job that I go to now is I say, "Hey, just FYI, I'm Ian. This is where I'm from. By the way, I love getting feedback. If you've got feedback that's maybe of a more critical nature, not that you're going to tell me I'm a horrible programmer or anything like that, but if you've got a way that I can improve, I would prefer that in privacy. Just let's have a private conversation about that.

(35:33):
"And for me, I'm not as big on, hey, let's all pat Ian on the back and congratulate him and make a big deal and shine a spotlight on something that I've done as far as positive feedback goes. I also prefer to downplay that a little bit because I believe everything we do is team effort. I'm about celebrating a team and what the team accomplishes."

Alex Booker (35:54):
At the same time, Ian, feedback can sometimes feel a bit like criticism. How do you view the difference?

Ian Douglas (36:02):
The difference between feedback and criticism I think comes with the idea of intent behind it, am I telling you this to make you better at your job or am I telling you this because I want you to feel bad about something? And I think that there's a way to share critical feedback with someone in a way that is constructive. I've certainly had to do this as a manager and as a director.

(36:23):
Certainly having to let people go from a job is always the hardest thing I've ever had to do. And I always hated having to let someone go, but I would always make sure that I was giving them feedback along the way. I would always have a lot of one-on-one meetings with my direct reports to say, "How are things going from your perspective? Now let me share how I see things going from my perspective. Let's try this."

(36:43):
And it was always like, "What can we do as a team to support you in this thing?" Not, "You need to be better about writing your code this way or that way." I would always try to frame it as, talk to me about your process for writing code and doing these code reviews and what's your process? Because maybe you're missing some steps along the way, and I want to make sure that we're really clear on what our company process is and what it's meant to be so that we're all working the same way and helping each other in the same way.

(37:14):
I think that there are ways to give critical feedback that doesn't come across as criticism, but it's meant to be a growth opportunity. And I think it's important that we are also open to those conversations. There can be a lot of ego with what we do as developers. It's like, "I know how to code. Don't tell me how to code. Don't tell me how to do my job."

(37:32):
It's like, "Well, I'm your manager. It is my job to tell you how to do your job. Maybe not how to write every line of code, but it is my job to tell you the process that we follow and making sure that everybody is following that same process. And if the process needs to change, then we'll discuss that as a team. But it doesn't mean that one person gets to go rogue and do things their own way. We're here working as a team and we all need to operate as a team."

(37:57):
Letting people know that you're open to feedback is important, and keeping notes about that kind of feed feedback I think is important so that you can reflect on it and have that growth mindset about what you're learning along your journey.

Alex Booker (38:08):
What I would add to that is apart from announcing it in a way, you can ask for feedback. That's a great way to not only verbalize it, but demonstrate that you're serious about getting feedback on something specific.

(38:19):
Feedback is honestly such a key part of any team effort, and when you build trust and familiarity with people and you've been working together for a while, it does get easier, but it's in those first few months and even during the period of time where a team is forming, which could be many months beyond your own onboarding, there can be some sensitivity around feedback. But I think inviting it as much as possible is a great thing to do.

(38:43):
But also be quite specific about what feedback you're looking for because that will make people feel a bit more empowered, I think, to give you the feedback that you need. At the same time when you get the feedback it's important that you are gracious and grateful. I always thank people for their feedback.

(38:57):
There was a time when I heard that feedback is a gift and I thought, "Is it though? It feels like I'm being criticized a little bit." But I cannot emphasize how grateful I am these days when I get feedback because someone took time out of their day to offer me some advice that could make my work better and at the same time, improve the success of our projects as a team. I always genuinely really appreciate that.

(39:20):
And not only that, but I know how difficult it is to give good feedback, and when I see some eloquent, thoughtful, researched feedback, I just know how much effort they put forth and it's so important. So I always like to thank them and sometimes even in public as well.

(39:34):
So some teams have Slack bots or all-hands meetings where you can give little shout-outs. I think it's nice to not only appreciate that person, but that also broadcasts to the other people in the team or the wider company that you are somebody who can take and appreciates feedback.

Ian Douglas (39:49):
Yeah, definitely. And you're right, it does come down to that idea of trust and respect. As a team, you're going to trust each other more when I know that when you're giving me feedback that you're doing it with good intent. I already know I messed up. You don't have to be super critical and make me feel even worse about something that happened. And so any sort of actionable feedback I think is really important.

(40:08):
But you're right, it is hard to give good feedback where you can say, "Hey, here's something to try for next time." I'm a big fan of iterative improvement. That's why I really love the agile process. It's like, okay, this worked well, this didn't work well, what can we change? What can we try a little bit different next time to see if we have a different kind of outcome?

(40:26):
The other thing that I think is really important with feedback is that you keep good notes about your feedback because that can also turn into a list of accomplishments for you. So whether you're building up your resume or your CV for a future job or just documenting your own notes of what kind of impact you had along the way, I think it's important that you document that as well.

(40:45):
And sometimes that can come from feedback from other people, "Hey, Alex. You know what? I really liked the way that you implemented that method. It was nice and streamlined. Or how you put that whole module together for that new feature that we added, that's going to be really reusable. That was really nice the way that you did this according to this or that design pattern." It just gives you that sense of accomplishment above and beyond.

(41:07):
And I think it's important to document that as well just for your own notes because sometimes we forget that. We leave that job and it's like, "What did I accomplish at that job?" And you've got to go back and really think about, what do I want to put on my resume or CV. But if you can document all that from your feedback along the way, then you've got that list of accomplishments and that impact that you've had at that job. And sometimes that can come from just the feedback that you get from your teammates or from management.

Alex Booker (41:31):
Ian, just how many solid state drives full of notes do you have at this point?

Ian Douglas (41:37):
I mean, if I were to sit down and fully write out a resume with all the major things that I've done at, gosh, 14 or 15 jobs now in my career, I think I'm up to about a four-page resume. But I always trim it down to a page for any job because like I've said before on the podcast, companies really only care about what you've done in the last 5 to 10 years. They don't care about what I did 30 years ago. So it's not as important.

(42:01):
Sometimes you can call up older things that you've done if it is highly relevant to a job. But yeah, I mean I've got a fair number of notes. But also, these are things that I've learned along the way like, "Oh, I wish I had kept better notes at that job."

(42:13):
When I was doing my job hunt a year and a half ago and trying to put a resume together, I actually found an old resume of mine from 2014 or 2015 where I was applying for a role internally at the company and I had to list out these were all the accomplishments I made at that job to apply for this other role internally, and I'd forgotten half of the stuff on that list.

(42:32):
And I'm like, "I'm so glad I'd kept a copy of that resume on my own hard drive." Because when you leave a job, you often lose access to all those notes, and so you have to keep that list of accomplishments somewhere that you can access later on for your own motivation, but certainly for getting another job in the future.

Alex Booker (42:51):
As a new developer, how would you go about handling feedback that you don't agree with? That can be a tough position to find yourself in, I think, if you don't have the right tools to negotiate it.

Ian Douglas (43:02):
Yeah, I would start by questioning why you don't agree with it. Is it ego creeping up where you're like, "Oh, I don't believe what Alex just said. I think I did that just fine." If Alex has more experience than I do, and Alex is telling me I shouldn't have done something a particular way, do I know Alex well enough to know that Alex is coming from a good place and Alex is trying to help me grow? Or is Alex just being critical?

(43:23):
Maybe I need to get that advice validated from someone else within the company who can actually take a look at the code and say, "Hey, Sam, or whoever, can you also take a look at this code because I got some feedback?" And you don't even have to say from who. You can just say, "I got some feedback about this particular bit of code that I wrote, that it wasn't very efficient. Can you take a look at it and also let me know?"

(43:42):
If they come back and they're like, "Yeah, you could have done this or that." It's like, "Okay, well now I should trust Alex's feedback because Alex actually told me the right thing." But if they come back and say, "No, whoever gave you that feedback is full of beans," then it's like, okay, well now you start to build an understanding of who you can trust for that feedback.

(43:59):
But I would say start by questioning why you disagree with the feedback because it could be just ego creeping in where you could be really proud of something and someone comes back and says like, "No, that wasn't the right way to implement it," or, "The way that you implemented it wasn't good."

(44:14):
But if you're a junior developer, you don't know necessarily all the best practices and you don't know all the industry standards and whatever. And so my job as a senior developer is to coach you on those things and say, "Hey, the code that you wrote works, but if you do it this way or that way, this is the long-term implication of changing it up and doing it this way or that way," instead of just saying, "No, the way you did it is wrong," because that's not really actionable feedback.

(44:39):
But by sitting down and coaching you through why you should do it some other way, that's a better way of giving that feedback. And even if you don't agree with that feedback, like you say, still coming back from this place of gratitude of, I appreciate that you just took 20 minutes to walk me through this and talk me through why I should do something a particular way, even if I don't agree with it. You still took a huge amount of time out of your day to coach me on something.

(45:05):
That's also an important skill to learn as well, being open to getting that feedback, whether you agree with it or not. I think having perspective I think is really important. We talked about that a little bit with finding a mentor and sometimes having a mentor outside of the company can help you gain broader perspective on how to accomplish a goal.

(45:23):
Sometimes when people give you that feedback, they just want to give you a different perspective on, yeah, that works, but here's another way you could have done it. And if they present it with, here's what you could have done and why, then that's all the better. And now we're all making each other better because we're teaching each other different ways of growth.

Alex Booker (45:40):
I think that's the best thing about code, coding is really complicated, but it's less complex than human beings, which are infinitely variable and very emotional. And so when it comes to evaluating two approaches to a solution, you can almost always objectively bring it back to trade-offs, I feel like, and that in a sense is relatively easy.

(46:01):
I think where tensions can run a bit higher is around directions to take projects more broadly or working styles and things like that. In those cases, you generally want to find something to align by. Instead of asking whose idea is better, you should maybe ask which of these is going to bring the project forward? And ideally you can bring some data to justify those things to the table.

(46:21):
I think where feedback and things like this get really difficult are when you're working with people who don't give good feedback, and that's why it's a gift when you really do get good feedback. Some people can overwhelm you with opinions, though they're not proactive about suggesting a way to move forward with that or how to action it. That can sometimes be not the most helpful feedback.

(46:39):
And at the same time, some people don't have the most tact when they deliver feedback. They could be absolutely valid in what they're saying, but they deliver it in a way that doesn't quite hit right. You have to employ a certain degree of responsibility to untangle their intention there, but it's not easy either, and it's really a two-way responsibility.

(46:57):
It's a empathetic process where you both need to appreciate and understand each other and where you're coming from, and it takes time as well to build this toolkit. I think it's something, as a new developer, you can't necessarily come out of the gate with. It's one of the reasons why on this podcast, we often say that if you come from a previous industry, you have more advantages than you realize because you might have experienced something like this in a previous role and know how to handle it.

(47:22):
The only last thing I would say is just that as a new developer especially and during an onboarding period especially, it's generally, in my opinion, going to be better to assume that someone else knows best because you just don't know what you don't know.

(47:35):
I think after the onboarding and maybe after a quarter or six months at the company, you yourself might have a better idea about why something could be done a different way. But rather than just pushing back without any basis, you can explain and go back to Ian's advice and ask, why don't you agree with this? If there's a good reason you have every right, essentially, and maybe you should be encouraged to express that because it's through the debates that you arrive at the best possible solution.

Ian Douglas (48:00):
The nice thing about software is there's lots of ways of accomplishing a goal. The bad thing about software is there's lots of ways to accomplish a goal, do I design the algorithm this way or that way? Does it use more CPU or more RAM or is there some balance there? And so sometimes getting that feedback, like you say, unpacking what's the intent behind the feedback? Is it because I'm overloading the CPU or I'm using up too many of this other resource or something like that?

(48:24):
I would say as you get on in your career as well, asking for feedback about how you give feedback I think can be important too. And just say like, "Hey Alex. Sam asked me for some feedback on this bit of code. I want to tell them this. Do you think that's going to come across the way that I intend?" And I can have a conversation with you because maybe you and I have worked together for a long time and you understand that how I may present that, not that it's going to come across hurtful, but that I'm getting the point across properly.

(48:53):
And so I think as you get on in your career, making sure that others are coaching you on how to give that good feedback, I think is important as well. So if I know that Alex is really good at giving other people feedback, and I'm not sure whether my feedback is being accepted the way that I intended to, maybe I should be asking other people for help about how to give that feedback in the first place.

(49:14):
These are all things that you learn and grow into over the course of your career. But being able to give and receive good actionable feedback is an important skill, and it's one of the harder skills to learn. I've often felt in my career as a senior developer, it's like, well, I could explain to you how to do it, but in the time it would take to explain how to do it, I could just go do it myself. But then I've stolen that opportunity for you to learn and grow where I could just coach you through it instead because that then makes the team better.

Alex Booker (49:51):
So maybe, Ian, you can help us close out by almost describing the kind of developer that would do really well at a company during their first few months. What are some of the most important traits?

Ian Douglas (50:03):
I think the biggest thing when you're starting at a company is you need to be open. That encompasses a lot of things. You need to be open-minded about how a company does things and operates. What you learn in school or your bootcamp at Scrimba or wherever you're learning to code, how you actually do the job once you get into a company could be different. And being open to, "Oh, that's how we do it here. Okay," as opposed to, "Wait, that's not the way I learned it. I can't do it that way."

(50:29):
So I think having that growth mindset is really important, and just being really open to adapting what you know and what you think you know to different ways of approaching problems and different ways of accomplishing goals. I think that that comes across to your team of this is someone who's going to be adaptable and someone that I'm going to appreciate working with.

(50:49):
Because I think as they realize that you're open to change, that you're open-minded to different ways of solving problems, that you're going to be more creative about how to do things because you're going to experience different ways of doing things.

(51:03):
If you can stay on top of trends and where the industry is going, I think that can be of benefit. Take the opportunity on the job to learn your job. And your after hours time, I think you can spend just keeping your finger on the pulse of what's happening in the industry with AI or whatever tools are coming out.

(51:23):
Things are going to change. Being open to that change over time, I think is going to be really important. 10 years from now, you're going to program things very differently than the way we're programming right now. The frameworks and the tooling that we use today are going to be different two years from now, five years from now. And so just being willing to roll with whatever comes your way is really important.

(51:44):
And then just documenting things and having others check it for accuracy, I think just shows that you're willing to turn around and help the team. And that goes a long way into the kind of developers that other people want to work with. And other leadership, when they leave a company, they're like, "Hey, Alex. I'm going to go start this other business. I want you to come with me." You can build and maintain those relationships over time.

(52:07):
And hopefully fortunate enough to work with colleagues that you get on really well with is going to be an important part of growing into a really open-minded developer who can adapt to a lot of things as opposed to being very closed-minded and say, "I only want to work in this technology." Because if that technology goes away, then you're losing out on where you could be taking your career.

Alex Booker (52:30):
Have you worked with people who have a bit more of a closed mind, and do you see that impacting their career in a negative way compared to those you've worked with who have a much more open mind by comparison?

Ian Douglas (52:41):
At one particular job I can think of, we changed things quite a lot. We changed a lot about our team processes, and we changed our technology stack several times. We had started in one programming language when I got there, we were shifting into another programming language that split off into two other programming languages again, all within the span of two years or three years.

(53:02):
And a lot of people, because there was so much change and it was just constant change, you could see this mental hurdle that they would have of like, "Oh, more change." And they would kind of grumble their way through it, and it would take them a lot longer to get started on things. Not that it hindered their career, but it certainly hindered the team sometimes.

(53:18):
Hey, you know what? We have to do this. This is the decision that came down from leadership. This is how they want us to develop this thing. These are the benefits of moving to this other technology. Let's just go with it. And when I left that job, I actually wrote a one-page letter to everyone on the team saying, "Be open to change."

(53:37):
If I've made any kind of impact on the team, I hope it's that we can all adapt to change. Because in my four years at that job, I had gone through four or five programming languages, several frameworks, lots of different ways of doing testing, lots of ways of building out service-oriented architecture. And then just the team adaptation of are we doing agile? Are we doing scrum? Are we doing kanban? Are we doing some mix of all the above? Are we doing extreme development, lean development? How are we doing what we do?

(54:08):
And there was just so much change and it's like, you know what? All right, this is how we're going to do it for a little while. We're just seeing what's going to work and what's not going to work, and eventually we'll settle into how we want to work together as a team. But we would lose people on the team where they would just say, "Enough is enough. I'm tired of all the change. I'm going to go somewhere that's more stable."

(54:26):
But I mean, that's how you need to adapt over time. Things are going to change. That's the only constant in development is that things are going to change.

Alex Booker (54:34):
Ah, yes.

Ian Douglas (54:36):
It's the only thing that doesn't change is that it's going to change, and that's okay. There are going to be new tools and new languages, and that's fine. We're coming out constantly with new higher level programming languages that abstract away a lot of the low level detail. Somebody smarter than me is coming out with a new programming language, and now I can go write a whole new application in fewer lines of code and I can get that app out that much faster. Great.

(54:58):
If it's got performance issues, I'm sure they'll figure that out over time, and my app will get faster over time, whether it's through hardware, or through better software. Or maybe some other language will come out and we'll rewrite that thing again. It's like, okay, I'm being paid to do this, so I'll write. That's fine.

(55:12):
Being really adaptable to that mindset and just really having that growth mindset, it really just comes down to I'm going to constantly grow. I'm going to constantly learn. I've got this insatiable hunger for just knowledge and then turning around and sharing that knowledge with other people. And I hope that that becomes somewhat infectious with the people that I mentor. Even with my own kids, I mentor them in that same mentality of just constantly learn and then turn around and teach that to someone else because that's going to make you understand it better if you have to explain it to someone else.

(55:44):
And just seeing them grow in their own life, but also seeing the people that I mentored now turn around and become mentors themselves. It's like, "Yes, I did the thing. I replicated my knowledge in someone else, and now they're replicating that as well and putting their own perspective on it."

(55:57):
But putting their own perspective on it, not that they're just echoing back the advice that I shared, but taking my advice, putting their own perspective on it, and then turning around and sharing that with other people. That makes me feel good. That's what charges my batteries and keeps me going.

Alex Booker (56:13):
Thank you so much for joining me. I think this has been a truly insightful episode I hope people can keep coming back to. Ian, thank you so much.

Ian Douglas (56:20):
Thanks, Alex. Look forward to part three.

Alex Booker (56:22):
Oh, you know it.

Jan Arsenovic (56:24):
That was The Scrimba Podcast, episode 123. If you made it this far, and if you've learned something, please subscribe. We are a weekly show, which means there's a new episode every Tuesday. Check out the show notes if you want to connect with Ian or for Alex's Twitter handle if you want to tweet at him directly.

(56:44):
On that note, the best and the easiest way to support this podcast is to tell somebody about it, be it in your online community, in real life, or on social media. And if you make a post about the podcast on Twitter or on LinkedIn, you might get a shout-out in one of the upcoming episodes. And if you're feeling super supportive, you can also leave us a rating or a review wherever you get your podcasts.

(57:08):
I've been Jan, the producer, and we'll be back next week.