The Scrimba Podcast

Jan Arsenovic (00:19):
Hello and welcome to The Scrimba Podcast. On this weekly show, we interview recently hired junior developers, senior developers, and hiring managers to help you learn to code and get your first job in tech by learning from both sides. In this episode, you'll learn how companies work. How does a typical team operate? Who do you report to? How do you know if you're the right culture fit? And why do job postings sometimes not make sense? We have compiled the best advice to help you understand a corporate environment.

(00:52):
You'll hear from engineering manager and career coach, Tiffany Jachja, founder of technical integrity, Dave Mayer, opera singer turned developer and developer coach, Anna McDougal, and engineering manager, Jason C. McDonald. You're listening to The Screamer Podcast. Let's get into it.

(01:12):
So you just got your first coding job, congratulations. Or you're ready to apply for one, congratulations again. But while getting ready for a job interview itself is one thing, figuring out how things work once you get the job is a completely different beast. If you're joining a company, you're joining a team, and the people in that team will probably have different levels of seniority and different titles. You'll probably have spoken to an engineering manager, but now there's also a line manager, there's a scrum master, there's somebody who's an engineering lead. There also might be project managers. Wait, is everybody managing something? And how do you work with all these people?

(01:56):
Meet Tiffany Jachja. Tiffany is a data scientist, career coach, engineering manager, and Twitch streamer. By day, she works at Autodesk. In her interview on the podcast, she helped us untangle the dreaded corporate hierarchy and the structure of a team.

Tiffany Jachja (02:14):
Firstly, you have what are called individual contributors. These are typically your engineers. They're not quite managing anything. They may contribute to work at an individual level, and that's sort of one way to look at it. And then you have what are called your managers and then your owners. So your managers are typically people managers. They manage some aspect of the work that's happening, and that's when you'll get an engineering manager. That's typically the person that you report into as an individual contributor.

(02:45):
And then as part of the team, you have support for what you're building. That'll typically come in the form of a program, a product manager, a project manager. Your scrum master is also the manager of your scrum or your agile workflows, so you get certain kind of titles associated with how your team is set up, and those people will typically manage tasks or core responsibilities, and that's how you interact with other people on the team. So there's kind of different areas when you think about a team, and that's how it's typically set up.

(03:20):
And product managers could have other product managers that report into them or they report into their own product line, but engineers are typically focused on that individual contributions. And so the better that you can work together with your manager, product manager, whoever else is on the team, the stronger team that you have, essentially.

Alex Booker (03:41):
So more often than not a newer developer on the team would be an individual contributor in this scenario?

Tiffany Jachja (03:43):
Yes. And then you can have things like becoming a team lead or a staff engineer. In a team lead, you're leading up a particular development of a milestone. In a staff engineering situation you're a part of, you're contributing to multiple teams. So everyone kind of just has their own specialty or tracks for growth in their particular role. An engineering manager may be a leader of multiple teams in the future, or they may be a leader of other managers and then they don't have individual contributors reporting into them. They're instead the manager of those managers who have individual contributors.

(04:17):
And then you have your product managers, which I forgot to also talk about more. Product managers who have domain expertise around the products that are being built. You have your project managers who have experience for managing projects. You get these specialties in teams that are helpful. And in data we have data scientists, data engineers, machine learning researchers. These are just additional specialties to a typical engineer that you'll have on the team. And that structure of whether or not they're individual contributor or more of a manager can differ as well. So it can get quite complicated.

Alex Booker (04:54):
I suppose the bigger the company, the more people and leaders and levels of hierarchy involved and that kind of thing. But it is quite typical, I would say, even in smaller teams to have a project manager or product owner who coordinates with stakeholders and gathers requirements and represents the customer sometimes. And then there's oftentimes an engineering manager who is involved in managing the work, ensuring all the individual contributors come together to deliver on those requirements.

Tiffany Jachja (05:18):
Yeah. And sometimes there's a little bit of an experience gap between others on your team and then your engineers, your engineering team, so an engineering manager can help bridge that. When my team had a product manager, we don't have one at this moment, so it's actually interesting because sometimes then your engineering manager ends up taking over some of the product management, but you can have syncs and conversations to help bridge the gap between product management and engineering so you can really help scope out how much time is something going to take, what may be the technical challenges of a particular idea, so you can come at it from a practical standpoint or just even from a standpoint of implementation.

