Hey everybody. You're here for the Interviewing Like an Interview. We're at Interviewing Like a Uniform panel.

How to interview and how to hire a great team. My name is Alan Brandt. I'm the co-founder and CTO of Hire.com. Here we have an alien learner. Actually, do you want to introduce yourself and tell us about how you got into the whole interviewing.io? So I've got a winding path. I started as an engineer. Then I dabbled in recruiting for a while, trying to fix some of the things that are broken.

Many of you have experienced some of those firsthand. And most recently I'm the founder of a company called Interviewing.io that seeks to make technical hiring a lot more meritive. I'm Cheki Uder. I work at Hire.com.

Hi, I'm Alaina Percival. I'm CEO of Women Who Code. And at Women Who Code we provide diversity consulting. So best hiring practices, best practices around diversifying our pipeline for our sponsors currently. And we're hoping to expand that further in the coming year.

My name is Ovi Fernandez. I'm the CTO of Andela. We're training 100,000 young Africans to code and to be awesome people in the continent. In my function I'm in charge of recruiting, respectively, those 100,000 people. So I'm doing a lot of interviewing.

And I'll be moderating the panel. Thanks to Alan and Hire for inviting me. Thanks to all our guests. I think we're very interested in finding out from the audience basically what you're looking to get out of this session. Because there's a couple ways that you could get interested in being here now versus the other sessions.

And that would be like raise your hands if you are in this session specifically because you want to learn how to interview as an interviewee. Meaning you're looking for work. Okay, so I'm just scattering my hands. Raise your hands if alternatively you're here as an interviewer and an employer looking to get some insight on that.

Okay, so it's useful to our panelists to understand how to structure the information that you share with the audience today. I think that one of the major themes we wanted to touch on during this panel is one that's near and dear to my heart.

Because on the softer side of what we do, I think it's very important to bring the mention of empathy to this whole process of interviewing. So I wanted to give the panelists a chance to discuss their thoughts around how empathy applies to the recruitment process.

What do you want to go first? One of the challenges that we see in candidates is that they don't help the candidates move their best forward. So essentially it's like a process where you want to see the best of the candidates that are coming in.

And employers don't know enough to actually help them manage the expectations or give them guidance on what you are looking for specifically. Company values different trades differently. One of the efforts that we had was to give them an interview guide explaining each round what we are looking for.

That really helps the candidates showcase their best skills during each of those rounds. At what stage do you give them that guide? From the beginning. So right after they apply? Yes. And just for clarity, I think that it may be confusing because there is a distinction of applying to get a job at Hire and applying to use Hire.

So the way that Hire works is that you create a profile and lots of different companies will reach out to interview you. What Chakra is talking about specifically is when we interview candidates at Hire, we've gone through several iterations of our interview process. And initially we had this process that wasn't very empathetic.

It was a little bit brutal where we would, as soon as we started talking to them, we would throw coding challenge after coding challenge. And we would just really, really get down just trying to figure out if somebody is going to be a fit. Then when we get to the end of the process, what would happen is that nobody wanted to come work for us. We'd get to the end and say, well, great, thanks, your interview process is kind of rough, but I'm not sure if I want to come here.

It may not be the right culture fit. And so then we said, well, what can we do to fix this? How can we improve this? And so we actually started basically doing a phone call with everybody before the interview process starts just to kind of be familiar with the company and talk about what the process looks like. I called with one of the founders. So that made things go a lot smoother. And then Chakra put together this interview guide.

And the interview guide basically says, here's the kinds of questions we're going to ask. Here's what our culture is all about. We do TDD. Here's how we approach things. And there's a way of getting people prepped up. I really like this idea of having a program that sets expectations and creates transparency through the process.

But it's also important to think that while you're going through this interview process, especially if you're in a growth phase as a company, you're probably doing this a lot. Whereas the people coming into this situation, they're only interviewing maybe once every couple of years.

And so they are coming to this without the experience and without having necessarily done this every week or several times a week for the past couple of years. And so creating that transparency in the process. And then having the process will also help you evaluate people across the board more equally.

A lot of ground has been covered already. I guess one thing I'll add is that in this market, and I'm sure you guys have felt this, is that labor certainly has a lot of power. So great engineers are in very high demand. And there are companies that still have to wrap their head around this.

