 We're going to talk today about how your work in open-source can and should help you get a great job, advance in your job, grow throughout your career. This is my fourth time being here at DevConf. This is my vintage DevConf scarf from 2016, so really happy to be back here again. I've given a lot of different talks here at DevConf, usually on the community track, things like leadership, influence, stuff like that. But one thing I've noticed over and over again is the hallway conversations you have afterward. I meet so many people who are students or maybe work in a day job but don't get paid to work on open-source. And they spend a lot of time and energy contributing to open-source, but they do it because they care, because they're interested, and they're not necessarily getting much of a career benefit out of it. And sometimes it's hard for them to see the connection between the job they're applying for and the work they're doing. And that's a real shame because a lot of what you learn in open-source development and open-source projects is skills that are really needed in your day job. And so we're going to talk about how do you make that connection when you are talking to your manager or when you're talking to a hiring manager? How do you help them see that what you do in open-source actually is giving you skills that are of interest to them? But first, a little bit about me. So almost two decades ago I was a student in a university, much like this one. I had a lot of different interests, but I didn't really know for sure what I wanted to do for a career yet. And so in the United States, university is a very expensive thing, and so your parents want you to figure out what you're going to do pretty quickly. And so I was taking some different courses trying to decide, and I remember taking an anthropology course, which is kind of the study of human cultures and how people come together, how they make connections, shared history, shared meaning. And I went home and I said, oh, wow, Dad, this stuff is so interesting. Just what makes people work together cooperatively or go to war with each other? How do cultures form? How are they sustained? And my dad said, well, no one's going to pay you for that. So study that, but maybe the computers would be a better way to go. You like those two and people will pay for that. And so of course, like most parents, he was a little bit right and also a little bit wrong. Nobody was going to pay me for that back then. But technology ended up giving me a path into a career where that is actually now a lot of what I get paid to do. It's to think about culture and what kind of culture does a company want to have, how do you sustain it, how do you help people work together within it when they don't get along. So I started out as a web developer and ultimately I focused today on Red Hat's culture. That means a lot of things. I'm a people watcher, catch herder, conflict resolver and reluctant dispenser of free and probably dubious and bad advice. So you get what you pay for and money back guarantee today. And so I think that my story is actually a really good example of what I want to share with you today, which is that career growth is not a steady straight up and down ladder kind of climb. I think that's often how we think career growth happens. You look at someone who has the job that you want or seems to do really well and you think, well, they must have decided how to get from where I am to there and just done it. But actually it's a lot more like rock climbing. Does anybody climb rocks? Yeah, a lot of you. So you know you kind of from the ground have a sense of maybe which way you're going to go up, but as you're climbing you're really only seeing the next couple footholds, the next couple handholds. And so sometimes you go a little bit in one direction and you realize, oh, this isn't going to quite take me as far as I thought. So maybe I move a little bit down and then off in a different way. And that really is what career growth is like. You kind of move in the direction of what interests you and you figure out, can I make more out of that? Or maybe not, but it was a helpful experience along the way. So as we think about that, one of the things that I love about Red Hat is you can email the entire company, all 15,000 people who work there. We have a mailing list called MemoList. It goes out to everybody. And so as I was working on this talk I said, you know, I have a couple ideas of what I want to do, but let me ask, you know, a lot of other people who work here, what do you think? So I said, hey MemoList, I'm going to give a talk at DivConf next week. Tell me how Open Source helped your career. So I made a couple stories. Okay, thanks, bye. And a few minutes later I had 30 plus responses, really, really long emails full of stories. And I said, wow, you know, thanks everybody. This is great. I'm all set. I've got what I need. And then they just kept sending me stories. And so I said, no, seriously, this is good. I've got enough. 100 plus later I had lots of really fantastic stories and had to kind of cut it off and write the talk. But huge shout out to everybody at Red Hat who sent me their stories. I think it really speaks a lot to the passion people have and how much Open Source does help people in their careers. I was really looking for what are the skills that you have in Open Source or you gain in Open Source that you might not be putting on your CV. You might not be talking about it a job interview. But people sent me all kinds of inspiring stories about how Open Source helped them in ways I didn't expect to. So I'm going to share a little bit of that with you before we dive into the practical stuff. So I got stories like this one from Alicia. She works in documentation for Ansible. And she said, you know, contributing to documentation is actually one of the best ways early or midway in your career to really demonstrate skills and support Open Source projects at the same time. So even if you're brand new to a project, you can make a contribution. You often, as a newbie, can see gaps in documentation that somebody who's more experienced can't see. They already know the undocumented stuff. And if you're more experienced, you can contribute more complex use cases. You can add details in that other people might not know. And really, anybody can fix a typo. So there's somewhere for anybody to start. It's a good way to kind of find your path in. And what she pointed out that I had never thought about was a documentation pull request can showcase a whole bunch of different kind of skills but it's public, so it's something you can share. You know, if you're early in your career, you're trying to show I have a lot of ability but you don't have much out there, you can show your writing skills. You can show your technical understanding. You can show familiarity with things like source control, right? Editing tools, different platforms, all kinds of stuff. I thought that was really interesting. She shared a lot about kind of how her path moved through that. Another really, really inspiring one from Adam Williams, anybody know him from Fedora? Long time Fedora guy. I've known Adam for years and I didn't know this about him, so I thought this is a fun one to share. Adam said, you know, the only jobs that he had before he started at Mandrake, Mandrebo, which is where he was before Red Hat, were Paper Delivery Boy, Library Assistant, Bookshop Assistant, Supermarket Assistant, and Administrative Assistant. I have a theme developing there, Perpetual Assistant, right? Adam's degree is in history. It's what he studied in university. He doesn't have any formal training related to software development. In fact, didn't even learn to write code until about 2014, which I found shocking if you've ever seen the work that he does in Fedora. In fact, Adam started out as one of those people who just hangs around forums helping people out, new users trying to figure things out, and ultimately he wound up doing that as a job for Mandrebo. Then he developed into release management, then into QA for Mandrebo, and then ultimately Red Hat where he is today. So really neat to see how you can kind of move in through open source, follow what interests you, and potentially build a pretty awesome career out of it. Felipe is a local here now. In the end of high school, he started contributing translations to Genome. That's an easy way for many people to contribute who may not have a lot of technical knowledge yet. He didn't know how to code, but being able to see the code and look at it kind of grew on him. And so he decided he was going to study computer science when he went to university. Then he started contributing to, the code that he contributed to Genome actually helped him get an internship with Google Summer of Code. And I loved his stories. His internship gave him the chance to travel abroad for the first time. It was the first time he ever flew on an airplane. First time he ever spoke at a conference. Really life-changing experiences for him. And he said, you know, he didn't have those kind of expectations for himself growing up. It wasn't the kind of life he even imagined he could have someday. Four years ago, he moved across the ocean to Bernal and wanted to really start a new life over here. Still working on the Genome and the desktop team at Red Hat. And for him, it's been a dream job and it goes all to free and open source software. So you can imagine just story after story like this pouring into my inbox. I was like, wow, this is incredible. And there were so many more. I had to cut like six of them out of here so that we actually talk about what we came to talk about. But if you ever get a chance to talk to Seth Conlon, or Kenlon, he has a really interesting story like this. And what I would encourage you to do is talk to some of your heroes in the community. Talk to some of the people who you would really admire kind of what their career looks like. How do you get started? How do you end up where you are? You might be really surprised to find out kind of how they got their path in. And so I wanted to ask in the room, because I know we have a lot of folks who have been contributing for a long time, what stories or examples would you add? How did you kind of find your way into open source? How has it helped you in your career? Everybody's avoiding eye contact. All right, 9.32 early. Fine, we'll go practical tips. All right, so kind of break it down, right? How do you actually do this? I think there are three basic steps, right? I mean, good presentation has three steps, so I think number one is get the experience. If you don't have the experience, there's not much you should be selling about the experience you don't have. So that's the easy one, start contributing. Most of you probably are already doing that. Then from there, it starts to get a little bit trickier. So how do you summarize that experience that you have in a very succinct, meaningful way that other people can understand? So what does it look like on your job application, on your CV, when you're having a very brief conversation with somebody about a job? How do you talk about what it is you do in a way that they can see the connection to what they're looking for? And then the third thing is, how do you then illustrate that? When you have a chance to talk more about it, how do you bring it to life for people? What are the stories you share? What are the examples you share? What are the pull requests maybe that you share as examples of your work, right? So pretty basic stuff, but it's kind of a one, two, three. So as I was asking Red Headers, tell me about some of the skills that you've got in open source that maybe you didn't recognize you were getting along the way. These are the kind of things to go back and look at your CV and say like, does this stuff actually come through? Are there things that I've gotten really good at in open source that I don't actually have on my resume today? And often that is the case. You tend to jump straight to the technology, right? Like here are the technology skills I have. We don't necessarily move into what are some of the other skills that they might actually be looking for. And I'll tell you, one of the most interesting things to me is when you ask people what they're looking for in a prospective employee, what am I looking to hire? They'll usually start with the technical stuff. And that's great, right? That's baseline. You have to have the technical skills. If you don't have those, the job's probably not going to work out for you. But if you look at the difference between somebody who really excels in a job and somebody who gets kind of stagnant and they can't really grow or even doesn't work out so well, it's not very often the technical skills that are the problem. It's can I work with this person? Does this person have the vision that I need to be able to understand the bigger picture of what we're doing here? Can they communicate with others effectively? Does nobody want to work with them? Because they're really difficult, right? There's a lot of things like that. And that's the stuff that you don't usually get feedback about in a job. You just get stuck and you're not moving forward. So that's where I think open source is a really, really interesting way of developing skills that people don't always put into words. So one that jumps out to me is, I kind of try to put, okay, how do you take skills that you have in open source and put them in words that somebody who's not an open source enthusiast would understand. So one of them is a global or cross-cultural perspective. Many, many companies today, no matter how small they are, I'm talking like a couple hundred people, they're often distributed across different locations. And being able to understand that your way of thinking, your way of seeing the world, isn't necessarily the same as everybody else's, isn't necessarily the one right way of seeing things. Being able to communicate differently to different people matters a lot. So what that could look like on a resume is saying, look, I'm a team player who has experience working across different cultures, different groups, different time zones. You would be surprised how hard that is defined and if you are a globally distributed team, it's really, really important. The second one is stakeholder management. So in open source land, what does it look like to manage expectations of different people? Right? Most of us, if we are contributing to a project, we all the time have, people have very strong opinions that conflict with each other. We have different opinions about what should happen from here. We have very strong, you know, this is the right answer, no, that's the right answer. And most of the time, the longer you work in a community, the better you get at having conversations with people who disagree with each other. Well, guess what? In your day job, that is often one of the most challenging things that people face in technical roles, but in any role, is I have people who have different opinions about what needs to happen here. Often there's not very clear lines of who's actually in charge, or maybe one person's in charge, but another person can kind of subvert it if they don't like it. So being able to work cooperatively and talk to people about, okay, here's what you want, here's what I want, what are we actually going to do here, is a really valuable skill. And it's one of those things that I think comes to you over time and open source. You get better and better and better at this if you're in a pretty busy project, but you don't always think to talk about it in interviews. So thinking about, this is something that you're like, yes, I do this in my project all the time and I've never had a conversation in a job interview about what that looks like. Think about some of those stories, right? How would you share them? Third one that jumped out lots and lots of people sent in is being able to give feedback that is useful, that is respectful, that is helpful, that other people are open to hearing and on the flip side being able to receive feedback in a way where you don't get upset, you're not defensive, you just consider it, right? Everything from code review type feedback to feedback about design, feedback about UI, right? Being able to do that is surprisingly a difficult skill and it's really, really something that gets in people's way as they're trying to progress in their career. Being able to share that this is a skill that you have and talk about examples of where you've done that goes a long way in an interview. So I thought, okay, how do you make this show up in just a couple of words, right? So typical CV, what you might have in a little summary at the top of yours is something like, hey, I'm a Python engineer, one year of experience in designing and developing web apps. Great, that's awesome. It's a good summary. However, if you're a Python engineer who has a lot of experience in open source and some other skills, you could look at what are they looking for in this job and what do I really want to highlight for that? If you want to kind of tailor your CV to fit the role. So let's say that right away you look at the job description, you look at the company and you see, okay, this is clearly a company where they work across multiple teams. They talk about you're going to have to be able to, you know, work with customers and work with apps, right? You're going to have to be able to do these kinds of things. I might say I'm a Python engineer with two plus years of experience because let's take some credit for what we do in open source here. If I've been contributing to open source since I was starting university, I probably have at least a year of experience if I spend a lot of time on that. So two plus years of experience working across different technologies, different teams, different time zones to develop web apps. All of a sudden I'm a little bit different from every other Python engineer with one year of experience who has their resume sitting in front of you. Or maybe, maybe I do a lot of work on OpenStack in my free time, but it's not necessarily connected to my day job. I could talk about I'm a Python engineer and an OpenStack contributor who has two plus years of experience in web app development and code review. If I have a maintainer, I'm probably taking a look at people's code. So think about what do you do in open source and in that side of your life? What do you do in your day job and what are the commonalities between them? And we'll talk about how to do this comfortably. You don't want to do this in a way where you feel like you're deceiving someone. You don't want to be dishonest about your experience, but you do deserve to take credit for what you're doing. So before I jump into other practical stuff, what other skills would you add? What are the things that you see people develop in open source plan that actually are really helpful in the stuff that they get paid? Communication skills are the right things. So communication, how to write stuff. Say more about that. Describe not just what you did, but maybe your motivations or what you're trying to accomplish. Yeah, so I'm going to repeat it back because I know we're recording. So what Tim said was being able to describe not just what you did, but what your motivations were behind it, what you're trying to accomplish, right? And then to the bigger picture of what other people are trying to do. You know, it's interesting. One of the things that came up was somebody said, you know, the difference often between a okay pool request and a great pool request is the little bit of explanation about what you're trying to achieve with it makes all the difference for the person who's reviewing it. It's a good example of where you develop a lot more communication skills inside what you do in open source than you might even in your day job unless your day job involves pool requests too. What other skills? Time management because of time zones. Say more about that. Yeah, so go ahead. That's great. So I'll paraphrase for our mic here. What he said was time management. Often when you're working across time zones, the flexibility to schedule things early in the day or late in the day to accommodate other regions really develops your ability to get things done in a compressed amount of time, right? Because if you're just adding on those meetings on top of the work that you're doing full time, you're probably going to burn out. So learning how to adjust that. So I'll hand over here. Issue reporting and troubleshooting. Issue reporting and issue troubleshooting. So say more about that. Well, it really helps a lot if you see that the person is a higher manager to see that the person knows how to file an issue like with all the information even maybe with the reproducer. It also helps a lot to see that if the maintainer is dismissing how they argue about the issue even more if they relate about the user experience they are trying to allow the other members of the community to have. And also if you see them participate on IRC and somebody has a question and there's no maintainer around and they say, hey, have you tried this? Have you tried this other thing? So those are very valuable skills both in interaction and in-depth in the technical side. Yeah, that's a great one. I'll try to summarize just in case the mic didn't pick it up. But starting about how you respond to issues, how you work with other people. And I think one of the things that you point out there too is that for most projects this stuff is kind of public record, right? So not only can you say, hey, I'm pretty good at handling issues. I'm really good at routing people appropriately kind of diagnosing what the problem is. And here's an example if you'd like to see where I did that or how I work in the community. So it really shows people you can demonstrate to a higher manager this is what I'm going to be like to work with. And that's a really big thing, right? Because that's the biggest thing when you go to hire somebody, you just really don't know what are they going to be like when they get here? How are they going to interact with other people? Are they going to be helpful? Are they going to turn out to be kind of a jerk, right? You just don't know unless you can actually see some demonstration. So you actually have a long history that you can point to where people can see how you behave. I saw another hand that went up. And back. So say more about kind of how do you develop that in open source. Communities. For example, you can see ideas floating but not necessarily a path to get to them. So by being able to see the overall picture of what it's wanted and become kind of a model. Yeah, it's a really good example. I think one of the most underrated skills that people develop working in open source is the ability to deal with ambiguity and to navigate very complex system and figure out how do I make a case for something and move it forward. And as much as companies can seem very much like a hierarchy where it's easy to figure that out, it isn't always, right? There's what's on paper. There's what's officially stated. And then there's the reality. Have we all seen situations where you can see one person in a company who's really good at getting stuff done and other people who just get stuck even though they have really good ideas? Yeah. So that's something that working in open source often helps you come up with how do I detect kind of the path forward here? How do I work with people who have strong opinions and accomplish something? That's great. What other skills would you add in the back? Yeah. I think, you know, that's a funny one too, is that as much as working in open source kind of develops your confidence that you can make something happen and that you are empowered and can make a difference, it also sometimes can help reinforce for you. I may not love what we're doing here, but okay, I can go along with it because, you know, at the end of the day I also care about what we're trying to achieve and maybe I'll try to convince you to do something different, but I could just hop on the train and move it forward. What else? Yeah, that's a great one. It really develops your ability to mentor others, to coach them, to do paired programming, cold review, lots of things like that. And I think as you become more senior and especially if you're a developer or engineer, that becomes more and more important to your role being able to talk about that, being able to do that. And it also becomes a skill that kind of sets you apart from other people who might be trying to get that same job. It's something that's important, but it doesn't necessarily come naturally to everybody. Anything else? We've covered quite a bit there. All right, so tips and tricks and a few mistakes to avoid. Big one is don't assume that they know whatever. Don't assume that they know what your project is. Don't assume that they know what languages you code in because you work on this particular project. Don't assume they know anything. Just include when you're talking to somebody a very brief explanation. What the project is, what your contributions entail. They may not know what a maintainer is. They may not know what community management is. Don't assume they know. But keep it short. Keep it specific. But don't get down too far into the technical stuff. You kind of gauge these conversations. Give them just enough that if they know nothing, they get a little bit of it. And then you kind of want to read, are they leaning in and asking me much more detailed technical questions? I know where I can go from there. Or do they look a little like, I'm not sure I understand. Maybe I can take a step back and simplify a little bit. Start with the explanation you would give toward more technical or even more simple as needed. This is a big one, though. I see this a lot. People will put on their CDs. They'll put, you know, maintainer for this open source project. But they are just kind of assuming that that's enough information for someone to understand. Or they're thinking, well, if they don't know, they'll Google it. Well, if you're a hiring manager, you're not usually going to take the time to Google something unless there's something else on there that got you interested to begin with. So don't make them do the work. The second one is really respect your contributions. This is something I see a lot. People tend to downplay what they do in open source if they're not getting paid to do it. So describe what you do just like you would any other valuable work-related skills or experience. So let's say you're in a job interview. This could look like saying something, you know, in my work on Anaconda, the Fedora installer, I review code for blah, blah, blah. I can say that and deliver that in the same exact way as I might say, in my work at Red Hat, I do blah, blah, blah. And if you present those things as equally important and valuable contributions, if you treat it as if this is work you do, because it is, the person you're talking to is much more likely to see it in that way. I don't know if any of you saw there was a study that came out not too long ago in Czech employers talking about whether they would count open source work as kind of work experience for students. And the answer was something like 80% said, no, no, no, I wouldn't count that as real-world experience. Well, a lot of that has to do with how you present it. If it's just in a footnote on your resume right next to I know how to use Microsoft Windows, okay, that's probably not going to get you very far. If you put it in the experience section of your, of your CV along with your employment and you don't sort of differentiate it out, you can put it on them to ask the questions to understand it. You're just listing it as experience. So this is a big one too. Don't inflate your role, right? If you don't feel like I have this particular skill we've been talking about, don't put it on your CV because that's going to lead to a very uncomfortable question in a job interview that where you say like, oh no, I just saw on a conference that I should say I had this skill. I don't really know what it means and I don't know if I actually have it. But do take full appropriate credit for the work that you've done. So this I think is much more common is that people downplay the work that they do or the skills that they have because they're afraid of appearing overly confident. So my friend at Red Hat, Sue Moynihan Cox she calls this learning the art of humble self-promotion which is you need to be able to promote what you do but in a way that isn't, you know, in your face and ugly. The fourth one is really highlight related knowledge and skills that you have. So Evolven Source has given you for example things people sent in an appreciation for good documentation, a better understanding of testing, more understanding of how automation should work, whatever it is, talk about that. Talk about how and why the work that you do in Evolven Source has contributed to that and why it makes you a more valuable employee. So for example you might say oh I see that you're moving in to see ICD. I've actually made a couple answerable contributions lately would you like to hear more about that? So there are ways that you can bring in your Evolven Source work into that conversation and really intrigue the employer to want to understand more about what you do. So with that I'm going to move us over to Q&A. I'm not going to pretend I have all the answers to everybody's questions but I imagine in the room somebody probably does. What questions did everything we talk about today spark for you? How do you get started as a contributor? Really good question. I think we have a room full of people who got started at some point who would like to give some pointers there. Yeah so I'll repeat back for the mic. So a good example is find a project you're already interested in, maybe something you're already using, something that relates to work you do already and just start small. Some of the examples that we gave in here earlier starting with documentation. My first thing might just be I found a typo in a doc. Great that's easy. I can walk through, maybe I have to submit a pull request to fix it so that gives me a chance to learn that if I've never done that before. Then over time maybe I answer some help questions. Maybe then all of a sudden I come across oh it does it this way. I have an idea for how it could do it that way. Let me try to submit it. So you can let your contributions grow over time and I think it's really neat actually how many of the stories that people sent in. That's exactly what their path in looked like. They didn't say I'm going to be a star or a Linux kernel engineer someday. They just started out with hey I use this. Let me figure out how to make it a little better. Figure out how to help other people who are getting started. Anybody have other tips? I see up here. Bug reports are a really reasonable and usually it's not too hard to find one to report so it's a great one. Back here. So before you submit your first patch with code in it you might take a look at other people's code and start there. It's great. Anybody else have something they want to add? A few maintainers to love you. A good one is to go through the open box maybe a bit oldish ones and try to see if they still reproduce. If they don't, stay so. If they reproduce and the steps were not clear and to like that and to help a bit the team try it. That's always good. And it gives you a better perspective into what the maintainers are doing with and it gives you then a path forward and forwarding questions about the developers and so on. Because investigating it may be able to find that they're actually doing the same things. Yeah, so that's great. I'll repeat it back for our future watchers. Talked about if you want to win the love of maintainers everywhere go ahead and take a look at older bugs that are out there and see if you can reproduce them. You can add comments about yes I was able to reproduce this, it is a problem or no actually this version and my setup it didn't happen. That starts to think about triage of bugs and things like that is a really good path in. And I will say too look for projects if you really are like I want my first contribution to go well I'm nervous. Look for projects that have some documentation that's geared toward how to get started on the project. A really good project tends to have information about what's a great way to get started as a newcomer, what do you need to know, where do you go to do this stuff. If you want to jump into kind of a very busy and disorganized project that might be a bigger hurdle just figuring out how do I contribute but many many projects have taken the time to show themselves as newcomer friendly and you can also identify yourself this is the first time I've ever done this that tends to make people a little more gentle with you they understand you're just getting started. That's a great one. What other questions do folks have or stories you want to share? So very good question is if you're applying for a company that's very much a proprietary company as far as you know they're not engaged in source projects is it worth mentioning that you contribute? Well I have an opinion but what do other folks think? Big enough there's still a wide field of fields that are important and of course quality fields are important and shepherds maybe some buck along so that it gets sold is also important as important as a proprietary environment that is important. Yes I'll repeat back for the mic the answer was a solid yes this stuff is still going to be very relevant to them and it's okay to ask questions about does your company contribute to open source are you familiar with it and kind of gauge where they're coming from and then that will help you understand how much explanation do you have to provide you know this is what open source is you never know if you're talking to a recruiter you might need to provide that if you are talking to somebody who's a hiring manager maybe maybe not it would depend on what their background is and you know it's interesting one of the things that some folks sent in ideas and whatnot was they talked about I don't remember who it was that sent it in I probably credit him at the end but if I did sorry Red Hatter I'll go find out who you were but he talked about how having coded in proprietary systems for years and years and years and also done open source that things that he worked on for 10, 15 years that were proprietary programs for an employer are no longer around and he put a lot of his life into it but he can't even see the code and sometimes can't even talk about the work that he did whereas even very small in his words not so great code that he wrote for open source projects years ago it actually still lives on you know a decade or two later and I think that's one area where open source is really a valuable thing to share with your employer because you can point them to look at code that you've developed you know if you're someone who writes code you can show them here's what my code looks like you might not be able to do that you know if you're working in a for a proprietary company you may not have code to show which um or that you have permission to show anyway so I think that's an area too where you might even intrigue them if they're not engaged in open source already and they might be kind of interested to know oh wow I can actually look at your code and not just you know in a here's a test kind of way but in actual real code that's out there in the world over here yeah that's really true um what he said was that when you're showing you know your code you're not just showing your code if it's open source you're showing how you communicate how you give feedback and that kind of stuff when you are looking at you know prospective hires you're trying to decide who should I hire it's going to give you a much clearer picture of what this candidate is versus somebody who just can tell you a little bit about you know I work for this other company and I work on stuff I can't talk about what other questions do folks have thinking about what brought you in here in the first place right I probably want to work on my CV I want to make sure I'm getting credit what questions did this raise for you and not answer it's great that's true and often open source conferences give you a lot more chances to speak just things like this DevConf I think is one of the best conferences where you've never done a technical talk it's a really great one it was my second or third talk I ever did anywhere was at DevConf and I only ever had one heckler at any talk I've done in many many years so you learn how to handle that too which is fun but it's really good and many times if the talks are filmed or if you have the slides that you share afterward you can also show people an example you know here's a talk I gave and here's the slides I used and you know that's one of those things that I think the longer you work in open source communities the more you take for granted that people just speak at conferences about what they do but in a lot of companies if it's a proprietary company many of the people who work there don't ever get up and speak at a conference about what they work on they might go to a conference but they may not actually have a lot of experience doing that whereas you know in front of a crowd full of strangers if you can get up here and speak you can definitely get up in front of you know your management team and talk about a feature you're working on what other questions or stories people have okay it's up when I first came from a proprietary company they were using a tool that was very impressed with the amount of effort that was so anyway I'm just mentioning not to lose that emphasis on you know CICP or resource yeah it's a great comment thank you for future watchers he was talking about how the appreciation and skills that you get in open source for code review often really are you know leaps and bounds in a proprietary environment and still very valuable skills that that people benefit from even in a automated world test and roll other questions back yeah it's the age old question right I've done so much how much do I put on the CV I don't want to be the one who shows up with the six page CV alongside everybody else's that's two pages so let me ask folks in the room when you are thinking about what you put on your CV how do you make that decision what makes it on what does it yeah so summarize what you do and highlight couple examples on there and you can always give a hint on the CV that there's much more you can talk about what I would do is take a look at the job you're applying for and try to decide out of all the stuff I've done and all the contributions I've made what might be most relevant and most interesting to this particular employer it takes effort to do that right you're applying to three different jobs it wants to kind of tailor what it looks like but it really will make your CV stand out from all the others because it's clear you're interested in the role and you've learned a lot about it you can also ask questions of the hiring manager so in the interview ask some questions to understand a lot more about the company about the job and that will give you the opportunity to share specific examples that you might not have put on your CV but what would I want to be if I would read the CV that would be important to me and a lot of the ways it works yeah so that's a really good litmus test too if I'm the employer and I'm looking for that CV what are the things that I would want to read on here and what are the stuff that I'd be like okay that's nice that's the stuff that you leave off and stuff you put on go ahead I would encourage you not to focus on the PR or the cognitive that are most technically impressive also with the ones that you actually have to fight for like the one that you had some interesting discussion the one that ended up with you having to throw it away and make a different approach because this shows much more development in the year otherwise it could just technical stuff it could be definitely in the light of the other box yeah so that's a really good point I'll just echo back very shortly don't just put the really technically interesting stuff on there put the stuff that you had to think a lot about maybe the stuff you've worked hard at but decided oh ultimately this isn't the right answer I had to go in a different direction really really good points and I would also say too if you are applying for a job what are the ones that you worked on that made a big difference for the person using the software for the end user those sometimes are not the most technically interesting things but often are things that show a perspective that maybe not every other person applying for that role would have so talking about the impact of what this contribution was what was the difference that it made to the project to the user that can be a really good thing to do before you go in for a job interview is to spend some time practicing like you're going in for a job interview so you can recruit your mother you can recruit your boyfriend you can recruit someone who loves you and is willing to sit in the chair and ask you tough questions but take the time to anticipate what kinds of questions might I be asked and practice answering them if you want to be able to share stories and examples it's really hard when you're nervous and you're sitting in a chair to come up with those you're like I know I have one but where is it but if you've told that story a few times over if you know in your head here's the couple of skills I really want to make sure come through then that's a really valuable way if you've told them a few times in practice you're going to be able to tell it much more easily in the moment and another thing too is to remember not just them deciding am I good enough to hire you want to know do I actually want to work in this place and so really taking the time to ask questions about what is the team dynamic like what kind of work would I be doing I ask really tough questions when I interview for a job so I'll ask questions like okay let's say six months from now I am wildly happy with this job you are really happy with the work I'm doing why is that the case what made the difference between me let's say six months from now I'm really unhappy here why do you think that would be right you can start to uncover there is sort of a toxic environment that I want to know what I'm walking into and you can tell how people answer and what they don't say right if they're just very like oh no you're going to love it you're going to love it maybe maybe not I don't know if you're not willing to talk about what are some of the challenges that's actually probably a tip off for them too let's say six months from now you know I've got the technical side of my job down but you're still not real happy with the work I'm doing what would be the most likely reason you know a year from now if I felt stuck in this role I wasn't advancing why do you think that would be I don't make them a little uncomfortable that you ask those questions but it actually will kind of get them to open up and it will give you a chance it will help you understand what are the challenges that they're facing what has been tough for them often they're filling a role that they've filled before so you know somebody who wasn't successful in it why was that the case really really good stuff and also it helps kind of humanize you and the person who you're talking to so you actually get to know each other as people which in the end makes you more likely to get the job even if you weren't at the top of the list going into it having those questions what other questions people have your interviewers in direction themselves contribute to this yeah it's a good question so you could ask the interviewer have you ever contributed to an open source project what's been your history with it and you might be surprised especially if it's somebody who is older of its interviewer many times they did years back and they haven't in a long time or they might say you know I've never contributed it's kind of it's really surprising how ubiquitous I think open source is now and how many people are involved in stuff it's a really good one you can also ask them questions about kind of their career journey in a company so you could say like tell me about how did you start out here how long have you been here you know what's been the most what's your favorite thing about working here what's the biggest challenge you have about working here the bigger picture that you can get of what this role is like the more you take this emphasis and it's more of a conversation of are we going to kind of make each other happy are we going to be able to give each other what we need whether anybody have stories they want to share about kind of how they got started in open source and what that's done for them go here say it real loud I have a very important question I was listening to some teachers so I said come here I thought there was only a problem I had to send them an email to actually and he doesn't use the project to support up the monstrosity so I hope that will work and use my work I would say so I mean it's something you can show you may not you might not position it as here's an example of an open source contribution I made but it might be here's an example of some work I've done it started out as you know an open source project and I was I couldn't get what I wanted in that project it didn't meet what it does now I think it would be an interesting thing for people to see go in the front I personally always ask the question in the interview about such things like probably about the time but in the data why was it like why were you about it it's a good experience to have yeah so it's definitely how it's received might depend on who the interviewer is but certainly if it's somebody who works in open source they'd be interested to see that what's the shift that I think kind of many open source communities it used to be that forking a project was kind of seen as like not a good thing so much it was we want to kind of keep one central thing but now I feel like it's just so much more like yeah if it doesn't meet the objectives that this project has why not that's why it's open source so we can my acknowledgement slide I mentioned there were a hundred plus emails that came in ideas in particular that I took from Red Hatters this is who contributed a lot of them and there were many ideas that came in from five or six different people too so it's kind of proof I think that a lot of this stuff really people find it to be helpful to them and that our experience is working in open source actually or sometimes they're more universal than we would think so I think