Alex Booker (05:57):
I like the distinction you introduced before between project management and people management. Some parts of leadership are ensuring the delivery of projects. Other parts of leadership are to do with the success of the individual team members. And of course there's a huge amount of overlap as well.

(06:11):
One thing I've encountered in the past is like sometimes your engineering manager is not also your line manager because I think the idea is that if there is something that is affecting the team, potentially, you might want to have a different leader involved. And likewise, sometimes you'll request vacation days from your line manager rather than your engineering manager, and there'll be a sync and everything's communicated obviously, but some teams do just have that little separation between the project management and the people management. Is that something you've come across?

Tiffany Jachja (06:38):
That's fairly common, especially if you have the setup that allows for it, it's probably a good thing because then not everything ends up being very personal, especially if there's very hard deadlines or additional communications that have to happen because someone's going to be out later and that sort of thing, it's really good. And it's also helpful to have other people advocate for you as an individual contributor or just as an employee. The more people who support you are saying good things behind your back or when you're not in the room or in a meeting, the better it is, typically. I see those as benefits to that as well.

(07:12):
But yes, an engineering manager will also typically look out for the development, career development of their individual contributors or their direct reports. And so some of that can include having one-on-ones tracking goals, getting to know the person, talking about what does career development look like? And that sort of thing.

Alex Booker (07:30):
And this is all great information. The engineering manager, the line manager, these are two people you'll definitely encounter during the interview process. You might not have both if you're in a smaller team, for example, but it's really good to know who they are, what they care about. Now I feel like someone listening is a bit better equipped to make the interview a dialogue. Ideally, an interview should be a two-way street. The first step to feeling confident in that environment is to understand that person's role and what questions would be appropriate.

(07:57):
And as an engineering manager yourself, I was curious to hear from you what are some of the things that a junior developer should be looking for from their engineering manager? What are some green flags that they should keep an eye out for and maybe even try and tease out with thoughtful questions during an interview process?

Tiffany Jachja (08:13):
I would ask questions around what is the mission of the team? How do you see it growing? And make sure that you're happy with that answer. A lot of times the engineering managers who can't advocate for their team or don't understand the work at a high or an in-depth level or a certain degree won't be able to advocate for you and your growth. I think it's just oftentimes I've experienced that as an individual contributor myself, understanding that your team exists for a purpose and that other teams and other parts of the organization need to be able to understand that in order for you to feel like you can focus on the work when you're there.

(08:52):
This is why we have engineering managers in the first place to manage the existence of the team, so I think it's important to always have someone or a team lead there to be able to remind the organization of the mission values and how the team contributes to that larger picture in an organization. That's one thing to lookout for. The second bit is do you work well with this person? Do you think that you have something to learn from them? I think that as an engineering manager, you have the unique opportunity to be able to mentor or coach your direct report. And so if you can see yourself growing because you're working closely with someone, that's typically a good sign in terms of whether or not this person would be a good manager.

(09:35):
You can also ask them questions about how they think about engineering management, how they do one-on-ones, do they do one-on-ones? That sort of thing. Those are typically good questions to ask as well.

Alex Booker (09:49):
There is a resource I want to share with people called the Nine Belbin Team Roles, and it basically outlines different characteristics of team members. For example, you might be a really great starter, like you can work in ambiguity and you can be quite self-motivated to build a prototype and get it out the door because those are your strengths. You're not going to be the right person to polish it and fine-tune it. This kind of person might also get bored towards the end because they like to learn a lot of different things and combine them.

(10:17):
Meanwhile, there are finishers and people who specialize more. There are people who are very good at coordinating, but sometimes struggle with the individual tasks. We're all quite different and we all have our natural strengths and weaknesses. There is a sort of challenge in becoming self-aware about those things. It wasn't really until I got into the workforce that I really realized where my weaknesses and strengths were. I'm wondering what we can suggest people do to build that awareness and maybe hone those skills before they get a job.

