 started right on time because there's only 10 minutes between talks this morning, so don't wanna run over. Welcome. This is how to get and love your first Rails job. My name is Molly Morgan-Black. I'm just gonna give you guys a little bit of background on me. I've been working since I was 16 years old and I have had a lot of jobs in that time. I have done everything from food service to being a neuro-behavioral researcher at a large hospital in New York. I've also been a book editor at a small publishing house in New York, right on the heels of the recession, that was fun. I have been a project manager at an advertising agency. That face is because I really did not love that job. I've been a product manager for a small startup out of Tennessee, and at that point, after overseeing the launch of a product at that startup, I paused my career and I went back to school to study software engineering at National Software School, which was a six-month bootcamp. And I am now a junior developer at Life.io, working remotely, and I really love my job. So I've worked with some really big companies. I've worked for some startups and small companies. I've worked in the most corporate culture you can imagine and startup culture. I've done a lot of interviewing for jobs, and I've also interviewed a lot of people for jobs. This talk is really advice that I've learned sometimes the hard way over the years. And also I talked to a bunch of other dev bootcamp graduates from all over the country, getting some of their advice as they got their first job. So hopefully we can impart some wisdom today. So I broke this talk up into two pieces, how to be a standout candidate and how to choose a job you will love. So let's just get started. How to be a standout candidate. First off, you need to crush the sample project, especially if you're in a bootcamp, but also if you're graduating with a CS degree, you're gonna wanna have a project that is representative of you and your skill set. I think the most important thing you can do, first off, is to choose a project that excites you. The foundation of your project can be a technical problem of interest, a skill you wanna hone, or a project that aligns with professional aspirations or personal interests of yours. Personally, I think the best projects are a combination of technical interest and personal interest. I say this because the most, one of the easiest questions an interviewer can ask you is why did you choose this project? And ideally, the answer to that should be a window into who you are, what your interests are, what you think about, what gets you ticking, what makes you excited to program. The other most obvious question a person can ask you about your project is what problems you do encounter or solve while working on this. So you're gonna wanna choose a project where you have an interesting answer about what things, what your technical interests are, what problems you want to solve, and how you tackle a challenge. I've heard a lot of people say things like, well, I just wanted to choose a project I could complete within the two-week window. That's not a very interesting answer when you're in an interview situation, so definitely think about how can I build a project that says something about me and says something about my technical prowess. Also, it's really, really important to put effort into your whole project. The amount of times I've heard something along the lines of I'm not gonna waste my time styling when I don't even wanna be a front-end developer. I can't emphasize enough how important I think it is to not form premature opinions about the work you are willing to do, especially when you're three, six months into this. That attitude really only serves to hurt you in the long run. When you work not just on the things that really interest you, but on the whole project, you're showing a potential employer that you're willing to take on a variety of different assignments, that you take pride in your work no matter what you're working on, and that you're excited to learn many aspects of your craft. These are all really awesome things to show about yourself. So you're only limiting yourself by saying, like, no, I'm only gonna take on this piece, especially when you're getting your first job in Rails or any language, you may not necessarily get to work on the thing that interests you right off the bat. A lot of times employers don't even let juniors touch the back end for three to six months. You're gonna wanna show that you can rise to the challenge of taking on some front-end work. Three, consider the edge cases. Your users will not behave as expected. This is true both when you're building a sample project but also forever. So this is a good thing to sort of tackle right off the bat. The best way to figure out what's not working is to ask your friends or family to use your project, your app. They will find the bugs and not because they're looking for them, they'll just happen upon them because they will not behave as you expected them to. And I would get this feedback from people while you still have time to fix it. Don't sort of push your project to the last day before an interview or you have to present it and then get a bunch of people to check your project out. That's just a recipe for a lot of stress. Four, understand every line of code in your project. There are group projects. A lot of boot camps do group projects, especially for final projects. There's Stack Overflow. There are online tutorials. There are sample projects for maybe your teacher or Hardal or something like that. And so it's not unlikely that you're gonna end up with some code in your project that you did not write yourself. And that's okay because in the real world, what are the chances you're gonna work on an app where you're the only person writing code? Probably none. But you do wanna be able to actually explain every piece of your project. So if you are on a group project, I highly recommend getting together as a team and explaining to each other how your pieces work to the point where the other members of your team can explain the work that you did. If you grab some snippet off Stack Overflow and you can't remember why exactly it solves the problem that you needed it for, go back and read that, re-watch the tutorial that you maybe grabbed a snippet out of, and I honestly think the best way to learn how code is working is to play with it in the Rails console. So if there's something in your project, you're not totally sure how it's working, grab it out, put it in the Rails console, play around until it makes sense to you. Ultimately, you're ready to present your project when you can explain the whole project. So walk someone else through your code base before you have to do it in an interview process. Refactor, refactor, refactor. There's never enough refactoring you can do honestly when you're writing your sample project. If you find your code hard to read, it is hard to read for everybody. So here's some questions that you can ask yourself as you're thinking about how to refactor a project that you're working on. Are my method names just clear and descriptive? And of the job they should actually be doing, right? They should make sense not just to you, but to anyone who's reading your code base. Do each of my methods have one explicit responsibility? If your methods are taking on too many responsibilities, see if you can break them up, write shorter methods. And this will also help you with naming, by the way, because you don't wanna write your names having, trying to explain multiple jobs. Is my markup mostly logic free? There are some times when it's appropriate to have logic in the markup, but ultimately if you can get it extracted to a model or a helper do it, it will make for much cleaner code. Is my code comment free? If you have comments telling you what your code does, you are not done refactoring. Go back to the beginning, keep working on it. Write tests, this may sound like an obvious one, because sure your tests will impress interviewers, but that's really not why I'm telling you to write them. Really your tests will save you. If any of you are like the junior developers that I know you think that the very best time to add just like one more feature to your application is the day before you have to present your app to somebody. And then everything inevitably breaks because it always does. And if you have no tests, well, you're gonna be this guy. So write your tests, they will tell you what you're doing. And they will help you isolate your problems very quickly. All right, moving on. Ideally at this point you have crushed your sample project. And now you need to do the networking. I mean, come on, they look so happy. It's gonna be great. Yes, you have to network. Honestly, I wish I didn't have to tell you that this is the case because I hate networking, but it is. There are meetups, there are industry parties, there are hack nights, there are volunteer opportunities. Just put something on your calendar every week and then force yourself to go, make your friends go with you. Just do something, get out, meet people. But very importantly, no, you do not have to ask everyone you meet at these meetups for a job. I mean, I'm just so surprised by the amount of times I have heard people do this. But there's a really big difference. So a lot of times at these meetups you do have an opportunity to introduce yourself to the group. And the amount of times I've heard people get up there and be like, hey, my name's Molly Black. I'm a national software school. Like, I'm graduating in a month. I need a job, like a Rails job. Do you know anyone who's hiring for a Rails job? Or like, are you or your company? If you are, like, come talk to me. Really come talk to me. I really need a job in a month. Please approach me. No one's gonna do that. No one is going to approach a stranger that they have never met and offer them a job. So my best advice is just go to these things and be yourself. Just talk about the things you're working on, what you've been learning, what you're excited to learn more about. And more likely than not, once someone actually knows you, if they know a position that is appropriate for you, they'll probably tell you about it. But the thing is that it's not just enough to go to these things and be the person that's being seen at all these meetups. You have to actually make real relationships. So once you start getting comfortable in your community at these meetups, meeting people, start asking people out for coffee. And honestly, this doesn't even have to be that job getting oriented. It can be just asking someone about how they started their career in tech. What their first job was like, how they got that job. And the thing is people really like talking about themselves. So they'll probably need more than up for getting a coffee or a drink with you. And then all of a sudden you start actually having real relationships in your community and people will keep you in mind if they hear of a junior Rails job that's opening up. Another piece of advice I have in terms of the networking is that if you really love a company you already know that you think they're amazing and that you would just kill the work for them, reach out directly. Honestly, I think I've gotten one job in my life of the very many jobs I've had from a job posting. In general, I just write a letter to companies that I think are interesting. I introduce myself, I ask if I can get to know someone there, take someone out for coffee, come in for more information. Depends on the situation. Sometimes you have to do some light stalking to get appropriate email addresses. Just do it. Honestly, the worst thing that can happen is someone you never hear a response. And that's kind of like not reaching out at all. But often if you write a really awesome letter and you express a lot of interest in what this company does, you will hear a response. And then all of a sudden you have an in at a place that you're really interested in working. So I'm gonna leave networking there and moving on to being the cover letter. So what do I mean by this? The cover letter, unless you have gotten a job through a networking situation, is your first impression. And I think the most important thing you can do is make it you. I'm gonna read you guys a classic opening to a cover letter. I've definitely written this cover letter back in the day. I'm so excited to be applying for the position of junior Rails developer at Life.io. I feel that my past experience and unique skill set are perfectly suited for this exciting opportunity. Okay. So the person who's receiving cover letters may be receiving up to like 100 cover letters. And if your cover letter sounds like this, you sound like everybody. And your job in a cover letter is really to stand out. Stand out the subject line, stand out the letter. If you actually embrace your voice, you will stand out. And by the way, this doesn't mean be really quirky and ridiculous. This just means make infuse your own voice into the letter that you're writing so that you sound like a human being. And this isn't actually that easy for everybody. So I would recommend that you read your letter, any letter you're saying to a company out loud. If you're not sure how you sound, when you're reading it, you can sort of say, does this sound awkward, stilted, boring? You guys just heard me read the beginning of a cover letter. It sounded terrible. If you sound like that, throw it in the garbage, start over, and keep working on something that sounds more like your authentic voice. And you'll know it sounds like your authentic voice when you read it and it sounds familiar to you. Never ever copy and paste. Again, for the cover letter, never do this. If you're like, I need to copy and paste, then you're applying to too many jobs. Only apply to jobs you really want. Put a lot of work into those letters, into that resume. Because if you're applying to a lot of jobs, some of which you really want, some of which you kinda want, some of which you're like, ugh, I just need a job, then you're diminishing the quality across the board of the cover letters you're writing for the jobs that you do really want. So I would honestly pick like five max and put a lot of work into those. With the copying and pasting, I say this because I've received as someone vetting potential employees letters with either the incorrect company name or the incorrect position in it. Because they're clearly copying and pasting and filling out those different pieces. I've never responded to someone who sent me a cover letter like that. And honestly, I don't know, even if they corrected the problem of it, it just says that they're not that interested in what your company does. So if you end up in the position where you've accidentally put the wrong company name into a cover letter for a company that you actually wanna work for, that really sucks. So don't do it, because you probably will never get to work there. Get a proof reader. All I really have to say about this is that a typo in your cover letter is just as bad as a typo in your code. And we all know that typos in your code break things. So don't do it. Get people to read your stuff. Moving on, you guys have all written amazing cover letters at this point. People have expressed interest in you. And it is now time to interview confidently. First off, and really the main thing I just wanna say about interviewing confidently is don't sweat the technical, even though I know you will because everybody does. But let's try to demystify the technical interview just a little bit. Potential technical interview formats. Questions about your sample project. Define a term or principle or design pattern. Solve a whiteboard problem. Maybe pair programming or take home assignment. These are kind of classic. The first four are ones that you're gonna actually have to do in person. Which can be a little scary. So the first thing I would recommend, especially when it comes to problem solving, is just to vocalize your thought process. You may be asked to do a whiteboard problem and you really don't know how you're gonna get from point A to point B. But you can start talking about what steps you're thinking about taking and how you're going to approach the problem. But I think what is really important in the technical interview also is to be okay with not knowing and being excited to learn more. Because it's totally possible you're gonna end up with a question where you draw a blank. Or you're just not really sure what that term means. Honestly, I would express to all of you that you should just embrace that you can't know everything right now because that's going to be the rest of your life as a programmer. You just cannot know everything. So if you're in this process, just sort of see if you can talk through like, hey, I don't really know what this thing is. But I would love to talk through it with you. I would love to hear an explanation. I'm definitely gonna look it up. I'm interested to learn about this thing. Because honestly, that's the best thing you can do. Don't stand on a whiteboard with no idea what you are going to answer and just sort of throw the pen and give up. At least try to create some rapport with your interviewer. Because ultimately, the interview process is all about building rapport. Yes, people are assessing you for whether or not they think that you have the aptitude for the job. That's just a given. But they're all so assessing, can I work with this person? Can I solve problems with this person? Can I share knowledge with this person? Are they someone who seems ready to learn? Are they someone who seems like they're gonna be a team player? And honestly, I think in a lot of situations, if you have people, one person who's slightly more competent, but one person who's clearly going to make a better teammate, people usually go in that direction. So I highly recommend just trying to build rapport with the people that you're interviewing with. Okay, the other piece of interviewing confidently that I wanna talk about is selling your past experience. A lot of people, actually I would love to know who in this room is coming out of a Dev Bootcamp situation. Okay, all right, some of you. So not everybody coming into this field anymore is a CS major, went straight through college, knew what they wanted to do. A lot of you are coming from past jobs that feel seemingly unrelated. But the thing is that we bring other things to the table as people coming from bootcamps after having changed careers. And I'm just gonna give a couple examples because I think this is really important. So I know a lot of people who've come to this from food service. And they've been almost embarrassed to share that. Like they don't want the people in the interview to know that. But honestly, I think food service is like incredible background experience. You are working for basically as part of a machine where everything in the background is like chaotic and sort of ugly. And what you're presenting though to the end user, so to speak, the people at your restaurant or at your coffee shop is a beautiful product that seems to have come out in this seamless, well-timed, really delightful way. And a lot of computer programming is like that. We aren't showing our users our code. We are building something that ultimately should be seemingly easy and beautiful at the end. So I think that people in food service have a lot of user experience know how, even if they don't know that they do. I also know someone who came to this from a carpentry construction background. This is a person who did not talk a lot of talk, like some of the people in boot camps do. He was a person who just really understood what it meant to build. At the end of the day, he was a person who just made things because he always knew that he was going to be judged based on what he made. And he didn't think he could sell that. And I was like, what are you talking about, man? You bring a lot to this. This is a person who is a real true maker. I come to this with a writing, editing background, and I know a number of other people who do as well. We are people who already care about word choice and syntax and grammar and structure and readability and naming. And that's really relevant. You still have a learning curve to get to the point where you're writing beautiful code, but it's something that you're really striving for. So I think that's something you bring to the table. If any of you were sitting there thinking like, yeah, but I was this other thing and it's really not relevant, come talk to me at the end because I cannot assure you that it is. And I would love to kind of help you discover how your background is, can be sold to your future employers. So I'm moving on to the next half of my talk, how to choose a job you will love. I think this part is almost more relevant because you probably have heard a lot less about how to vet the companies that you're interviewing with. And I think this is just as important as being a standout candidate. So the first thing is narrowing your search because in the tech field, you're not just in the tech field. You might also end up in like finance or healthcare or food or travel. Most companies these days are a company that does one thing and also happens to be using technology. You could end up working for a huge corporation or you could end up working for a startup. There's a lot of things to be thinking about as you're starting to try to figure out where do I even apply for a job? What do I want? So the first part of this is really about asking yourself some questions before you even start the interview process. I think the most important question you can ask yourself is what problems am I interested in solving? An example of this is I used to work in hospitals and a problem that I was interested in solving and have been interested in solving for a long time is how to make healthcare more proactive and less reactive. That's a personal problem I'm interested in. Your problem might be technical, it might be philosophical, it might be personal. But I would literally write down a list of problems that you're interested in solving before you start applying for jobs because this will help you start thinking about industry and where you might want to work. Do I want to wear many hats or have fewer more well-defined responsibilities? This is a question that may help you discover whether or not you want to work for a smaller company or a larger company. A lot of times startups or companies that are right past the startup phase, you have to bring a lot of different skill sets to the table or at least be willing to play a lot of different roles. Larger companies where there's more structure and things have been more well-defined, you may have a much more narrower job responsibilities. Either way is fine, it's really just about what is right for you. So I would definitely think about that as you're thinking about size of company and what's right. Do I want to gain breadth of knowledge or depth of knowledge as a junior developer? This is kind of a question that will help you suss out whether you'd rather work for a product company or an agency, consultancy. In a product company, you're gonna gain a lot of depth of knowledge. You're gonna be working on probably a lot of the same piece of a code base or the same code base in a way where you're gonna get to know it and sign it out. At an agency or consultancy, you may have a new project every six months and that can also be really awesome as a junior because you're gonna get your hands on a lot of things. So that's, again, just personal preference. What am I looking for? Can I succeed in a remote position or would I rather work on site? A lot of people say or warn juniors against working remotely. I work remotely, I love it. It's right for who I am. I'm a person that does really well when I close the door and can focus. But then I also have Slack to reach out to my team. So, but I would say in a remote position, you need to be a person who is, you know you're accountable to yourself. You know that you're not gonna be distracted by your TV during the middle of the workday and that you can be proactive about reaching out for help when you need it. In terms of working on site, you may just be a really social person who needs the interaction. Maybe you wanna work in a team environment where you are pair programming in person during the day. It's just really, again, up to preference. So I think these are really important things to know about yourself before you just start throwing applications out into the world. So I'm gonna leave that there. And now at the point when you're actually in an interview process, my best piece of advice is to interview potential companies as thoroughly as they are interviewing you. This is about building a relationship, right? So it's not just like, oh God, I hope someone hires me. It's also about like, this company is looking for someone who's going to fit their culture and their needs and you need a company that's gonna fit your life and what you're looking to get out of it, especially as a junior developer because this is going to, the first company you work for is going to greatly impact your career moving forward. So things to look for in a company as you're interviewing them. Code quality. As a junior dev, the sort of coding culture of the company is going to greatly impact how you code. So if your company's not writing tests, you're probably not gonna write tests. And if they don't do a lot of refactoring, you're probably not gonna be doing a lot of refactoring. So I think it's really important to suss out the quality of code that the company are gonna be working for. Questions you can ask potential employers. How does your company manage technical debt? What does the current code coverage look like? Are they writing tests? To what extent are they writing tests? What is the code review process? How many eyes are on the code before it goes to production or to staging? How is your code going to be reviewed? Are you gonna get feedback? Can you tell me about a problem your team ran into recently and how it was solved? So are people sort of left to their own devices to figure something out that they run into? Or does the team kind of drop everything and all work together to solve a problem? All these questions are really just meant to get you some insight into how a company is writing code because while there is sort of the engineering first model in Silicon Valley, that's just not always true. Everywhere you're gonna work, some companies have sort of less, more reactive tech signs where they have realized they need a tech division sort of in a way where they're like, oh, we have to keep up with the market and they don't necessarily have the best practices. And so while a lot of companies do, don't assume it. So ask these questions before you take a job. Oh yeah, and another good one that not everyone's gonna be able to provide for you is to see if you can get a demo of the code base. So if you can get a walkthrough either of a project they're working on or a piece of code, that's gonna give you a lot of insight into what you're gonna be working on. Growth opportunities. Again, really important as a junior developer. And some people are afraid to ask about growth opportunities because they don't wanna sound like self-serving in an interview setting, but it's very important. So questions you can ask, how does your company foster learning culture for its developers? What are they doing to help people move forward? If they don't have an answer to this, they're like, oh, we're kinda working on that. That's something to consider. Has this team of developers been involved with mentoring juniors in the past? Are you the first junior they're hiring? Are they sort of taking a chance on you? Are people excited about the prospect of mentoring a junior? Or do they see it as like, oh, this is gonna cause some slowdown while we try to catch this person up to speed? Try to get a sense of how they feel bringing you into the team. Very important, the work. What kind of work does the company envision you doing? Again, I mentioned earlier, sometimes junior devs don't get a chance to work on anything that could remotely touch the database for three, six months. That's probably something you're gonna wanna know upfront. What do they see you working on right off the bat? So I think a good question is, what kind of work do you envision me doing in the first three months, six months, a year? This will also give you a sense of what pace they hope that you will grow at. And just if the work that they are proposing that you do is of interest to you. Well, I work primarily alone on a small team with a mentor. Again, these are personal things. Like maybe you really want to work alone. Maybe that's how you problem solve best or how you feel most comfortable. Or maybe a team environment is exactly what you're looking for. So again, just get a sense. Well, I help with feature planning. Not everybody is excited about this prospect and some people really want to do this. So get a sense of whether you're gonna be handed a task once it's completely defined or whether you're gonna get to be a part of feature generation and what the roadmap looks like a little bit. Learning environment. And this is different than growth environment. This is about how you feel that you will learn in this place. I think a great thing to assess is how you feel when you are leaving an interview, especially a technical interview. Do you feel like, yeah, I feel good about this team. I feel like I'm gonna learn with these people. I feel like I can grow from these people. Or do you leave feeling like, man, I feel so dumb. I really didn't answer the question I think in the way they wanted me to or really feel bad about not having known that. Because I think if you get a job offer from a place where you felt really stupid or unconfident leaving that interview process, that may tell you a lot about how you're gonna feel working there. And as a junior, you're gonna wanna be able to learn from the people around you. You're gonna wanna not be too intimidated to ask the questions that you need to ask to get to move forward on problems or whatever you're working on. So I highly recommend thinking about how you feel when you are leaving the interview and if that is a positive feeling. Do you feel, do you see potential for a mentoring relationship? Ideally at the end of an interview process you've met at least some of the people you'll be working with. Is there anyone there who you feel like, yeah, okay, that's a person that I'm really going to be able to learn a lot from. And if that person seems excited to be working with you. I just think that's one of the most important things you can get out of your first job as a junior. So, okay, you've killed the interview. You've done amazing through this whole process. Good job, everyone. So you now have to actually weigh the offers that you've been given. The first thing I wanna mention is considering the perks. Meaningful perks, vacation days, sick days, parental leave, flexible work schedule, option to work from home. Do these companies that you're looking at offer these things? I think this list actually boils down to, does this company trade its employees like human beings? Sure, maybe you're gonna be working a nine to five schedule in general, but you're also a human being who maybe will get sick, or your kid will get sick, or you'll have to meet the plumber at the house one day, and there's a really big difference between a company who's like, yeah, of course, you're a person, you have to deal with these things. And a company that makes you feel bad every single time you have to ask for a normal human inconvenience. So try to get a sense of what kind of company this is, and how they're going to make you feel when you have to just be a person. And I think this list also boils down to, does this company trust its employees? Usually companies that say, yeah, of course, your kid's sick, like work from home today, it's not a big deal. This is a company that trusts that you will do your job whether or not you are under supervision, so to speak. I think the answer to this question should always be yes, but a lot of times it's not. A lot of times companies treat you like you're sort of an adult child that will not produce some less being watched and micromanaged. So try to get a sense of how the company views its employees. I think one of the best ways you can do this is to ask for the employee handbook before you actually take a job. If they don't have one, that's a red flag, because they're not thinking a whole lot about how to treat their employees. If they're not feeling good about giving it to you, that's a red flag, because they should be really proud of their employee handbook. It shouldn't have a lot of policies, they feel awesome about. Ideally they've put work into that. So that's a really good way to assess how the company, especially if you don't feel like you're getting the answers that you need. Let's talk about superficial perks for a second. Free food, drinks, beer on tap, ping pong, like hip office stuff. I actually love all the things on this list, right? Except being beggars, which are really dumb, but I've also worked at a place that had all these things, and I remember when I was being offered that job, they told me like, if you ever have to work after six o'clock at night, we're gonna pay for your free dinner. And I was like, wow, that's so nice, that's so thoughtful. Two weeks into the job, I've never left before six, free dinner, and I usually didn't leave before nine, and it could go on until whenever. And free food suddenly didn't feel like much of a perk anymore. I was like, cool, free dinner, I have no life anymore. Sometimes superficial perks like this can really mean that a company is trying to create an environment where you want to be there all the time, or are there all the time. It doesn't always. But I would say be a little bit skeptical about a company that's like really pushing this stuff and not pushing a lot of the more substantial perks that actually make a meaningful impact on your life. Considering the monies. Before I really say anything about this, I have a sensitive aside. Some of you may have a lot of student debt or went to a boot camp where that was a really big financial risk for you, and you had to both not earn money while paying for an expensive education. So if you're prioritizing money, if you're like, whatever, I'm gonna get three offers and I'm gonna take the one that's the most amount of money, that's fine. I'm not telling you what to do, but this is a job about getting, or this is a talk about getting a job you love. So I think this is the list for optimizing for happiness. Number one, being treated like a human adult. I wish I didn't have to even put that on this list, but I do because I've had jobs where I'm not. And I think a lot of people have as well. So that's baseline. The next thing is mentorship and learning opportunities. As a junior dev, this is going to be your best investment in yourself. If you are working for someone that you feel that you can learn from, that you feel helps you tackle new problems, helps you learn, helps you take on new challenges, that's probably the thing you should optimize for, honestly. Code and culture next, again, we talked about this. This is about if you are at a company that has great practices, you're gonna learn to have great practices. So I would definitely optimize for that. Excitement about the work. You would think that wouldn't land at number four, but honestly, if you don't have one through three, it doesn't matter how excited you are about the work you're doing because you're gonna be miserable or not learning a lot. So I would definitely optimize for the first three. And then if you're really excited about the work you're gonna be doing there as well, that's an awesome plus. Money I put kind of at the bottom because I think if you can't get one through four, you're gonna be sacrificing some happiness for money, which honestly, if you get one through four, you're gonna be such an awesome dev, like one to two to three years later, that you're gonna get the money in the next job. You're gonna be able to get that high salary. So I really wouldn't optimize for money, but again, everyone has their own situation, so you have to make a personal choice on that one. Ping pong's a joke, but I really do love ping pong. So I put it on there. That's all the time I have. I hope you guys leave this talk being like, yes, I'm going to be a champion. I'm going to do this well. I'm gonna write an awesome cover letter. I'm gonna go nail the interviews, and I'm gonna really, really think about culture and what will make me happy before I take a job. Again, my name's Molly Morgan Black. You can find me on Twitter at Mollymoblack. You can find my company at Life.io. I'm also a really nice person, so if you see me around, please come talk to me. I would love to talk to anybody who has any questions about going through any of this process, because I know it's hard. And I hope you all do really well. So that's it. That's all I got. Thanks.