And as a result, they're making people jump through hoops very early in the process. So there are companies that will send out soulless coding challenges. And then very good people know that they don't have to jump through those hoops. And that company will no longer be in contention. So maybe that's a very different way to think about empathy.

But think about how many options the people that you're talking to have and be mindful of the fact that you have to be selling very early on. So maybe having people talk to a founder is a very good idea. But don't treat people like they are going through a revolving door on an assembly line because you're just shooting yourself in the foot. I want to riff on the themes that came up here and try to make it a little more actionable for our employers in the audience.

So undoubtedly they already have a process. You mentioned, Alan, that your interview process was brutal. How do you gain that understanding? How do you go from whatever process X is that they have now to one that is more empathetic?

What are the steps to determine and change it? I really like the way actually Nate at Lumber Engineering put it yesterday in saying that like anything we develop, it's also a negative process. So you start out with something that works for you and you just keep iterating on it.

I don't think that it's necessarily the best approach to try to nail the perfect interview process right at the beginning. When you have an interview process, what are the things that you're trying to address? One, you're trying to actually make sure that your process accurately figures out who would be a good fit for your team and who wouldn't. So if everybody gets through your interview process, then you need to be very empathetic, but it doesn't actually do you any good.

But then you want to actually provide a positive experience so that you can get to know somebody in the right context and sort of bring them on board. And so the way that we started out was with just a few problems, a few questions, and we would ask them offsite and we would bring somebody in. And we saw that that was working pretty well. That was our first process was two questions and we asked them offsite.

Then over time we said, you know what, actually, we can ask one of these questions in advance on the phone. What were those questions, just if you remember? Yeah, so with us, the first question is an algorithmic question. So it's not a hard algorithm that you have to come up with, but it's more like here's an algorithm, kind of code this up. And then the second question is an old design question. So in that case, we'll give them a game of some sort that somebody will be familiar with,

like Minesweeper and I'll say, so write this, basically, in any old language that you're choosing. What do you do if they don't know the game? Well, so the easy thing about Minesweeper is you can always sort of pull it out and say, this is Minesweeper, here's how we play, and kind of walk them through it.

One thing that actually I'll do on the algorithm as well is sometimes if somebody really can't get their head kind of wrapped around the actual algorithm, then they'll sort of walk through it and say, well, here's the algorithm that you implement. So it's really not about knowing the rules, being able to kind of put it together. So I want to walk back a second. So there has to be a process, so you should treat it like development.

It's an inverted process. So what is your test? How do you get that feedback to know whether the process is succeeding or failing? So actually, those two questions I thought were related to the interview process itself.

Has anyone tried kind of surveying the candidate to see how they felt the interview went? Is that something that maybe would work? Well, so one of the main things that happens on the platform that I'm working on, and we always survey people after each interview and ask them how you think you did,

and we also ask their interviewer how they actually did. And I've tried graphing these perceived versus actual performances. There's no correspondence at all. People have no idea. When people bomb, they tend to think they did okay. And when people do fairly well, they tend to think that they bombed.

Okay, so is it a hopeless situation? I think that surveying people about their experience is probably much more useful than how they did, but I think probably the biggest test is whether they actually accept the offer or not.

We also do the survey, but we also call people, even if we don't hire, hire them on our team and ask them what can we do to make your day better, and you get a lot of good information and candidates talk to you. Surveys are good, but when you talk, you get a lot of feedback. What are some of the more interesting stories that have come out of that process?

So one of the interesting stories that came out of the feedback that we received was, you know, we have a half-an-hour coffee session in the morning when people come on site before the interview process starts. We talk with the company and learn more about the culture and so on,

so that really helps them get a sense of how the environment is and they're able to project more of their skills during the entire day. So it was an informal kind of thing in the beginning, like a coffee session sort of thing? Yes, exactly. The feedback that they liked about it. What are some of the things that you've heard that they didn't like?

I've often had feedback that when you have several days before you hear back about something, you start to kind of psych yourself out about that company or sort of come up with reasons why that company is not a good fit for you

because you're wondering, you know, are you going to, like, why haven't they given you an offer yet? And so, one, if, you know, you're going to decide on Thursday as a team what to do about it, let the person know that, hey, you know, Thursday is when we're making this decision and we're learning by Friday morning. Something like that, so it creates transparency in the process

