 Welcome to Better Hiring Practices for Fun and Profit. So we are here to actually solve the hiring process in tech once and for all. We are never going to talk about this ever again. But before we get started, I wanted to just do a little bit of house cleanup. So there's, of course, the lovely RailsConf hashtag if you want to comment about the panel. Also, I'm going to be checking this other hashtag, higher Rails periodically throughout the panel to look specifically for questions or comments from the audience. We'll still do a Q&A maybe like with 10 minutes or so before the panel ends to take your questions. But I did also want to just take the time to get questions from the audience as the panel progresses. And so I will be checking the higher Rails hashtag throughout the panel. And then also, you might also notice that at the bottom, maybe it's a little bit hard to read, but all of our Twitter handles are down on each slide, so if you ever need to tag one of the panelists or something like that, feel free to do that. So before we get started, let's just take a second to have everybody introduce themselves. I'll start. I'm Ceci Korea. I am the moderator of this panel. And as Allison mentioned, I'm super passionate about bringing people into tech, so that's kind of what moved me to want to talk about hiring practices. And then we could introduce the panelists. Hello. I'm Heather Corralo. My company is called CTO2. We help companies do organizational agility transformations. What that really means is we help company cultures not suck. And we talk about workflow. We talk about process. We talk about mapping talent and product and engineering strategies holistically. And yeah, that's me. Hello. My name is Justin Herrick, and I am a developer, a consultant, and a teacher. I've been doing that for my entire career. One of those three. Also founder of Lunar Collective, which is a software consultancy focusing on training and building custom software for whatever you might need. And I'm really hoping to, with this company, set good examples and good practices for how to do things internally in the industry, which then can be shared freely with other people. And that's why I'm here. I'm going to move this forward. I'm Pamela Vickers. I work at MailChimp in Atlanta, Georgia. I'm an engineering manager there. I work a little bit alongside the product, but mostly work on career development and processes internally on our engineering team. Amazing. So just to get started, I wanted to have a bit of an icebreaker, and I would like to hear from all of the panelists. And all of you are also welcome to join with the hashtag HireRails if you want to share. What is the worst job interview you've ever had, whether you were interviewing someone or you were being interviewed? Okay. I have one. I don't know if it's my worst, but it was very memorable. I was interviewing with a two or three person startup, and they had not done a lot of interviews themselves, and they thought they should probably just do a whiteboarding exercise since that's what you do in interviews. And they were describing it to me, and it was one of those questions where there's like buckets and there's red balls and black balls in them, but they couldn't remember how it went. So every time I'd start, I'd start trying to do something like, wait, no, no, no. You pull one out and you do know what color it is, and then you put it back. No, that's fine. Just keep going. So maybe not the worst, definitely not the best. All right. So I was talking to Ceci about this last night where I have a bunch of bad interviews that I could tell, and worse is kind of in the eye of the beholder. But I've got one story I think works really well. I was applying for a job at a consultancy, and you know, you had to like submit a bunch of code, and they were going to review it. I got flown out to Chicago, I'm sitting in a big office. They actually had like projected the code up on the wall, and they're kind of just doing kind of like a mob code review. They had like four or five people in the room, and they're kind of just asking questions. It was overall pretty expected. It's a code review, and I'm answering questions about my code. And there was this gentleman in the back of the room, and at one point he kind of chuckled, and he pointed, and he said, what are you doing on line 45? And I look at it, and as soon as I look at it, oh, God. So I had a string, and in that string I was interpolating a value, and I had called 2S on that value, but I had also called 2S on the string, because apparently I wasn't sure if it was a string, so I did it three times. And I was just mortified. I fixed it, and he said, okay, good, good, good. And then after the interview was over, he walked up and introduced himself, and he's like, hi. My name's Robert Martin. You can just call me Bob. Mine is going to show my age. I was in an interview, I was working for a financial services firm, and we were interviewing a C-sharp developer, and the developer that I was interviewing with asked this woman, who was from Canter Fitzgerald, what she was doing on 9-11, and why was she here? You see, Canter Fitzgerald lost 105 people in the trade center bombings. And they were her friends, and she had been working in New York at the time, and for whatever reason she hadn't gone to work that day. And we were now in London, and it was four years later. And if you ever want to see someone fail at sensitivity and empathy in an interview, that's the way to do it. Wow. Mic drop. All right, so let's get started with sort of like the first piece in the hiring process, which is job descriptions. And we'll be talking about job descriptions from an employer perspective and an employee or potential employee perspective. So to get started, how do you write a good job description? How do you write a good job description? I think that the first thing is figuring out why are you writing that job description to begin with. What problem is this new individual or individual is going to be solving? And what skill sets or attributes do you not already have on your team in order to solve said problem? That question, you know, there's the idea of, you know, let's throw bodies at problems versus let's figure out what problem we're trying to solve and what skills and attributes do we need to solve for that? And so I think that those questions need to come at the very beginning. Yeah, I agree. From my perspective, as like an employer and as a developer who will be working with the people, I intend to hire. In my job description, I want the candidate to have a very clear idea of what their day to day is going to be so that they know what they're getting themselves into. I like to focus the job description on what am I expecting of them when they come in? What do I expect them to be able to deliver? What time frames do we normally do projects on? And how will their day be scheduled? And I kind of think that fits in a job description because that clearly outlines what the job actually is, not just a bullet list of like acronyms, which you could do that for a thousand companies and get a thousand different jobs in the end. I'd really rather focus on writing a job description that lets someone know, oh, this company is unique. They do two stand-ups a day and they're upside down, you know, or whatever. Yeah, I'll just echo what my other panelists have said, where I think focusing on what the person will be doing in this job is more important than what their previous experience was. So focusing on you need to have already done these things might not be as important as saying these are the things that you will be doing. Another thing that we are at MailChimp are specifically trying to do more of is give an idea of what the organization around you is like, reporting structure, especially since we are a growing company and that's not always clear when you look at a job description, like who am I going to report to, who, what sort of team am I going to be on and how far away am I from people who can, you know, make decisions and pass along my feedback. So we try to give a really clear idea of what your life in this role would be. And I think this might be a little bit more applicable to larger organizations, but how do you manage different sort of requirements between groups? Because oftentimes you have an open job rec, but this person is going to be shared among, you know, two, three different teams and then there's like all of these different sort of responsibilities. How do you manage those sort of different types of requirements when you have multiple groups involved? Do you mean if one person in a role will be wearing multiple hats? I think you have to be very explicit about that. I know that I have interviewed before somewhere and realized that I was interviewing for five jobs, maybe, instead of just one. So, and I think that's fine, depending on where you are in your career and the sort of investment you want to put into a new role. But I think putting that up front, either in conversations or in the listing itself is always ideal. Yeah, I think it would be helpful if that's particularly the case to try to filter for people who get excited by something like that. I know there are people who really enjoy having multiple reports and being able to jump between different things. They like the pseudo challenge of like, okay, I'm working on this on Monday and this on Tuesday. Well, if you want someone who's gonna have to do that, you should say in the description, like looking for someone who enjoys this type of work or this type of workflow. So let's switch over to the job seekers point of view and what advice would you have for those who are looking for a job and they sort of need help navigating and reading through job descriptions, sort of almost reading between the lines? I don't want to sound like I'm plugging my work, but I gave a talk at an ultra confident Atlanta called Job Listing Minesweeper where I focus on this question, but high level, there are very common phrases that you'll read that mean a very common thing. So read a lot of them and ask good questions, be very critical about what something that can sound fine might actually mean. I know there's a lot of talk about culture fit being a good signal that there might be a problem. There's lots of things along those lines. So I would also say, send job listings that you think sound great to someone who's been doing it for a while and they might help point out some of those things to you. I had something really good and then I lost it. Can you elaborate a little bit more on some of those specific words that might be a red herring for someone trying to decipher a job posting? Some of the ones that I picked up on where sometimes there's just really aggressive language that I tend to expect out of maybe an all male team saying like we just kill it 24 seven, crushing it. Ninja hackers only apply. Yes, definitely avoid the Ninja hackers. But there are some that I think are also fine. You just need to make sure you clarify what it means at that company. Things like flexible vacation, that might be great, but it also mean you never take vacation because people kind of look a scan site you when you suggest the idea taking a day off. So again, it's not all bad things but things that are a little vague or a little too pointed sometimes. Strict, strict requirements probably shows that they don't really have a good awareness that there's great developers that come in all packages. Yeah, I think along those lines, it helps to look for the technologies they require and make sure they're not asking for more years of experience than the technology's been in existence. So if you see any of those like need five years, minimum react experience, you might wanna go, maybe they don't really know how this should get written. Very similar to what you were saying. I think when I sit down, I sat down with a lot of juniors as they're kind of like post-code school getting ready to ramp up and they're looking for jobs and I go through these interviews and it is kind of this like game of like ticking off boxes of like, okay, this is a plus, this is a negative. This is a plus, this is a negative and then you kind of get a feel for it by the time you get to the end. Yeah, things that are pluses are like, oh, let's talk about our process. Like I always tell the students, okay, look for them to mention any agile practice or mention testing or mention their version control and stuff, but if it's not mentioned but they mention their ping pong tables or they mention certifications, it might not be what you're looking for in this, in our community. But ultimately I think the job descriptions are there to make sure you as the job seeker know what you're getting into. So if you have no clue what that company is gonna be like, well you won't know till you get there, I guess. And that's not really very helpful for you when you're trying to apply the different places. I'm curious, are there any HR or tech recruiters in the room right now? Anyone who writes job descriptions for a living? Awesome. Okay, well you're very brave to raise your hands, sir. We won't tell anyone where you're sitting. Yeah, so I was a tech recruiter forever and I think that there's this great intention to make your company sound so cool and fun because it's so competitive to get out there and your hiring managers are breathing down your neck because they desperately need these people and damn it, we just bought a new keg. Why isn't anybody wanting to work here? And the thing of it is that if you write work hard, play hard, free beer, unlimited vacation, what that's really telling me is I'm gonna work 60 to 70 hours a week, I'm gonna work in an environment that may or may not be safe for me as a woman that identifies as a woman in that space and unlimited vacation is not the same thing as minimum vacation and that's a little pro tip. Minimum vacation is awesome, unlimited vacation is a sure sign that you are going to not be able to take it. I've seen that over and over in small and large companies so really talk to your HR teams or talk to your teams and say what does this really mean to us? If you do have unlimited vacation, you can say minimum vacation on our team three weeks a year, right? Like I'm gonna apply to that job, so. All right, so to move things along, I wanted to talk about once you have a job description out there you have applicants, let's talk about how to assess your applicant's tech ability and I wanted to sort of take a little bit of time to set the stage for this question. There was a great episode of a podcast called Invisibilia where they talk a lot about the mind and they did a study where it was called the white coat study and they gave people a task to perform and half of those people were told, you're wearing a doctor's coat, the other half were told that they were wearing a painter's coat and the people who were told that they had a doctor's coat performed better than those who were told that they were using a painter's coat and I often feel like how we assess tech ability and tech is either telling someone that they have a doctor's coat or a painter's coat, we aren't always setting up people to succeed or giving them the best of environment to assess the tech ability so the big question is and it's not an easy question but we'll try to tackle it, what is the best way to assess tech ability? Make them do what they're gonna do on the job is kind of my go-to. So that depends a lot on what the role is. Recently I was hiring for my consultancy and I basically had like a two-step code challenge where the first one was they had to just build this app out and any technology they wanted, they had unlimited time to do it, just give it to me when you're done and I wanted to see their ability to do something when they have full control over the choices and the timeframe and the methodologies and then I made them do a second one where I dictated everything, like the requirements, the language, the framework, how much testing coverage they should be, I wanted to see what the difference is in their output from working with dictated technologies versus they can choose their own because at my particular business, at the consultancy, they're gonna be doing both. They will be able to do green field projects but they'll also be having the opportunity to just use what they've been given to them. So you would need to adapt that to your company but I find things like code challenges, things like bringing them in and pairing with them for a few hours. For me personally, as a developer, it gives me the best insight into this person and to how they work and how they think. We've had a lot of conversation around how to do this because this is really, I think, one of the toughest things. It's not as hard to find people that you like, that you know would fit into your team and be a great teammate in general. But to know whether they can come in and make the impact that you really need for whatever level you're hiring for is really tough. We are very reluctant to ask them to do work outside of their own work that they're probably already doing because not everyone has that time but it truly is a great way to tell tech ability. So what we have been doing and we've been very happy with what we've been able to find out by doing this is we just ask for a code sample and we try to frame it as best as we can and let them know that we're not judging them on the code sample. We just want a foundation for a conversation. So we ask technical questions but then we also just sit with their code with them and we ask them if you had unlimited time, resources, money, what are some things you would do to improve or expand this. So we try to work with something that they're familiar with because you get a lot of insight when you hear someone talk about code they've written and sometimes the insight is they don't understand the code that they've written and sometimes the insight is just so much depth that you wouldn't get just from reading the code. So we try to have a conversation, almost like a live code review without us being critical necessarily, asking guiding questions or I see you did it this way. In my mind, I think I would have tried it this way. Did you consider that? So we try to have those conversations while setting up early that it's not about the quality of the code, it's really about the quality of the interaction around the code that we can get a lot of helpful information out of. I think something else to take into consideration that I've seen happen in larger companies is if you're hiring more senior engineers that might have a primary language that's different from your current stack, making sure that you have the right person interviewing and reviewing that person's code versus just another person who's on that team who might not be as familiar with that language. And I don't know if this will be a true or full statement that people will nod their heads with in this room, but I think the more seasoned an engineer becomes the more strong a point of view they might have in their code base and what they're writing down. And that should be okay. And so having someone who can just make sure that you have someone who's interviewing that person who's capable of understanding A, that language and B, that point of view and where that might be coming from because what could be a false negative may just be a point of view. That's a great point. I wanna take a second just to see if we've had any questions from Twitter. That's actually a great question. Go ahead, I don't know if we want to, let's just do it. How do you best inventory your team's existing skills? Just why a lot of people don't do it. Like how many units of Ruby you have on your team? We have three widgets of Ruby, two widgets of JavaScript, one of React. That is tough, depends on the size of the team. I feel like on a small enough team I could pretty quickly whip up an estimate of like, yeah, my team is three quarters, really strong full stack Rails developers, one person that likes JavaScript. And I would feel confident with knowing that spread. But if I'm managing a team of 20 plus, that'd be really hard to kind of get the nuances of what everyone's at and where they are and what's their detail. I almost feel like you could kind of self report that almost, like you could get information, pass out a survey, have everyone sit down with you for a one on one and say, hey, I wanna know. How good are you at Rails? No, just tell me, how good do you think you are? You wouldn't be working here already if you weren't good at it, so I just wanna know. And then we can kind of, oh, look, they all say they're good at this. Now we kind of have an idea at least of the averages for our team. Yeah, that's a great idea. You could even look at get stats. I would say it's probably easier to look at the negative space, right? If it's probably harder to look and see what you have than to look and see where you're a little bit weaker. So if you have certain projects that don't get good momentum or you have certain parts of the code base that just never get the attention or the expertise in there, it's easier in my mind at least, especially when you have a larger team, which our team is rapidly growing. It's easier to see, we really could use someone that really knows this or has a lot of experience dealing with this type of issue. So I would have a hard time telling you what our current inventory is, but I could tell you some of our needs for sure. I think it depends on the health of your team, but doing a team retro when you're starting to look at workforce planning or hiring the next person for your team, bringing and engaging the entire group into the conversation about their own skills and where they're really kicking butt and where they'd like to learn or what someone new to the team could bring is a really great conversation to get people engaged in the interview process as well. So I have a bit of a devil's advocate question. Why do we even need to assess tech ability after a certain point? Like if you are a developer, you've been doing this for 10, 15 years, like at what point can you just move past a code challenge or a whiteboarding? I mean to be very just crass to know how much to pay them. You want to make sure that people with similar abilities are getting similar salaries. So we have an engineering ladder that we use to kind of compare people. We don't really want to say oh person A versus person B, but just groups of people and what they should know, what they should excel at and where it's okay for them to have, you know, things that need to be stronger over time. So I would say someone could come in with 15 years of experience, but not be able to contribute more than someone with five years of experience, but they might be wanting a 15 year experience salary. So that's my first answer. Good answer. All right, so to move things along, I think I'm actually gonna skip this question. Let's talk about this. How do you get noticed in a sea of applicants? This is a question that I hear a lot from people saying, especially if they're junior developers, you know, should I just print a bunch of resumes and start dropping them off at companies because I'm just not hearing back? So how do you get noticed? I'm making everyone nervous by doing this. So when I would teach, what I would tell my students is halfway through like the entire cohort, I'd be like, okay, here's the secret to being noticed when you apply for places. And it's a horrible secret. It's the one you never want to hear, which is give talks and write blog posts. Don't just go to meetups. The problem with that is it's not a like that fits for everyone solution, but it is a guaranteed solution. If you're not just the person who sits in the back of the meetup, but you say, hey, I know enough about Cucumber. I can give a talk on it at a local Ruby meetup. That's gonna make you stand out because hopefully the companies you're applying for in your town are also there at that meetup and they see you with the one on stage, not just the one applying. Same thing with blog posts, like writing blog posts that are like informative and telling a story or not telling a story, solving problems and like contributing back to the industry, build up a body of work in your name that speaks volumes to you that differentiate you from every other applicant and might be applying for the same position. If you have technical recruiters who are good, they're probably also looking at your GitHub. So if you're a boot camper and you've been contributing to your GitHub and I see your progression for the 12 weeks and you're adding stuff and you're working in open source and you're doing great work and then you graduate and it's six months later and you're working at West Elm, waiting for somebody to pick up the phone and you haven't put forth any new code and you haven't been working or contributing, that's a signal. And I think that can limit your opportunity as well, especially if you're a super junior. So we have about 12 minutes left and we still haven't talked about diversity, which I feel is a really important topic. So I'll just throw it out there. There's a lot of talk about hiring diversely and a lot of people feel like it's not needed, it's no longer a problem and a lot of people feel like no, it is something that we should address. So why is hiring diversely important for companies? I mean, if you go back to the idea of looking at the edges of your team and what's missing, if everyone has the same background, you're gonna have a lot of the same missing pieces. So even from a business perspective, having people with different backgrounds and different life experiences, you get more of those pieces covered. So you can just build better product. I feel like this isn't a crowd, you have to sell the human value of having a diverse team, but you definitely get better coverage when you have people that know different things for different reasons. Yeah, for me, every team I've worked on, that's had a diverse group of people in it from different backgrounds, different ethnicities, different genders, the products ended up better in the end and we all grew more in the process because like you were saying, you kind of learn from the gaps in your own understanding and your own perspective and that can be filled out from the people in your team and having those different voices with different backgrounds can just show dividends to the whole company culture as well. Is it wrong if I talk about culture fit? Are we jumping ahead? Go ahead. I think when we think about hiring diversity or diversity, we need to change our vernacular. I'm a recent non-smoker. I quit 12 days ago and yeah, woohoo! But I don't say, if someone asks me, I don't say I'm quitting smoking. I say I'm a non-smoker. I don't smoke anymore, which is helping me to not smoke anymore. So instead of saying culture fit, I think it's really important for us to start changing our vernacular and start talking about culture add because if we're adding to our culture, it's much easier for us to connect that to hiring diverse and inclusivity into our teams and into the organization that we have. Yeah, and I could talk about this for a long time so I won't go on on a rant. But yes, culture fit comes from this idea of our culture is good now. We don't want to ruin it because a lot of companies aren't proactive about shaping their own culture so they just kind of let what happened be the way it is and they're scared they're gonna break it. You should be proactive about shaping the culture of your company and that means how can I add to this culture in a way that's gonna benefit everyone on the team? So I wanna, before jumping into questions from the audience, I wanna touch on the gender gap. And just to set the stage, there is an article, it was a study that Hewlett Packard conducted a few years ago and there was a Harvard Business Review article about it. I couldn't find the original study unfortunately but the study essentially found that women apply to a job posting if they meet 100% of the criteria whereas men apply if they meet 60% of the criteria. And what I found really interesting about the analysis from the Harvard Business Review article is that they felt like what women felt was holding them back was more of this perception. It's not necessarily how they perceive their skill but a mistaken perception about the hiring process. I think that's really interesting. So question here is, do you agree or disagree with the student studies findings and what can we do to address it? I totally agree with this. I see it happen all the time. Stop putting so many bullet points and stop putting five plus or six plus or seven plus years of some experience which isn't really what you're really saying. Somebody might have three and be great. So what are you really articulating in that bullet point and maybe create a narrative out of that rather than a bullet point because I see it happen a lot. Yeah, I don't know if I've seen it as much on the hiring side but I definitely see it as someone who works with new developers in the community a lot where I have to just basically direct people and say you will apply to this job and you will interview and I get very like mama bearish about it and I only have to do that with women. I've never had to pull a male friend aside and like you can do it, you can do this. I have to sometimes tell them, I'm not sure if you're quite ready for that. No, I completely agree and both of what you said is basically what I've seen as well and it's interesting to me because I think it goes go back to our first question about job descriptions and how we just have this default of just laundry listing every acronym we think they might need to know in passing and for one person that might be, oh, have you heard of that? Another person might be, do I know that in, inside, and out and I'm terrified of applying for a position and I don't know those things. And I think another thing we could do going back to the job description answer is try to list all of the things that actually occur on the job which could be like, there's a lot of jobs, sorry, every job you do in tech involves a lot of things we call soft skills but those are never on a job description or if they are they're like one line at the very end but like being able to talk to a client, communicate effectively with your team members are things that don't necessarily have like a gender bias either way but they round out the requirement other than just technical things people feel like they need to know. Great, so I wanna turn it over to questions from the audience. I wanna take a question from Twitter first and then we'll open it up for Q&A from people here. So let's see, hmm, so many good questions. Thousands of them, they're just poor. I'm kinda interested in how important is education versus experience? How important is education versus experience? Like one of, can I posit experience is education to an extent in my background? I have a computer science degree and I think it has allowed me to know lingo that made other people feel lesser and I did not have to feel that lesser sting and that's about what I got out of my degree, so. To kinda add on to that, I don't have a computer science degree which I kinda mouthed as she was speaking but what that means is I have spent over the years of being a self-taught programmer countless nights reading Wikipedia articles for no value other than I wouldn't feel dumb anymore when people would say things in passing. So I can throw out all this conversation stuff about monads just because I read them because someone said they're hard and I wanted to make sure I didn't feel dumb in a conversation one day, you know. Right, so let's turn it over to the audience. So just to repeat on the mic for the recording, are there any practices that you're trying to recommend in your company that are considered too progressive? Yes. Yes. If you wanna talk about teal organizational structures, you can talk to me after this session. I scare HR teams a lot more than I scare engineering and product teams. I think organizing your business and your organization versus changing your engineering structure is super scary to people, so that doesn't mean it's not the right thing to do though. Yeah, I would say not too progressive, but the same where our engineering team is on board to do anything. It's just a matter, do we want to formalize things in the policy while we're still figuring out how well it works? So that's kind of where we are on things. Yeah, I don't think I've currently come up with something that's too progressive for someone, but I have had the conversation of talking to a client or a company about their existing hiring process and telling them that they're filtering for the wrong thing. Like a lot of companies have noticed have made their hiring process longer because it's hard. I'm not gonna fault them for that. It's hard and they don't know what they're doing half the time and you just gotta wait it out sometimes, but that just means you're filtering for the person who has the most time and has the most ability to wait which normally is filtering for some type of privilege or whatever, which way you look at it. And that's normally not what the company wanted at all. They wanted someone who wanted to work there. It was a good fit for what they do. And instead they filtered for the person who could wait around a month and a half and then another month and a half and then do the fifth interview in a row. And they don't mean to do that. So I think we have time for one more question. Yes. So the question was how do you measure productivity after a new hire when your whole team is remote? I normally use agile for that. I'm not trying to say that as a dismissive way, but in most of the remote teams that I've worked with, we kind of roll them into our sprint planning process and we have them do the same estimations we do. And I normally expect a certain amount of lag time as they ramp up on the project and I kind of build that into the hiring process. But after, I would say after like a month or two, we start evaluating, okay, this is where we expect you to be, this is where you should expect yourself to be. Let's measure what the output was, sprint after sprint and start to see how we can maybe make changes on that. Great. So we have like one more minute. So maybe one more quick question. So how do you normalize feedback from team members who are conducting different interviews? We use an application called Greenhouse and you do scorecards. And we worked very hard on the questions on the scorecards and you're not allowed to talk to anyone that was in the interview until everyone's done the scorecard because it's so easy to introduce bias. We're like, how did you think it went? And you're thinking it went great. And someone makes a weird face and you're like, oh, I must have missed something. So then you start looking for the bad thing. So we have everyone do this big brain dump with some very specific questions. And then we read it all and it's very clear if some people had a very different experience. And then we debrief, but a lot of times there is pretty good alignment or you can kind of pick out where the similarities are. So keeping it, keep not talking until you write down all your thoughts and then getting the thoughts together has been immensely helpful for that. I can't stress this enough. Every person who goes into an interview is representing your company, they are ambassadors and they should have interview training before they go into that room. So if you aren't interviewing, interview training the people who are interviewing those candidates so that they can feel comfortable in writing in that greenhouse and having that conversation in the debrief. It's a huge win. It's very low cost and high impact. All right, well, thank you everybody. If you still have questions, we'll be here. We can talk out in the hallway or maybe we'll do a bop, I don't know, but or you can also reach us on Twitter. So yeah, we're here to continue to talk to you about all this stuff. It's super exciting. I'm glad we solved the problem.