 Thank you for coming to the talk, thank you for being at the panel earlier. My name is Duane O'Brien, I am the head of open source at Indeed, I am also a hiring manager, I probably should change that URL, but come to the Indeed booth downstairs and talk to us if you're interested in hearing about the roles that we have open. Quick disqualifier, I'm going to talk about some things in the talk that are my own views, if you hear things that are exciting and make you very happy, then I would say all hail to Indeed and if you hear things that make you very angry or make you want to come up and have a very strong debate about it, that's probably me, come argue with me or yell at me on Twitter or anything like that. So the subtitle for the talk was how open source participation plays into hiring. It's also called don't judge candidates by their GitHub profiles and I can sum most of this talk up in one word and that one word is don't look at candidates that you're looking to hire and make judgment calls about them based on their GitHub profiles. Further I would contend that GitHub activity is a bad indicator in hiring and we should stop using it. Now bad indicator in this case does not mean it is a counter indicator that it's telling us bad things, it just means that GitHub activity does not tell us what we typically think it might be telling us and that's why we should not rely on it as part of hiring. This is because GitHub does not own the world of open source and that GitHub open source participation does not necessarily indicate candidate quality and open source participation requires time that not everybody has and I'm going to dig into all of these as the talk progresses. A quick show of hands, any hiring managers in the room, any people who are responsible for hiring decisions? Maybe 10% of the room so I'm guessing the rest of you are not responsible for hiring you work in or aspire to work in the software industry in some way. More or less the rest of the room with a few people who may have slightly different roles. For individuals, again I want to give you tools that will help you advocate during the hiring process and for hiring managers I'm going to talk a little bit about what some candidate alternatives might be when you're doing these kinds of evaluations. Now before we go too far into this I want to make it clear that this is not an anti-GitHub talk, I don't hate GitHub, I don't have anything against GitHub, I'm actually very very positive on GitHub. You'll hear me sometimes go back and forth between the phrase open source participation and GitHub activity. This is really more focused on GitHub but don't take it as a big anti-GitHub brand, I think that they have made a tremendous contribution to the open source community and changed the way open source has worked for certainly the last 10 years or so. So a quick story time about me, I was working at a company two or three companies ago and I was working on a product that used a lot of open source software and I literally sat next to a team that was being put together to build a large open source project and I was a JavaScript engineer and I should put a JavaScript engineer quotes there because I don't think I was very good at it. I was a JavaScript engineer at the team and they were hiring for a JavaScript engineer and so I was excited I was already in the company I applied for the role and I met literally with everyone in the team starting with the hiring manager and then you know a series of meetings with people where we talked about technology and the goals of the project and everything. In the first meeting with the hiring manager he said well you know we're excited that you want to come work for us and join the team you know it's an open source project we'd like you to you should feel free to you know fork it take a look for an issue find a bug that you feel like you might want to take on and you know take do some work on that submit a pull request and see how that goes. Now we went through the process of meeting with everyone else it was not something that I really had time to get to and at the end of the process I was not offered the role and when I asked him why he said well we invited you to submit a pull request of the project and you didn't do anything so we just assumed it wasn't that important to you. Now what the hiring manager didn't know at the time was that I was both the single-earner and a three-person household and the primary caregiver so all of my time that I didn't have at work was spent on the house and there was just really not reasonable time available in the off hours for me to fork and submit a pull request or to kind of dig into a bug. Now there is an aspect of this looking back on it today that I can see I probably could have made some kind of smaller contribution in the time but I had very very tight time constraints on the time that was available to me when I was not at work and I would like to say that I very patiently and clearly explained this to him what actually came out was probably more angry and maybe a bit of a rant and some frothing and I explained that I was you know primary caregiver I don't have the same kind of availability to time and he acknowledged that but in the end I still did not get the role. So the problem of personal time availability and contributing to open source and it being a problem overall is not particularly a new idea. Ash Dryden was writing about this where was this in 2013 many jobs require open source contributions to even consider a candidate and this was in the blog post her ethics of unpaid labor in the source community November 2013 and I want to read a quote from that. Further deciding that someone is a good programmer based solely on their publicly available code excludes far more than marginalized people. It also excludes anyone who can't release their code publicly because of licensing or security reasons. This also includes a large number of freelancers and contractors who are unable to publicly claim that they worked on a project for legal reasons. So requiring open source contributions as part of the hiring process biases against the whole category of candidates and some of them tend to be traditionally marginalized people but another whole category of people that just can't be involved in open source for one reason or the other. This is also not a new idea. It is not an unpopular idea. It is a thing that seems to come up every few months. I first submitted the I think I submitted the first version of this talk around January last year as there was a company called Git Lance that decided that they were going to provide automatic candidate ranking and evaluation based only on their GitHub activity. So they would scrub through GitHub. They would look for people who have activity and they would provide higher ability and ranking scores. So this was the business model that they were proposing. We see Rebecca Turner here calling them out. GitHub was already fairly well understood for the past few years among people who were paying closest attention to it that GitHub makes a bad resume for a lot of reasons. But then there are these people that came along and said what if we use some machine learning and just make it an algorithm. No, it's still a bad decision. So it's not an unpopular idea. It comes up every few months. About six months later, someone else posted this thread that kind of blew up on Twitter that indicated that he doesn't even look at resumes anymore. He just looked at people's GitHub profiles to see if they are people that he wants to hire anything that everybody else should too. After being taken strongly to task for this position, he later claimed that he was trolling people and the troll defense whenever someone says something that maybe they shouldn't have said online. So it comes up every few months and I've had this conversation a number of times over the past few years with friends, with colleagues, with former colleagues who are now hiring managers. So why is it that we keep doing this? Why do we keep coming back to this idea that we just want to look at GitHub and hire people based off of what they do there? Well, part of it is because we love data. If you look at this GitHub profile, we've got all kinds of great stuff here. We have a year's worth of very easily visualized activity. We can tell that they are constantly active on GitHub. We can see that they are a number of a bunch of different organizations. They're just a prolific contributor. And this is really appealing. We love visualizations and engineering. And most technical hiring managers are engineers who either grew into the role or got senior enough that they were pushed into the role. So when you see something like this, ah, now I can see lots of data, we love visualizations. But it's not just because we love data. We also teach this behavior. We teach it in colleges, we teach it in boot camps, we teach it in hacker schools, and we teach it during the hiring process when we say we'd like to see your GitHub. In college boot camp and hacker schools, we tell people that having open source activity, having a GitHub profile can make it easier for people to hire you. It improves your chances of hiring that reinforces that same behavior, that reinforces that same learning. And part of this, like I said, is because those engineers who, the hiring managers are probably former engineers. In particular, the new hiring managers now are in this little bubble that they have created. They started off in engineering when GitHub was just the de facto standard, right? They've never worked in a world with SVN or CVS or Visual Source Safe or Per course. God does all of order, but you get the general idea. So they came up during the time of GitHub. This is just how everything works. Of course, they're going to look for people who look like them and who came up the same way that they did because they believe that those people are going to be successful and they're going to hire what they know. Now, you might be looking all of this and say that you don't see a particular problem here, but I'm going to dive into what I believe some of the problems are. And the first one is obviously is that there is open source outside of GitHub. So who knows the digital oceans? All right, great, lots and lots of people. Who knows about their current quarterly newsletter? Okay, I think this is one of the coolest things that digital ocean does. And that might tell you as much as you need to know about myself because it's not technical. It's a survey that they do. They release it every quarter. It's called Currents. And they try to gather what they see as emerging trends or kind of emerging ideas within the world of open source. In which one was this? This was some time last year. If you go to digital ocean.com slash currents, you can find all of the reports, which source code repository do you do? Do you use less than half of them set GitHub? That means more than half of them use something else. Alright, so we already know from this that there's open source that happens outside of GitHub. We know there's open source on launch pad, out of patchy, in bit bucket, and in newer and more innovative source code control platforms like Lich that are doing things that are maybe even a little beyond me. We know open source happens outside of GitHub because we also know about GitLab and the ability to import code in from GitHub. So this is a report that was released by GitLab in, was it June 3rd in 2018 showing the velocity of projects that were moving off of GitHub into GitLab. Who knows what happened right about here? Microsoft buys GitHub and tremendous, tremendous volume of projects has moved off of GitHub on to GitLab. Now Microsoft has done a lot over the past few years to really become meaningful members of the open source community. I personally believe that we're seeing them put a lot of their time and effort into that messaging sincerely. But over time, who knows what's going to happen with GitHub and Microsoft and who knows if this chart will once again see a tremendous rise or if something else will come along. So we know there's we know there's open source activity outside of GitHub. So if you bias candidates in one way or another, based on their GitHub activity, you're filtering out some percentage of the other candidates as well. There's also a problem on how you measure participation. So would anyone want to hire this JavaScript engineer? No hands went up. It's probably a good idea. That's me. I was not a very active JavaScript engineer, but you probably don't want me in that role today. But if you take this profile, someone who's clearly involved in JavaScript, and you take this profile, which of these two JavaScript engineers do you want to talk to first? Well, this one has a lot of activity. These seem pretty prolific. You might want to talk to them first unless you realize this is Douglas Crockford, one of the co-creators of JavaScript, discoverer of JSON, creator of JS Lint. He knows a thing or two about JavaScript, right? So if all you're looking at is activity as a filter, you're likely to center, centralize your efforts on candidates that look like this and mis-candidates who may be more senior or may be doing architecture kind of work. Now, you might not do this individually as a hiring manager, but your recruiters very well could be, right? Or other people who are helping source candidates very well could be. If you're telling them to look for active GitHub profiles, they'll miss people like Doug, right? And activity in and of itself doesn't really mean a whole lot. It's a little bit like hiring your most prolific four of a member to be your community manager. Well, maybe they're the right person. Maybe they're just the loudest troll, and they like, you know, getting involved in conversations, or maybe they're just very pedantic and they can't let go of nitpicky conversations about words. And I'll read this out of a quote from a blog that came out last, sorry, in 2013. So really, your GitHub profile displays two things, how influential you are, and how easily you can be coerced into constantly working. It's honestly about as relevant to a decent hiring decision as your cloud score. Was cloud the thing over here? No hands. Okay, awesome. Cloud was this thing in the US that basically tried to measure your influence based on looking at your social media profiles, right? So, you know, how much you would crawl through Twitter posts and a bunch of other things, and it would try to determine, you know, how much influence you could have in conversations about specific topics, like how much weight does your word carry when it comes to JavaScript? Actually, between the time that I created or submitted the first proposal for this talk, and the time that I gave it, cloud went out of business. And so I had to update and add this slide. So, if GitHub activity is about as useful as your cloud score, well, that's something else that that metaphor tells us. So let's talk about the kinds of people who would not be on GitHub. Like most of my tech career, they may have been doing internal work only, right? They might have been working entirely on proprietary software. They might have been working on software that they just weren't allowed to work externally, and they just don't have anything to show for it, right? They may have been company policies in place that expressly disapprove participation in free and open source projects. Now, in the U.S., and I can really only speak more effectively about what U.S. employment agreements are like, but in the U.S., it is not uncommon for you to sign an employment as part of joining a company, an agreement as part of joining a company that says that all the work that you do while you're employed for us is technically company property. Now, how enforceable that is really depends on region-to-region, and it's usually not as enforceable as companies might believe it is, but it certainly has a chilling effect on engineers who want to get involved in open source projects. And I've talked to a number in many different companies who see employment agreements like this assume they just can't contribute to open source, and so they never try. But your company might actually have really aggressive policies around this, for example, if you're doing government work, especially if you're doing government work that might have some kind of clearance. You might be bound by an NDA, a non-disclosure agreement. I just can't talk to you about the work that I'm doing, and I can't contribute into the open source community based on the work that I'm doing, because I've signed a piece of paper that will make me fireable and sueable if I do that. And some people just don't want to. And that has to be okay. There was a comment, I don't know if he's still in the room here, on the panel where Michael was talking about recognizing open source contribution and rewarding it for employees either by factoring it into the promotion process or factoring it into their incentives. I personally feel strongly that that's a bad model because there are some people who don't want to participate in open source, and if their only path to getting promoted is to force them into open source, that actually creates some problems. And I'll dig into what those problems are in just a little bit. So hiring based on GitHub activity isn't just inaccurate because it misses all of these things. I will go a little further to say that hiring just based on GitHub activity is wrong. And I mean wrong in this sense morally. So open source participation can be problematic for any number of groups of people. There are some communities that are very challenging to participate in. This is getting better over time, but I think we can replace the word challenging with toxic communities where it may be the language or the framework or the stack that you know the best, the community is not welcoming, or at least not welcoming to you. And participating in that community costs you emotionally more than you get out of it. You should not be forced into participating in that community. There are communication barriers that can add friction, and I think this is especially relevant outside the US. If someone is maintaining an open source project in the US and all of their contributors are English, and English is not your first language, and maybe not even your second, it may be not even your third, you're going to be less likely to be able to get your pull requests landed and merged than people who are able to communicate more effectively in English. This also adds into, when you add into that the time delay that's involved in time differences from, you know, this side of the world to the other, communication barriers like that can really make it difficult to participate on even footing with other members of the community. And so your work might be de-prioritized. So that's another reason that it can be wrong. Cultural norms can be intimidating. I'm a pretty reasonably grounded person, but even now when I go to make a contribution to open an issue, to open a pull request on a project that I've not been to for the first time, I spend a lot of time trying to figure out if I'm going to get it wrong, or if I'm going to get yelled at, or if I'm going to put my foot in my mouth, right? When you don't know how to navigate the community because you haven't before, it can be a little intimidating to take that first step. But I want to focus a little bit on this idea of time and call back to the idea of participating in open source on your free time. I don't, there's an outstanding question, and one of the reasons it's outstanding is because it's moving over time, of how much open source and how many contributions to free and open source software come from people who are paid to do it, versus people who do it because they love to do it, right? We've seen a lot of numbers thrown around over time, you know, what is the ratio of paid versus non-paid free and open source developers. I didn't have an answer to that, so I did what any reasonable American tech guy would do. I just read half a blog post to put up a Twitter poll, and I asked, for those of you who participate in open source communities, which of these is the most true, I do it on company time or do it on my own time, and two-thirds of the people who respond to this said they did it on their own time. Well that's, you know, two-thirds of 188 people, so maybe not a super useful piece of data, but we know there's something there. Let's come back to Digital Ocean Currents. Do you write code as a hobby or a profession? And 63% of the people said both, 18% said as a hobbyist, 14% said professionally. So at least 63%, some percentage of their free time plays into it. We just don't know how much. A couple years ago, GitHub ran the open source survey. This one got 5,500 responses. It's going to be fairly GitHub biased in the data set, but they, knowing some of the methodology that they put into it, they really tried to get honest, good answers to this data when they ran the open source survey. So 5,500 responses, virtually all 94% of those who are employed use open source at least sometimes in their professional work. 81% use it frequently, and 65% of those who contribute back do so as part of their work duties. I'm going to say that again. 65% of people who contribute to open source do it as part of their work according to this survey. That means 35% don't. They're only doing it on their own time. And I've said a few times, free time, I don't know about the rest of you. I think free time is like free money, and I don't have any free money. So I don't have for any free time. What I actually have is personal time. And the idea of personal time is something that the tech community as a whole has continued to encroach on over time. I think it's very important that your personal time is personal. You have the time that you need for work, you have the time that you need for recovery, and then you have the time that you get to do whatever you want to. This is why in Silicon Valley, if I see a job opportunity that someone advertises that we have chefs on hand for dinner, that's not a perk, that's a red flag. That means they want you working at the office past dinner time. So personal time is personal, and it should say that way. Let's talk about who has the most personal time. Well, I'll give you a little bit of a spoiler. The people who have the most personal time tend to be young, tend to be male, and tend to be white. They look a lot like this. If this is your life, if you're, you know, a single young man of reasonable affluence, of course you can spend eight hours at work working on code and eight hours at home working on code, right? You're not too far from this looking like your life. These people have so much time they paint blue tuxedos on them, right, as part of a sports game. You're young, you're in college, you've got all kinds of free time, right? You've got all kinds of personal time, but if this is your life, if you're raising a family, the older people in this picture don't have any free time. They don't have any personal time. By the time the kids are in bed, it's just enough time to kind of recover and get ready to go to bed yourself. You don't get a lot. If this is your life, if you're a single parent with a couple of kids, personal time is just doesn't, it's not going to exist for 18 years for you. If this is your life, if you are, you know, primarily responsible for elder care, you don't have a lot of personal time and what personal time you do has go, what personal time you have goes into this role. Now this isn't just, you know, me talking about it, the UN Economic Commission for Europe broke down across a wide range of countries who has time for free time and other activities, TV video games and then other free time activities. And country by country, it is men who have disproportionate free time when compared to women. And this is because in general, out of the same report, women tend to disproportionately bear responsibility for household duties, right? So not everybody has the ability of free time. Your free time is your personal time and how you spend it is how you choose to spend it. And this is why I contend that using GitHub activity or open source participation as a primary filter during the hiring process is wrong. Because if you won't consider a candidate who doesn't participate in open source and some candidates can't participate in open source because of external forces, you are trying to lay claim to their personal time that doesn't belong to you. It biases against a whole category of people. Their personal time is not yours. Don't. We'll come back to the summary of the talk. Don't use this as a primary filter during hiring. Now what are you supposed to do? Because I've I've tried to build what I think is a compelling case on why you shouldn't do this, but I haven't given you any tips. I want to talk first to people who find themselves in the position of being evaluated for hiring. I want to try to give you some tools that will help you advocate for yourself. And I'm not going to lie and I can't really sugarcoat it. This is kind of hard to do. It's intimidating walking into an interview and also feeling like you need to do anything other than just try to make the person on the other side of the table happy. Advocating yourself is not impossible. It can just be challenging. Part of this is just knowing the language. If you understand that this whole thing is happening behind the scenes, it gives you the ability to deal with the problem in a way that maybe you couldn't before. Know that this is what recruiters look for and have an answer. Don't get caught flat-footed when a recruiter says, hey, you know, we looked at your GitHub but we didn't see any activity. So what's the deal? Explain your constraints, right? And that could just be as simple as saying, as having an answer ready to give that says these are the other things that I'm involved in and this is where I spend my time, or this is not where I choose to spend my time. I don't like to code, you know, 24 hours a day. When I get home I like to read or go hiking or get away from the computer. And if that answer isn't acceptable to the employer that you're talking to, if they're looking for people who eat, breathe and sleep code, that should be a signal to you that they don't want people who eat, speak and breathe code. They want people who eat, speak and breathe their code, right? They aren't going to be as excited about someone just because they make a lot of off-hour contributions to open source. The expectation is going to be that you will continue to do that work for them in the off hours and consider yourself lucky to have avoided that. So have an answer for whatever your constraints are or whatever your decision has been. Feel free to offer them code samples. In most cases, even if you've only been doing internal work, there is code that you have worked on that you can share in the process of the interview process, in the process of being interviewed so that they can see what the code looks like without actually giving it to them. If you've got to print it out and take it in so they can look at it, I think they will understand. I can't share this with you because it's under NDA. I can't share this with the internal, but here's what some of my code looks like, right? I would say that sometimes I have heard people given the advice that anything on GitHub is better than nothing. So create a project of your own. My perspective as a hiring manager and as a people, as a person who looks at the candidates, if I see vanity GitHub projects where you've decided you want to make your own forum software as a thought experiment, that tells me slightly more than nothing. But if you're investing significantly on trying to create something new, I would wonder why you're not spending that same amount of time also being involved in the open source projects you use. I think vanity GitHub projects are better than nothing, but don't force something into GitHub just to try to make it look good for other people because in some cases it can actually end up looking bad. By all means, if you have a thing that you love that you're building on GitHub and it's your own thing, that's not forcing it, right? You're creating something that you love. But don't put something up just to put something up because it's going to look like fairly low quality code anyway. I also think it's very important to recognize your value. Hiring managers in the room, put your hands up again, people responsible for hiring. Keep your hand up if you think hiring is super easy. Not a hand stayed up in the room, right? Individuals in the room who are not hiring managers, who are working or aspire to work in the software industry, the power is in your hands, right? There are not enough of you. If there were, hiring would be easier, all right? Hiring is hard. Understand that and know what your value is. But it's not just about knowing that there are not enough of you. You really need to recognize what you're doing well. And I'll touch on that briefly in a moment. So since there are not enough of you, filter out those needing employers. Filter out the employers who you think are going to be expecting you to answer emails at eight o'clock at night and writing code at midnight, right? If that's your thing, if you love your job so much that you go home and you keep working on it and you work into the night and it brings you joy, no one should stand in your way, right? And there, I have magically turned into this kind of person over the last few months over the program, it's not writing code, it's usually writing documents. But no one's expecting it of me. My employer is not expecting it of me. Some people just like to work in that mode and you should feel free to. There's nothing wrong with that, right? But if your employer is expecting it, that is a thing that I think you should filter out. I also think it's important to know when you are at your best. Know, really know the things that you do well. I thought for a long time that I knew what I did well. I was wrong just about on every case and I'm probably wrong about it now. You have a set of skills, right? And maybe what you can do well is you can write really, really well formed code that's easy for other people to understand that it's very elegant. That might actually be your strength, your actual strength might be finding really, really weird creative solutions in code that no one in their right mind would ever deploy in production but solve the problem in a way that no one else has been able to solve before. Maybe that's your strength, right? The only way to really know what you're best at and to know when you are at your best is to go through a process that I like to think of as ruthless introspection. You need to sit down with yourself and your work and really spend some time looking at it and being honest with yourself about the things that you're good at and honest with yourself about the things that you're bad at. Speaking personally, I had a very hard time recognizing the things that I was bad at and I had an even harder time admitting that I was bad at those things especially to other people until I sat down and actually figured out what the things were that I was good at and that I could bring to situations. If you can articulate those during the hiring process, it demonstrates a kind of self-awareness that most candidates don't come into the process with. You'll sometimes get a question, you know, tell me what you're bad at, tell me your worst mistake and there's a temptation to downplay that, embrace it, know what you're bad at because it's going to make you better able to talk about the things that you're good at. But while you're doing this process of ruthless introspection, I also want you to practice fierce compassion for yourself. This introspection is not a process for you to find all the reasons that you're not qualified for the job you want to get. It is a process for you to find out why you are qualified, what your strengths are. Be kind to yourself when you're looking at the things that you know are just not your best areas or the areas in which you want to develop. So ruthless introspection always pair it with fierce compassion. And that will, again, give you the ability to play to your strengths. Don't paper over your weaknesses, don't try to hand wave over your weaknesses. If there's things that you can't do well, they're going to come out in the first three to six months of your employment anyway. They're going to come out. Talk about what your strengths are and be honest about your weaknesses. Also, finding a mentor, who has heard someone say, hey, find a mentor? A bunch of people? Okay. Who knows how to? No hand. Maybe one hand, maybe one hand. Advice on finding a mentor, look for someone who you think is further along in their career that can give you good advice on how to get to your next step. If you're looking for, if I was looking for a mentor because I wanted to be a CEO someday, that's a massive, massive step to try to find somebody to take me that far. I need to find somebody to take me to the next step in my journey, like what's going to get me a little closer. And when you ask for someone, when you ask someone to give you mentorship, be specific about what you're asking for. Will you be my mentor? Sure. What are we talking about? I can't help you with that. And much the same way that when you ask for feedback on something, I'm going to pick on you for just a moment here. So I'm giving my talk, you and I are good friends. We're old friends. How am I doing? Great. That's what your friends are always going to say. That's what anybody is always going to say. How am I doing? Great. Let me try something else. I'm of English as a first language speaker. I tend to speak very quickly. How well do you think I'm pacing my language so that I can be understood by the room? Okay. That was super useful feedback, right? Because I asked her specifically what I wanted feedback on. And for those who don't have English as a first language, I struggle with this all the time. I'm a fast speaker. If there's anything I was unclear on, please catch me afterwards and I'll unpack it as well. So when you find a mentor, when you're looking for a mentor, be specific about what you want them to do for you. And be specific about those conversations. If you want help trying to find one, I will be more than happy at least to try to help you find one. Other ways that you can advocate for yourself is you can seek paid contribution work. If the constraint that you're under is that the time that you have available needs to be put into time that generates income for you or your family, there are ways that you can seek paid contribution work. Outreach is a program run by software Freedom Conservancy that provides paid internships for people to make their first contributions to open source projects. I see that. Thank you. There are bug bounty programs. I believe Hacker One has a pretty good one where you can collect bug bounties on bugs that are open on open source projects. There are a number of companies that will offer paid internship as part of the hiring process. I don't know if we want to hire you full time or not. Take a couple of weeks contract and let's see how it works out. I know Honeycomb I.O. does this. Not everybody's in a position that you can take advantage of that. That can be a little hard. Especially if you need to have the next job in hand before you let go of the last one. But there are paid internships available that can lead out. There are also some fellowships available through Mozilla and the Ford Foundation. So there are ways out there to seek paid contribution work. And that can be a better way to build up your open source profile and to give you the ability to advocate for yourself. With that I'm going to switch to talking to the hiring managers in the room. And ultimately I just want to encourage you to look at candidates another way. Rather than interviewing for fit I want you to think about interviewing for growth. I'm going to go to a report that is probably fairly biased toward American data. It was run by Gallup Research. And the basic question was how important are growth opportunities in your next role. And so I'll read out here Gallup's related report how millennials want to work and live reveals that 59% of millennials say opportunities to learn and grow are extremely important to them when applying for a job. Comparatively 44% of Gen Xers and 41% of Baby Boomers seem the same thing about those types of opportunities. So Gen X, 44% I care about growth. Millennials 59% I care about the opportunity to grow. If you're looking at a candidate who doesn't have open source contribution history, that's a fantastic opportunity to give them to grow. Right? Look for the opportunity. Look for reasons to say yes to that candidate to bring them in and then help them to grow in that area. I also want you to be very conscious that you're treating your candidates fairly. So if you have a candidate that you're evaluating and they have that prolific GitHub profile and you decide you want to talk to them, that's fine. If you have a candidate that you want to evaluate, they look strong but they don't have any GitHub activity, start asking them for some alternatives or providing alternatives to them. If you want to look at their open source work and evaluate them and they don't have any, offer them a panel interview, ask them for code samples, offer to do a reverse code review, have them come in and sit down with an engineer who wrote some code and they review the code for the engineer. You're going to get a little more insight into how their brain works through that process as opposed to just looking at their things. You can give them a take home programming exercise. I have very mixed feelings about this because this is just another version of trying to lay claim to someone's personal time. So if you give them a take home programming exercise and it's a couple of hours long, that's probably reasonable. If you give them a take home programming exercise, it's going to take them a week to complete, you have to pay them or don't do that. Even if it's more than just a couple of hours, you should really be thinking about what the end result is there. Offer them contract work. Again, you might have features in an open source project of your own that you want to have implemented. Rather than bringing them in as an employee and not knowing how well they're going to work out of open sources, the thing that you care about, offer them a paid contract to implement a feature. You will get a lot of exposure to how they work and get more of a sense for what they're like. Again, that won't work for everyone. And the idea is to have a diversity of options that you've already thought about when you don't see what you're looking for. Think about open source activity and GitHub activity as a signal that you're getting from a candidate. If you have another candidate that is not giving you any signal, you just have to find another place that that signal can come from. So treat your candidates fairly. To wrap up, I contend that GitHub activity is a bad indicator in hiring. We should stop using it bad in this case, means it tells us things that it does not intend to tell us and does not tell us what we wanted to tell us. This is because not everyone participates in open source in the same way. Not everyone has the same time constraints and the same time opportunities to contribute to open source. I want candidates who find themselves in this position to advocate for themselves. And I hope I've given you some ways that you can do that. And hiring managers, I want you to offer candidates alternative evaluations of equal weight. If you give them a take-home exercise and it comes back, you need to evaluate that using the same amount of weight that you would evaluate their GitHub activity. You can't give them a take-home exercise and say, well, they did great on the exercise, but they didn't have any GitHub activity. So we're going to bias toward that thing. Treat them with equal weight. And with that, I believe we've got between four and seven minutes for questions depending on whose timer we look at. Okay. Actually, we are a little bit ahead of time, but we can take one or two questions. Thank you, Dwayne. I'm Alvin. Nice to meet you, Alvin. I'm wondering, when you asked just now, how many of you have heard the word clout before? Did you mean C-L-O-U-T? Because I would have put up my hand had you spelled it with a C. Right. And according to Merriam-Webster's Dictionary, I have an app. It's spelled with a C. Right. And the startup spelled it with a K, presumably because clout.com was not available, but K-L-O-U-T was. So, thank you. Just two refresh changes. The first one is like in my history, I saw people who stole the open source code, renamed the packages, and then put it on their GitHub and pretend it as their own work. And actually, there are companies who actually do build your GitHub profile for paid. I mean, you just pay them cash and then they make a new project just to and contribute to it just as like your own. So, and that is right. Like, GitHub is, as you said, it's not a good indicator, but the problem behind it's like we're talking about hiring managers and people who have to do HR screenings. And HR people who usually they don't know about coding unless you have to send all the works to the technical guys to review. So, what kind of like suggestion can you give to those non-tech HR managers or staff to screen out employees or candidates? Sure. So, the first thing I'll make sure that we know is that people who do just copy library code out of open source projects and call it their own or well in license violation already, right? And they would, those libraries probably would show with very low activity, right? And I would encourage people to look at low activity GitHub projects in an individual's personal repo the same way you look at a vanity project. If there's no collaboration, it there's open code maybe with license but may not be open source. As far as advice for hiring managers on how to give HR guidance for non-technical people to navigate the screening process to avoid situations like that. If you're working with a recruiter, right? Your recruiter is not likely to be familiar or deeply familiar with your own nuanced technical space, right? They might understand the process of sourcing candidates to come in or going out and finding people that they think would be ideal. It is important to have this explicit conversation, right? I'm not looking for people with GitHub activity if they have a GitHub profile. Great. But if not, that doesn't mean we throw the candidate out. Look at some of their past other roles to see if the roles that they have held to date look like they might be able to perform this role as well. Unfortunately, this means that you have to cast kind of a broad net maybe a broader net than you'd like to. And believe me, when hiring is already hard, right? Having to go through twice as many resumes to figure out if you think someone is a fit, it means more time investment on your part as the hiring manager. If you take the role seriously, I think you have to do that work, right? So making sure that the candidates are not getting filtered out above you by this by being explicit about that requirement or the lack of that requirement is one thing that you could do. Are we at time? Are there more questions? Maybe last question. There's the last question. You dropped that phrase hiring people who don't want to contribute to a free software open source. I take a little bit of the issue of that because there's a difference between not wanting and not being able to. If I have a corporate open source project, then I'm looking for people who understand the community and who can help me push that project into the community. And I may not have the resource and time to train people in community work. I can train developers, but I cannot train them in community work because that's a whole different kind of thing that needs to be done. And so I don't know how to deal with that. So let me give an example, a couple of examples that maybe will help clarify that. And to start from the foundation that I don't think everybody has to participate in open source. I don't think everybody wants to and I don't think anybody should be put in a position where they feel like they are forced to. Developers can work on projects that are internal facing only and be great developers and never be in a position that they could. There would be opportunity for them, but I don't think we have to force them into that. And again, if they are being forced into a community that is not going to be receptive to them, then you're putting emotional labor on the candidate. For example, if the project that they're working on, that is internal, that touches some piece of free open source software, if the community around that project has demonstrated the inability to work effectively with people who are several time zones in the future or in the past or who are not able to navigate their language or their cultural norms, you're basically putting stress on the individual to figure that out for themselves when there is a community problem on the other end that they can't solve. And so that's not going to be a good experience for them. If you take as another example someone who's already been through that experience and I've talked to another and number of engineers who've done this, you know, hey, I made an open source contribution once, it was terrible, I'll never do it again. Okay, like if that's where you want to be, I will take you where you are there. I hope over time that I encourage you just a little closer to making maybe a tiny of contribution and helping work through that again. So I know you've got your hand up. I'll be happy to talk to you afterwards. I'm looking to you for time. I think we're at it. All right, thank you. Okay, if you have more questions, I think you will be around here. I'll be around. I'm actually headed straight to the booth downstairs. I'm supposed to be on duty, but I can talk to the hallway briefly as well. Ketch doing and ask a question. So let's give a big round of applause for the doing.