so they're not like, oh, well, why haven't you responded to me yet? Or just respond to them right away. So sometimes, like, we have a separate set of orders that are coming to me and it's a little bit of a technical interview. I can't make a promise like that to the candidate because I don't handle it.

That's something like the recruiter will handle a lot and I'll tell them we'll get back to you as soon as we possibly can. We'll hear from Charlie or whoever else as soon as possible. So we have a comment from the audience basically expressing that sometimes the recruiters in the company, I guess it's a larger company, are disconnected from the technical staff that actually does the interviewing

so it may be a little difficult to set expectations correctly. How do you bring these kinds of processes, you know, how do you make your recruiting group more empathetic? Absolutely, that's actually a pretty common situation and one that we've started to run into as well. One solution to that issue specifically, which is the recruiter,

the HR recruiter being not as active in following up is to be very clear who somebody's champion is until he's got a champion on the engineering side. So early on in the process that may be that whoever does the first interview, the person that gives the first thumbs up, then that person potentially says, okay, well,

along with all the other things that I'm doing, I'm going to kind of stay on top of this. You know, that can mean very different things in any organization, but usually that just means literally staying on top of the recruiter and saying, have we followed up? What's happening? When we first started at Hire, it was actually kind of an interesting learning experience. We started with a different name. We started originally with the name Developer Auction. And the whole hypothesis, the thesis originally,

was that we created this high limited marketplace where for one week kind of companies can put in offers and see each other's offers and it's going to create a competitive dynamic to increase, you know, candidates' salaries in case they help, you know, help people, you know, help the market, clearing starts to happen. What happened was we did see a competition, but it was on salaries. Companies pretty much knew what they were paying

and they weren't comfortable going outside those ranges, but companies started to compete on speed. So early on what would happen is because the, you know, the batch lasted a week, sort of Monday through, you know, through the end of the week, people would log in on Friday and put in kind of the offers before the weekends. But then what they would see is that, you know, all the best people that would reach out to them when they put in their offer, they can see all the other companies that are reaching out

and they see, wow, there's like 15 other companies on this group. Let me try to get in there earlier. And the candidate chooses which interview to request and which one to say no to, which, you know, pretty much does what happens, you know, outside of Hire 2 and your regular day-to-day process, which is not as time compressed. And so what happens when you get to the end of that, is people are just less likely to go talk to an interested company.

And so essentially train companies to start, you know, logging in Monday morning and putting in their offers. Well, after that, the competition continues where it's about getting the person to the next on-site to the next on-site. And so I guess one of the best things that helps fix this is showing that it makes a difference, right, that when we move faster through a process, we're much more likely to make habits.

And to address your question earlier, like, how do you know if it's working right? So I think one way of knowing if it's working is if you think about it sort of like a conversion quality, like you have different steps where you want to see if somebody did well on the first screen, if they were interested in doing that, if you gave them the offer, if they accepted the offer, if they did well on the job.

And ultimately, you know if you're doing something right, if you're actually able to hire the people that you want, the people that are doing well on the job, you know. If you're not, then you can kind of go into that and see, well, what's the problem? Is it that people aren't passing the interview, or is it going to be able to pass the interview if they don't want to accept the offer? And you sort of get into that and try to figure out why. Like in our case, we saw that everybody was coming in,

and the first thing that was happening is they were, you know, starting to work on basically the whole challenge. And so in the surveys, we heard it's like, hey, you know, let us get to know the team a little more. We added the coffee break at the beginning, and it really just kind of smoothed out and gave it a great welcome for the day. How many of you are using an applicant tracking system like Greenhouse or something along those lines?

Anyone aware? Very few? Yeah. What do you guys think? Is that a wise move to invest in that kind of system? It would seem if you want to have data about this process, if that makes sense. Yeah, especially if there's a disconnect,

like you mentioned, between the recruiting team and the engineering team. You can solve some of that with technology, and there are two great products on the market. One is Greenhouse, as I mentioned, and another one is called Lever. And there, you can just see a snapshot of everything that's happened in the past. It's happened to a candidate at any given point in time, how long it's taken to get from point A to point B to point C. And you can also set reminders