Anna McDougal (10:43):
I sometimes get brought in on job interviews, and one of the questions that we often ask people is, have you ever coded in a team?

Jan Arsenovic (10:50):
That's Anna McDougal, she's an opera singer turned developer. Anna also coaches junior developers on her YouTube channel, Twitter, and around the web. In her episode, we peeled back the curtain to learn Anna's streamlined advice for new programmers looking to find their success as a junior.

Anna McDougal (11:08):
And that is, I think, the best way to discover this kind of stuff. So it could be, for example, learning from someone else. So having a mentor, for example, who you do pair programming with. It could be doing a hackathon or something like that. Although again, being a mom, I know how inaccessible that can be to a lot of people. You can't always take a weekend off and do overnights and stuff like that. It's just not practical for a lot of people. But there are also, for example, Codebar is an online free mentoring meetup that happens. I sometimes attend some of those as a mentor.

(11:39):
There are a lot of Discord communities. I mentioned The Odin Project before that I was a part of. I know that Scrimba has a good YouTube community. I've seen them in action several times now and they're really wonderful. But if you can connect with people in these communities and say, "Hey, let's just have a pair programming session together," that often gives you some perspective. Obviously, one time is only going to give you one perspective, but if you do that a few times with a few different people, you start to notice patterns about what you're gravitating towards and what they're gravitating towards or whether you're a leader or a follower in pair programming. Do you prefer to drive or to navigate? Do you prefer to pick up on the errors that another person is making?

(12:19):
Do you like talking about those? Do you respond well to critical feedback? That's also an important thing because that's another skill that you have to learn for someone to say, "Actually, you've gotten it working," and this is something I had to learn, "You've gotten it working, but actually it's not so efficient the way you're going about this. Is there a better way you could structure it?" Having those questions brought up to you and learning not to get defensive, all of these things kind of come up in team programming situations. So I would say that's one of the best ways to discover your strengths and your weaknesses and be honest with yourself about them.

(12:53):
But also, and this is the hardest thing I think for a lot of people to hear, is to not try to fix them necessarily, just to be aware of them because some things, yes, need fixing. For example, a lot of my job is finishing things. A lot of my job is maintaining software. A lot of the time I do have to do these little fixes on a finished product. That's part of my job. So I do have to learn to enjoy and to find enjoyment in those things, but that doesn't mean that it's my personality. That doesn't mean it has to be my specialization. It doesn't have to be my strength and it probably won't be my strength and that's fine.

Alex Booker (13:31):
What you're sort of describing is that there's room for different people on different teams, and it's really got more to do with compatibility than any right personality or any right approach. When you go into a job interview, you're often sort of gauging each other, not just the company gauging you, whether there is compatibility there when they ask about your weaknesses. Oh yes, it's very common to want to say, "Oh, I work too hard or my life is my job."

Anna McDougal (13:54):
"I'm too much of a perfectionist."

Alex Booker (13:55):
"I'm too much of a perfectionist." Exactly. But at the end of the day, if your manager is a good manager, I think they should understand these things. They should understand that different people have different strengths and weaknesses, and a manager who's constantly trying to sort of put a square peg in a round hole, so to speak, and task you with things you're not suited to, that's a relationship that's kind of destined to fail. You'll never reach your full potential that way. And so understanding yourself in that respect can help you feel better about rejection in parts, think about it more like redirection. This just wasn't the most compatible approach.

(14:27):
But likewise, when you do go into that interview, now you know. They're just not interrogating you. You're looking for that mutual compatibility and being transparent and honest in that respect can be good.

Anna McDougal (14:37):
Absolutely. And that's exactly what I was about to say is that often when people get rejected, they think, "Oh, what did I do wrong?" And it's not actually necessarily what you did wrong. It might just be that they know, "Oh, we have a team full of introverts and we need someone with more energy to bring into this team." Or on the flip side, all of our people are really goal-oriented. Imagine a team full of mes. You'd hate it. You need some people who are a bit more chill, who can actually just work through a problem really slowly and thoroughly and who are going to ask the hard questions.