so that if this person falls out, then nobody follows up with them. You can have the system paying you and saying, dude, you've got to get on this. And that will solve a lot of your problems. Fundamentally, I think you still have to set the expectation that if it's the recruiting team's job to move at a certain speed, it has to be reinforced

and it has to come from the top. But you can take away a lot of the friction around actually making that happen if you get a good ATS. How do you help your team be good interviewers? Because I think this addresses both sides of the equation here.

Because if someone's an interviewee and they understand kind of what the interviewers are, how they're being prepped, maybe that's helpful. But I'd love to hear your thoughts on that. Absolutely. I can comment on that and also potentially give a little bit of advice for if you're in an interview process like ours,

what are the kinds of things that could be positive signs? So as I mentioned, in our interview process, there's sort of two main questions that are the technical, the main technical assessment aspect. And the first one really assesses whether somebody in the program, right? So you have this algorithm that's not complicated algorithm, but it's a little bit tricky implemented. And the second one being the OO problem.

In the first one, what we do is to figure out how to get everybody on the same page, we basically all calibrate. The way that we calibrate is that when one person does an interview, if you're new, if you haven't interviewed before, then you sort of shatter that person and you can look at the other support cards. So a support card is where after an interview you say, here's what went well, here's what went not as well.

And the support card in our case is very, very specific. And I'll tell you exactly how it starts out. So we'll kind of give the problem to somebody, and it's fairly standardized, but we'll paste the problem into the actual use of the quota path, the kind of screen sharing program together, and we'll actually paste that in because we want to make sure that each time the question

is given in exactly the same way. And then the first thing that's on the support card is did the candidate clarify the requirements, right? So all of these things, they're not required, but they are a way of making sure that everybody's looking at the same thing. So, you know, just say yes or no. And if somebody jumps into it and, you know, did the problem right and can clarify requirements, obviously we're not going to penalize somebody for it,

but if somebody clarified the requirements and did test some of these next things, then that might be kind of a thumbs up. So then at the second part after, basically did they clarify the requirements, is did they ask if the good-for solution is okay? So a lot of times with algorithms, you can find kind of a trickier solution of solving it in a more efficient way. We're actually not looking for that.

And if somebody jumps right into doing that, they did it perfectly, again, we're not going to penalize them for it because they found a better solution. But also if somebody says like, hey, is brute-force solution okay? We'll say, yeah, it's fine. You're going to usually have very small kind of inputs, so, you know, that's fine. And that makes the problem much easier. And so what we're looking for there is we're basically trying to figure out not just whether somebody can code,

but can they do it in kind of a collaborative environment. Now, as an interviewer going in to do this for the first time, especially if you haven't interviewed in a while, you can be very counterintuitive. You're in a new environment. You have no kind of, you know, what's going on. You don't know what's expected of you. And it may not seem like you should be asking questions, but generally asking questions is a really good thing. Like, we look for people that talk out loud

and get engaged. And it can be a good idea to actually take a moment to just really kind of get in line with whoever the interviewer is with and get on the same page. I'd love to hear from some of the other panelists. Like, should you go into an interview and not actually say to the interviewer, I'd love to discuss what you're, you know,

what you're judging out. You know, just making me very, very blind. Yeah, definitely being more clear on the expectations and how people are going to be evaluated is going to produce a better result. Some of the, I guess, innovative ideas that I've seen or would like to see tested out is some companies are taking it off whiteboards

and actually coding on a computer. Some companies, instead of going more towards algorithms, are doing more towards, like, actual company code base, so real company issues and problems. I would love to, I don't know how many companies are doing this, but I would love to see a company

actually doing the code challenge over IRC. So without looking at the resume to see that they graduated with a CS degree from Stanford or knowing what their interviewer's gender is, I would love to see a company, yeah, So I think, I think it was Harvard.

Is that history? That's what, that's what my building, pardon? That's what your building is? That's exactly it. So you used her platform. I don't want to say how that works. I think, you know, managing expectations is very important, even for the internal interview team, because a lot of times what happens is

different engineers are judging on different skills for the same round, and that becomes much harder for any candidate to clear the bond, because the expectations are not great. Yeah, so to, to, to drill down on this point, just, you know, to make sure we're clear. So, so one of, I think, might be considered

best practice or at least advice that I've seen is to make sure that the interviewers have a specific thing they're looking for. As an interviewee, you know, if you come in and you're across the table, knowing that studying an expectation is kind of universally, like, a good skill to have,

you know, wouldn't it be good to be just blind and out front and say, look, you know, look, I'd love to understand exactly what it is that you're, that you're judging me on, because I know that necessarily that's not going to come off, right? The interviewer is not going to say, hey, by the way, I'm looking to know if you're a good culture fit today, or.

I think it's much harder for the candidate to do that for, than for the interviewer to kind of achieve that conversation. Why don't you just take courage or something? Why do you think it's harder? Because that person is going, at that point you're going to have, I mean, it might be a good thing,

but it could potentially not be a good thing. The person in the, like, interview position is much more in a position where they need to be kind of putting their best foot forward. I don't think they shouldn't do it, but it's, I think, slightly more.

My recommendation to candidates is do that before you go to the onsite. You know, have a conversation with the hiring manager, have a conversation with the recruiter, work with you, you know, understanding the interview process, what the day looks like, and what are the focus areas for each round. I think if you have a conversation then, it's much easier to kind of dice out the process and give them feedback as well

based on what they're missing from the ideas. As you align with the culture of the company and how much time they're putting into designing the interview process as well. I'm kind of curious about something, actually, now that you mentioned that. So, if a candidate was to ask that, in order for you to answer, you'd have to actually have a process

where you know, like, for instance, who's going to do the interview and stuff like that. How many of you work in an environment where there is a process and you would be able to answer that question? Okay, so again, kind of half the room. So maybe one of the takeaways from this panel is the very simple, have a process.

You know, is there, what is the best way to go down the road of having a process? Will you be buying a tool or, you know, some people like to invent their own things? You know, what's your experience with that? So I think the first part of a process

is basically something that's a standard repeatable process. So doing some things in the same way. So with us, what started out as our initial process was just saying, okay, well, we're going to always ask this question and we're going to always ask this other question and then that was kind of the early part of the process. Then we added, okay, after that, we're going to have a pair programming session so we can see what it's like to work with somebody.

And originally, that was our process. Then after you have something where, you know, a lot of candidates are starting to go through it and then the next thing that you might want is a tool. As Aileen mentioned, the two that are, you know, getting pretty popular right now, Greenhouse is more of an enterprise solution, it's a little bit more expensive, and Lever is a very, very low price point. So really any team, no matter how big, if you don't have half a paycheck system,

you can get started with that, right? And then at that point, you know, into the tool, you would say, well, here's sort of my stages and here's how I'm moving somebody through it. And the second part for us from the process is that it came down to where once it was more than one day, then eventually we had to sort of simplify it down. So we had the first question, we had the second question, so we started to ask the first question in a phone screen.

Well, then before that, we started to do the founder phone call in pre-sell. Sometimes we would do the second question over the phone as well if somebody's remote. Now, at this point, we have multiple touch points, and that becomes a bad experience because you've got somebody that's like, well, I've been on the phone, each time you have to get something scheduled. And so then you sort of simplify things down. But for us, it's basically just doing the same thing repeatable

long enough to where you can actually see what works and what doesn't work. And we do retros on this. Like in the general computer engineering style, we'll actually do a retro and ask what's working. A retrospective. Exactly, a retrospective where all the interviewers will get together and say, Who moderates that in your case? I was moderating previously. Chakra is moderating that with computer engineering.

I'm curious for something to kind of a different angle on the process aspect of it. In your process, are you optimizing to prevent false positives or false negatives? You know what I mean by that? Or maybe you can imagine what I mean by that, right?

I'd love to hear some of the other perspectives on that. We try to minimize false positives in some sense. So it's more of a limiting risk of hiring someone who is not actually qualified.

It's not like we only optimize for that, but I think that's more important because ultimately it's more costlier on the company, it's more costlier on the candidate if it's not effective. That's very important. And going back to your earlier question about how do you make the hiring process successful, I think it has to start with a commitment from the team.

The team has to be committed to having a good process and taking feedback from candidates and improving on it. After all, you want great colleagues to work with us on a daily basis and it has to be a top priority for the team and the community especially. I forgot to say critically. And it has to be a clear champion