(15:09):
You need this balance of people, and we don't have that perspective when we're candidates. We can't see how the team looks, how the team is working, what the team is lacking, and the manager or the hiring manager hopefully can. So it is a thing where sometimes you don't do anything wrong. Sometimes it's just we have two or three people who could do this job. We know they could all do this job. Which one do we think is going to compliment our team the best? And the other thing they're often thinking is, "Who can I imagine working next to every single day of the year?"

Alex Booker (15:41):
That's a good question to ask yourself.

Anna McDougal (15:41):
One of the best pieces of advice I ever got randomly at a motorcycle lesson was someone said to me, "Don't see an interview as them interviewing you. You are interviewing each other. It's a business meeting and you're trying to see if what you have to offer and what they have to offer matches." Just think of it as business negotiation, as contract negotiation rather than as, "I'm this poor weak little soul. Please, please, please hire me."

Alex Booker (16:11):
"Please pick me."

Anna McDougal (16:12):
Exactly. Which it doesn't work in high school and it doesn't work in job interviews, so leave that attitude at the door.

Jan Arsenovic (16:20):
Coming up, what is a culture fit and how do you become one? But first, let's take a look at your social media posts about the podcast. On Twitter, dev Kei Ira shared our interview with Nadia Zhuk and wrote, "Give this podcast a listen. It's really helpful if you're changing career to coding or if you're new to coding. Well worth it." Thank you. Also on Twitter, Aishwarya wrote, "My most favorite Scrimba Podcast so far is with Sylvialynn Favello. I've already listened to it twice. My takeaways, have fun, be yourself, take breaks, and try new things. Whether you succeed or fail, you learn either way." Thank you, Aishwarya, for resurfacing this episode. It was a really good interview. I'll be linking to it in the show notes.

(17:05):
And by the way, I think I've fallen behind when it comes to keeping up with your LinkedIn posts. We had so many iTunes reviews that I just didn't have time to go through them, which doesn't mean you should stop leaving us ratings and reviews in your podcast apps. We really appreciate that and it's one of the best ways to make this podcast grow. But yeah, I'm just saying there's been a lot of activity on LinkedIn that I haven't really read aloud on the podcast until now, so I'll start doing it.

(17:34):
A couple of weeks ago, Alison Troller wrote a post saying, "Hi, folks, I'm starting the practice of learning in public. Learning in public is the idea of documenting on a public forum what you're learning as you're learning it. I heard about it on The Scrimba Podcast from Shawn Wang. What won me over about learning in public is that your primary audience is yourself. Learning in public reminds me of the evidence-based teaching practice of minute papers. At the end of a lecture, students take one minute to summarize the key concepts they learned and note any questions they still have. This helps solidify learning in the moment and helps the instructor, or you, in the case of a self-taught learner, figure out what concepts still need to be reinforced and what concepts to cover next. I'm already writing notes for myself. Might as well review them, clean them up, and put them out there in case they can help someone else."

(18:28):
This is amazing. Good job, Alison. I see that your blog looks really nice and I hope you keep writing it. By the way, if you're interested in learning in public, I'm going to link that episode of The Scrimba Podcast also in the show notes. If you would like to get a shout-out on the show, just post about it on socials as long as your Twitter or LinkedIn posts contain the words Scrimba Podcast, we will find it. And as I said, you can also leave us a rating, a review in your podcast app of choice wherever you listen to this if the app gives you the possibility to rate and review what your listening, please do it. We need social proof so that we can get bigger and better guests on the show.

(19:12):
Dave Mayer is the founder and CEO of Technical Integrity, a boutique recruiting firm famous for its culture-first approach. Technical Integrity has worked with big companies like Twitter as well as many mid-size startups. The culture-first approach to hiring benefits both the candidates and the employer. So if you get a job at a company, that means that your values align and you fit into their culture or at least the culture of the team you're joining. But what exactly does that mean?

Dave Mayer (19:44):
I'll add a little bit of an asterisk to the conversation in that it's not about culture fit, it's about culture add, and I feel like that's a big differentiator, because especially when organizations want to build diverse organizations, culture fit can, doesn't always, but can mean more of the same. So we like to emphasize addition. How do we add to the culture? How do we make the culture better? As a general answer to your question, obviously every startup is different. Every organization has their own culture and as they should.