who is accountable by all, right? Until then, you know, nothing gets done. Everyone is working, everyone has to do business and so on. So I believe part of having a strong commitment and accountability. So I do think one of the risks with the false positive is that people work towards hiring women a certain box.

So you're like, oh, this person graduated from here, this person worked at this company, this person has this video experience and all of these boxes are ticked. And it kind of goes back to that, like nobody gets fired for buying IBM and you end up missing a lot of people

who maybe have the alternative experience or who didn't graduate from a top 10 CS school. And so I think that the risk in that is that people will push great candidates out of the box. What's really unfortunate is that a lot of smaller companies

take their hiring cues from companies like Google and Facebook and Microsoft. And those guys have such strong friends that they can just have this revolving door of people. So they can be very, very picky both at the top of the funnel and later on. Now later on makes sense because you're potentially judging someone for what they can do. But at the top, they just throw away a lot of people that might be very qualified but don't look a very specific way.

If you look at the strength of your own brand and you're honest, I would advise everybody to just think critically about whether you're blindly taking your cues from these guys or whether your process makes sense for you. And if your brand isn't as strong as Google's, then maybe it doesn't behoove you to throw away everybody

that hasn't gone to MIT and Stanford and has worked at Facebook. And the challenge, one of the challenges is that you actually don't know how well you're doing. You only know for the people that you've hired, whether the person worked out or not, but for the people that you didn't bring on site or that you passed on, you never know if that person was a good fit or not.

And anecdotally, we have one engineer on our team that we did not take through the regular process who joined prior to the point that process was established. And later on, he said, I actually want to take this coding challenge. And this is one of our top engineers, one of the most productive, really, really top guy. And he did the test, and he was very nervous. And he worked on it for a long time.

And essentially, after seeing his results, we would not have brought him here. And that would have been such a huge mistake, one of our top engineers. So the point there is that you really don't know. It's one of the things that we're actually trying to figure out, because we've got a lot of companies interviewing candidates on our platform. And so we can tell that one company said no to a candidate that was then hired by another company

and has done really well. And so that's something that we actually want to try to bring to life. I actually have a friend that went through your recruiting process. This friend was really excited about getting hired early on. And this friend had an interview with a coding challenge. This friend didn't feel that they did very well on the coding challenge.

And then this friend didn't get an offer from hired. I've always wondered. I think my friend has always wondered. But I think the idea here is that the coding challenge is, I think, actually, it's worth talking about the beginning of the pipeline there

and how do you actually scream like, basically, is there a chance that you're inadvertently failing at that level? Just actually what Elena was mentioning, I guess there's a lot of thinking for interviewers when they do the first interview.

And I don't know, from the top of my head, but what she wants to get me to do at higher ed is, out of all the interviewers, what is the success rate of candidates passing the first on-site or on-screen compared to second or third? I think people get better at it.

The hiring part or the interviewing process and getting a new job is one of the most stressful things in life. And you're going into these situations where you're being judged. And so it's a really unrealistic life experience. Are there gender dynamics to it as well?

Oh, definitely. For bringing people on board, data shows that the men will apply for jobs where they have seven out of 10 of their requirements and men will apply for jobs where they have four out of 10 of their requirements. So I ask companies, if you can conceive of anyone

not having that, just leave it off the job description. And you're not suddenly going to get 200 resumes. You might get four. But hey, we knew that one of those four aren't going to be the right one. I also ask people to lower the barrier for application

as much as possible. So if you're going to ask an engineer for their resume or something like that, if you're looking for someone who's not really looking, they have a job. They probably don't have their resume pulled together. They might want to just send you an email saying, hey, I'm willing to talk to you. Or you might have someone who completely has it together

and has been preparing for this, and they want to send you their 30-page CV. So when we invite people to, when we have people post jobs to the women in a good community, we ask that it's 140 characters and includes an email for follow-up, so that you're not going to have room

to put any four years of male's experience when actually you hire someone with three years experience, because in that case, a woman might not apply. So I want to stress what you just said, because I think it's a really important takeaway that the less bullet points you put on the description, the better.

Also, I want to make a suggestion that hasn't come up kind of surprisingly, but at Indella, we have over 13,000 applications to hire 60 people. And you might say, OK, well, how do you screen that? You know, because it's just like an unworkable load to go through. We actually partner with a company called Plon.io,

and they provide an assessment test that takes about half an hour for the candidate to go through. But it tests their problem-solving aptitude, basically IQ, task management, innovation, and 12 different personality profile steps. So we have a particular personality type that we're looking for, and we also have problem-solving aptitude minimums

that we're looking for. So that helps us kind of cut it down. I'm thinking that that process is fairly blind, because when we get those results, like basically, you know, there's no picture or gender necessarily associated with it. So it's especially blind for us looking at African-American laptops. We don't even know what they are.

And it helps in the sense of having a baseline expectation of how that person, you know, what they're capable of, even if they don't interview well afterwards or even if something afterwards indicates that they might be good. So I'm curious about your experience with that sort of thing. Do you think that that would work as well with engineers

where the market is in their favor? I mean, you have a very selective program where people probably kill to get into it, whereas here, you have a much less engaged audience. And I can see people that don't look well on paper being willing to do that, because this is their way to prove themselves. So digging back, I worked at ThoughtWorks for four years. And during the time that I worked at ThoughtWorks,

it was one of the top employers in the world. But it was still a hot market. And when you showed up for the interview, they'd be like, here's the wonder look. There might be issues with the wonder look, but it was basically an IQ test in certain ways. I don't know.

I also think that once you get someone to apply, you can add extra layers. But kind of getting those people to come in the door for the first time, you want to lower that barrier as much as possible. Right. So maybe to answer your question, it's something you do after there's already one.

One thing I've noticed, this sort of comes up sometimes, is people ask, well, why did I have to do this coding challenge? Or I have X years of experience. Why did I have to do this trivial problem? And for us, it's actually also a way of testing out a little bit of the cultural attitude. So we bring in some people that are really fantastic and just crush the test. And then my response is like, OK, cool.

Not too bad. Let's work through this and have a very positive attitude about this, as opposed to others that say, you know what? I don't really want to do this and whatnot. And that's where we come from. Like, hang on. I don't know if I would want to work with this person on a daily basis. So I think the same thing can happen with an at-home assignment or a coding challenge, as long as it's reasonable

and the expectation has been reasonably set. We don't ask somebody to do any sort of testing or assessment until they've had a half hour at home call with one of the founders, right? And so with us, we know that 80% of the people past that phone call won't make it through the interview screen and won't get to the offering stage. But we're still ready to have that phone call in advance at the beginning, because essentially, it's

our way of saying, like, we're going to give something to you, but we expect you to do something for us as well, which is basically to go through this process. One way that I found to kind of combine both of these is to have interview questions that themselves are selling points. So smart people don't really like solving arbitrary problems whose purpose feels

like it's an idiot test. Fizbaz is kind of a canonical example of that, but it comes in all sorts of variants. So if instead, and again, on our platform, the best performing interview questions, ones where a candidate said, like, I really want to work with these people. These are people I've never met before. They don't see them face to face. They just have a conversation. Our questions where you start with something

that you've actually seen and then adapt that situation to something that would lend itself to an interview question. So you can describe a scenario you've seen at work, and then eventually you start writing code. But you also have the person start thinking about the problems that you're solving. And you know that if they're interesting problems, those problems are going to stick in their heads.

So if you can, you know, like people don't care about people on tables or like beer or whatever most of the time. I think they want to work with smart people and solve interesting problems. So the sooner you can get somebody in front of a smart person and have them solve an interesting non-perfunctory problem together, the better off you're going to be. And as we're getting closer on time,

I want to make sure that we have a chance to take any questions. I saw a hand up on this side of the room before. Yeah. What's our comment again? I think it's one of the fairies. I think we're starting to get to the room. OK. So I'll take a question for the audience. Yeah. Hi, guys. I'm Elisa. I'm a single grower at a customs software firm

in New York. And my question is just if you could address more in the very early stage of the hiring process a little bit more in terms of early recruiting tips and especially for recruiting more diverse applicants. From the perspective of an employer? Yeah. From the perspective of an employer recruiting from the early years. So we've been talking a lot more about the interview process. But before you get to that, in terms of attracting