(20:17):
Hopefully the startup, at least in our small microcosm of the world, has given a good deal of thought to their mission, their core values, and these kinds of things. If that's an afterthought as an organization, it's going to be really hard to build a culture. If the founders and the founding team have sat down and say, "Hey, these are the whatever, three to five things that really drive us as an organization, and these likely will not change over time," maybe they'll tweak them a little bit, but if the founders are clear that whatever, integrity, customers first, fill in the blank as to what those core values are, but everybody who wants to become part of the organization then understands, has sort of a baseline to work from.

(21:03):
The rest of the thought process is what really matters to the engineer? What really matters to the engineering team? What really matters to the clients? It's easy enough to find a Java developer. It's not easy to find a Java developer who genuinely cares about customer success, who genuinely cares about mentorship within the organization and growing if that's part of the internal values. And so sitting down with a client and understanding what their core values are, and then sitting down with engineers regardless of their level and understanding what's important to them, and then trying to fit the puzzle pieces together and say, "There's a match here, or there might be a match here, or there's probably not a match here." That's just sort of part of the discussion, part of the beauty of the matchmaking puzzle piece fitting that we do on a daily basis.

Alex Booker (21:55):
So am I understanding you rightly, culture is very much the same as the company's values? Could you say if everybody shares those values, you have a good culture fit, essentially?

Dave Mayer (22:06):
Certainly that's the baseline. If we all have an agreed upon framework to discuss that we believe that integrity and speed of development, and again, sort of customer success, those are the baseline in which we're starting the discussion, then everybody's at least starting from the same point in the race. There was a client that we worked with that had, we wrote a blog and we can maybe link to this. It's called the best engineering core values statement we've ever seen. They say, "Core cultural values, family over everything, serve others with purpose, build authentic relationships, value unique perspectives, challenge what's possible, and keep things fun and get it done."

(22:49):
So I think those are awesome, those are six, and then they have engineering philosophy. There's 20 bullets here that we won't go into, but the first one is have fun, and the second one is write code for humans first and computers second. These are all very, very intentional ways of looking at the world, and that's really key to finding the right person who's going to come in as a culture add.

Alex Booker (23:16):
What advice can you share for people to sort of understand their own values firstly, and then proceed to find a company that shares those values so you have a good chance of being a culture fit?

Dave Mayer (23:27):
I'm grateful for the question. It's a really critical one and not an easy one. I'll be 49 this year, so I'm a little gray around the beard, and I day in and day out have this conversation around what your intuition is telling you with engineers of all stripes and executives of all stripes. We also do executive placement in addition to the building engineering teams. Where I'm headed with that is that we talk all the time with people who are in transition or considering a transition regardless if they're straight out of school or they've been in business for 20 years. But the answer is usually the same, and it's a little bit Zen Buddhist, but it's true.

(24:07):
And my best answer is really, your intuition is never wrong, but it takes time and effort to listen, to understand and hear your intuition. And obviously, this is predominantly a conversation to your point around what is the best culture for you and ways I suggest to people to get clear on that are just really getting outdoors, getting into the gym, turning off your devices, getting away from social media, getting clear on what your gut is telling you as to, "I really only want to work with a mission-driven startup, or I don't care at the moment, I just need experience."

(24:50):
I mean, that's legitimate, but is it being true to yourself? Is the question. When you're whatever, 21, 22 straight out of university and you do genuinely just need an opportunity to pay the bills and get some experience, sure, that's an okay time to go to work for fill in the blank enterprise software company and get the experience. But the double bonus, the extra points are for when you can do both. When you can align yourself with an organization, whether it's a nonprofit or a startup that's working on something in Web3 or whatever it is that you're passionate about, and you can get the experience and they have the mission and value statement that aligns with you.

(25:30):
So you can do both is the message. Don't cut yourself short in saying, "I just need the experience. I got to pay the bills." That's okay, that's fine, but take it a step further. Get quiet, get clear with yourself, revisit if you haven't, Simon Sinek's Start With Why. He's got a great TED Talk and a great book, which really emphasizes your own personal why statement. What is it that you care about contributing to in this world and how are you going to manifest that on a day-to-day basis? And that means where are you going to put your time and effort? There's only so many hours in a day, so where are you going to spend it?

(26:09):
And is it going to be with a mission-driven organization? Is it going to be with an IBM? Is it going to be at Goldman Sachs? All of those answers again are fine, but are you truly listening to what is going to make you happiest when you get out of bed from your intuition, from your gut level need that is always talking to you, but if you're just sort of constantly scrolling social media or not creating the space to be open to hearing what your intuition is telling you, then you're probably going to end up in a job that's not the best fit for you.

Alex Booker (26:41):
A lots of people after being in the industry for a minute, they feel a bit disenfranchised with company values because sometimes they sound really appealing, but they are hard to interpret and arguably hard to live up to. My question is, as a new developer, how do you sort of genuinely gauge a company's culture and company's values? Because a lots of companies will publish a proud blog post saying, "Hey, here are our 10 values. Be honest, help each other." All these things. "Start small, dream big," but how do you sort of verify that they truly embody these values?

(27:16):
And by the way, it's not uncommon for people to subscribe to these values and think it's a great fit, but as soon as business demands kick in, for example, a competitor launches or there's a dip in revenue or something, sometimes values fall by the wayside, and it's really a case of ruthlessly working on the tasks. How would you go about gauging this as an interviewee?

Dave Mayer (27:36):
Interviewing is a two-way street and should be treated as such. That's not easy, especially for a new engineer who is potentially nervous in an interview situation. But at the same time, if the organization is just sort of peppering you with questions and not giving you an opportunity to do your own due diligence on the organization, on the team, on the management, maybe it's not the right fit. Organizations that genuinely want it to be a two-way street and care about what you bring to the table as well as how you feel about the situation, and even at a bare minimum, acknowledge the humanity of being nervous at an interview, I think you can sort of read the tea leaves to some degree.

(28:18):
To directly answer your question, I think I encourage people to ask difficult questions of their own during an interview process. Ask the interviewer, whether it's HR or the engineering manager, about ensuring that you have time to do so. Take the time to do the homework upfront about this organization, about their core values. Ask them difficult questions. Choose one or two pieces of their value statement or whatever it is that you have questions about and turn it into a critically thought out question.

(28:51):
I see on your mission and value statement that this is the way you look at the world. How does that really manifest itself in a day-to-day basis? And I'd like to hear an example. Further, I'd love to talk to some of your team members about this same question. This is absolutely a two-way street, and it is ultimately your responsibility to ask difficult questions to understand if it's the right fit for you, but also to some degree to keep the organization accountable as well. This is not just a one-way street.

Jan Arsenovic (29:22):
Now that we've even masked how hiring works, how teams work, how companies operate, what are the company values and why you shouldn't be sad if you and the company you're interviewing for are not the right fit, you just need to apply for jobs. Sometimes, however, job ads are not written by developers, and sometimes you can tell. Jason C. McDonald is a software engineering manager and business analyst with over a decade of experience in software engineering, and he thinks that you shouldn't get discouraged if you don't even seem to be meeting the requirements of a job.

Jason C. McDonald (30:03):
The problem is recruiters, whether they're HR employees internal to the company or whether they're third party, don't know how to code. So they think, "Okay, we need somebody who is an expert in Java and Spring, because we're working on a Java Spring application, therefore we have to have someone who knows Java and Spring." And of course, that's nonsense because developers know it doesn't matter if they know Java or Spring, if they know how to code and have worked with a GUI framework, they can pick up Java and Spring. There are some exceptions.

(30:36):
Sometimes you need an experienced senior developer who knows that language inside and out, but that's not the lion's share of applications. Most of the time, you just need someone who can craft computational logic effectively and knows how to engineer code, and that's all they really need. And so they wind up weeding out all of the qualified candidates, and then they're left with the pool of candidates who know how to lie really, really well. And then of course, they don't make it through the gauntlet when they actually have to interview with the real developers.