more really high quality candidates and especially more diverse candidates. So the question was how do you attract candidates and especially diverse candidates? So shameless plug, Women Who Code has over 25,000 technical women. And we have job postings and the code review every week.

So I think your question is sort of around what in the hiring process is doing for sourcing, right? How do we get people into the door? And I'm going to say that for me, this is something that I did not know anything about. And that's where this company came out of that was failing to source for many months.

And at this point, what we do at Hired is we bring people in across in many different ways, right? So from sponsoring events such as RailsConf to we have your tech on LinkedIn. So sometimes we can use networks like that to identify the type of talent you want at scale as opposed to having to message each person.

Messaging people individually, that can be effective as well if you find somebody that's the right fit. And generally, if you're going to do that, then you want to find somebody that's fit for their specific reason. Yeah. I also want to advise you just from experience, have a distinguishing something, whatever that may be. So that develops our purpose, right? We have an amazing social mission, and that's helping us get amazing candidates in the door.

People are cold emailing me saying I'd like to be a part of this. At Hatch Rocket, I had a beach front office. And I was like, hey, come be a surfer and do amazing code with us and do great things. And that's what we're about. It's basically about human psychology and having some sort of hook. So if you're just a consulting shop in Ithaca,

and that's the only thing you have, no offense, but unless you live in Ithaca and have family there, why? Why would that be your number one choice in the next office, right? But if you have something else that's really, really amazing about what you do and your purpose, then that helps you a lot. So then also on the diversity side,

a couple of things in addition to the don't have bullets that don't need to be there. Using superlatives, women don't identify as rock stars or ninjas or the absolute best ever. Using words like learn quickly or things

that are aspirational but still inherently positive. Work hard, play hard is another thing because then you're saying, hey, we're not really expecting a lot of hours out of you. We're expecting you to use your social hours with people who are currently strangers. And those are just things that don't resonate with women.

Real quick, are there any perks that you've found are really good in this environment specific to where we are right now in this room? I guess it hasn't, from what we've seen, it's been less perk driven. So you see a lot of things coming out sort of unlimited salaries and lunches and whatnot. But from what we've seen-

Unlimited salary? I'm sorry. So you're saying the perks, you're saying what you're saying is that the perks are not as important. So what is important? So the main thing I remember is basically

engineers like to think of engineers like, so it's working on an interesting product, working with technologies that they like, working with the people that they like. If it came down to the one most common factor, I would say it's probably not that many people. Any more pressing questions like, which you're going to die if you don't get out?

I'm going to be protecting against- How do you protect against, I'm sort of realistic, how do you protect against doing what? Don't use your career. That's the easy answer.

All right, any other- For hired, what do you ask in the 30 minute first session? Is it technical or not? Do you mean the coffee social? Yeah, so the first part, yeah, so the first part,

it's less of a screening, it's more of a pre-sell call. So in that call, there's never a point where we don't study it on to the next step unless, you know, for some reason we see it's like- Otherwise you'd be wasting a lot of time, right? Right. So the idea is this is entirely a pre-sell call for the candidate's benefit. So we'll talk about what we're doing, So as we're wrapping up,

I want to just make a quick announcement. So we've got a few things. So one, we're having a party tonight. It's going to be an initialized roof, which is a really cool rooftop bar with a view of the city. It's really close to here. If you go to Railscom slash party, you'll see the details. Ovi is going to be DJing there,

addition to being in the Addison Wesley editor of the Rails series and author of the Rails play, and in fact, he's also a DJ of 25 years. I'm also in the month's first party right now. And then we have a room there for a second. So come to our party. It's 6.30, 9.30. The details are on the website. Grab a ticket or something here for free on the event, right?

Also, if you like ping pong, we have a ping pong tournament that we're hosting. So anytime today, come by the higher roof of the Expo Hall. If you win one game today, then you're enrolled in the final tournament, which is tomorrow, and we're giving away a $2,000 signing bonus. So when a candidate gets a job on Hire, we actually pay them a $2,000 bonus

as a deal they get from the companies. And so we thought it would be cool to give that away, too. We won a ping pong tournament. $2,000 prize for ping pong. Awesome. All right. I want to thank all the participants of our panel. Let's give them a round of applause.