(31:06):
And so you wind up with all of these unfilled positions, and actually there are companies that I'm familiar with that are hiring and have hundreds, literally hundreds of open positions that they cannot fill, despite the fact that they have thousands of applications a month and they cannot fill these hundreds of positions because the recruiting processes are actually eliminating the qualified candidates. That's frustrating to hear when you're searching for a job, but it's also helpful because you know that if you know the recruiting process is broken, then you know the only way you're going to get into a position nine times out of 10 is to know somebody on the engineering team, which is why networking is so important.

(31:45):
If you know somebody on the engineering team and you can form a relationship with them, that can get you in even if there's no way into that particular team. If you have rapport with an engineer, engineers talk, go to the local user group for whatever language you're in, get involved with the community, make connections, make contacts, and make it known you're looking for work.

(32:06):
My current job, I got through my Python user group, and it was a referral of a referral of a referral. It was like a third-level referral into the company. That's not atypical. Once you get to talk to the developers, you will discover really quickly what I've heard over and over again is, "Oh, the job description. Those aren't hard requirements." They may be prepared to dismiss many or all of them because they didn't write those requirements, and most of them aren't going to matter. So knowing that when you're looking at jobs especially, and even though the recruiting process is broken, apply anyway. Apply if you think that the job sounds interesting and you're anywhere near the ballpark, even if it says, "Degree required." "Well, I don't have a degree." "You must know JavaScript." "I don't know JavaScript." Whatever.

(32:51):
If you think it is interesting, apply anyway. Seriously, just apply anyway, because sometimes you'll wind up getting one of those good HR people, or you'll get one of those companies where it's actually developers who are screening the applications, and you may actually have a shot at that, so don't let the job description deter you. Worst thing they could say is no, and then you're in the same position you're already in.

(33:13):
I think the important thing from a developer's perspective is to become proficient in the language that you are in or the language that you're working with already. And if you discover that you enjoy it, that you enjoy the tech space you're in, dig your heels in, get good at it. If you don't like it, go looking, find something else, experiment, play with different things. Find a sector you enjoy, dig in and learn that stack well, because a lot of times there's a bit of a risk-reward kind of situation with companies and training, and you can get away with more of this when you're a junior developer because they're assuming they're going to train you anyway.

(33:47):
Basically, they don't want to have to teach you basics of coding. If they have to teach you programming one-on-one, they're not going to be happy. But if you know the essentials, if you know the basics of the field that you're working in or the specialty you're working in, then a lot of times I think companies are willing to put in some training effort. That goes down the higher up in the ranks you move, so they're going to be willing to put less training in on a senior developer than on a junior. That said, it doesn't mean it's none, and it varies from one company to the next. There are companies out there with completely unrealistic expectations who when they say junior developer, what they really mean is a senior developer that we can pay $10 an hour.

Alex Booker (34:25):
Yeah, that's not okay.

Jason C. McDonald (34:27):
And then there are other companies that when they say junior developer, they mean the absolute bare basics and you're willing to let us mentor you. So again, it's part of that conversation. When you're interviewing with a company, it's important to remember that you're interviewing them too. They need to prove themselves worthy of you because you actually have something to contribute to that team, to that company while you are proving that you are a good fit for them, and that you have something to offer their specific team. And remember too, every team has a very specific puzzle piece, shape hole that they're looking for somebody to fill. And if it's not you, it's not personal. They're looking for somebody with some specific traits and skills that are sometimes hard to describe. And so bearing that in mind helps deal with what sometimes feels like continuous rejection.

(35:13):
But at the same time, this is a two-way relationship and recognizing what you need as a developer. If you're the type who needs to be given an assignment and given the latitude to work on it yourself, or whether you're the type who needs more collaboration and mentorship, knowing that is helpful when you're applying because different teams handle that in different ways.

Jan Arsenovic (35:36):
That was The Scrimba Podcast. Check out the links in the show notes to listen to the full interviews with Jason, Dave, Anna, and Tiffany. The show is hosted by Alex Booker, [inaudible 00:35:47], I'm the producer. You can find both of our Twitter handles in the show notes. Thanks for listening, and tune in again next Tuesday.