Absolutely. For one, just thanks for having me on, Cory. I appreciate the chance to talk about it. And I think there's maybe two things to know.
The first thing is that I actually went three and a half, almost four years into a degree in physical therapy, of all things. Before I saw the Iron Man movie and that movie, like that totally changed my life.
I was like, there's Jarvis and you got like the Avengers going together. And I'm like, why is this not a thing? Why can't we have Jarvis in like the real world? I feel like computers, like can kind of talk to you. Like, why can't they be more intelligent? And it was at that point I switched majors entirely, went into computer science, and I was like, "Okay, I'm going to go for it. I want to learn to do this. I want to get into AI and I want to really understand the field."
And in doing that, naively at the time, I was like, "Well, then, okay, my North Star is going to be Google, because that apparently is the big company to go to if you kind of care about learning about technology." And so I realized very early on, immediately when I switched, like, "Okay, how do you get into Google?"
And it turns out it's these algorithmic challenges, as you said. And so I started very early on studying for them, learning about them and preparing for them.
I made YouTube videos that you can still find on YouTube from decades ago of me, like, explaining concepts that my professor was talking about. And then from there people are like, you're actually pretty good at teaching this. And that transitioned into a couple of roles, and now I'm here.
I worked at Google, I understand AI, and it's a fun kind of rabbit hole to go down into for sure but also... well, as much as you can understand AI, I'd say... that's a little bit about my background.
That is wild. And that's one of the things I've always thought was a bit goofy.
I've got a good friend, he is an amazing interviewer, but he's one of these people, he just spends his spare time just doing HackerOne stuff. Like the amount of job offers he gets when he's on the market, like he'll go and interview at like 10 places and he'll get 10 offers.
That is great. But it's just like, damn, the amount of effort. And then he's just like, "You know, I don't really... I'm reacting. All the stuff I just showed them that I know how to do, like I'm never going to do it in my job. I'm going to make a pretty interface that is engaging and fast and I'm not doing any of this like deep algorithmic work. It's not like I'm building like how React renders stuff, I'm just building HTML and CSS."
And it's just like, "Man!" and at the same time like I'm not putting that effort in. I'm going to show up, I'm going to put the effort into like, "Hey, I want to work here." I'm going to put that effort in. Like research the team, research the company a bit. But I'm like, I'm not going to try to go and pass your test.
I'm going to show up with what I know, and I want to see if I am a good fit and if you are a good fit for me. Like, that's what I'm here for. And like that's why I said like, "If this is the gate - you have to have read the big red algorithm book - it's like I read it 20 years ago and like I didn't see a lot of value in it in my work day-to-day, working typically in like web frameworks and whatnot." It just didn't hit - if I was building a database, hell yeah, Like, makes sense, right? And I think that scoping is missing a lot of times.
I feel like many people that you see running these interviews... I worked on a team where somebody did this... they sent me some stuff that they had Googled for the interview and I'm like, "Dude, if you have to Google it, what is the point of hiring any of these people?"
And they're googling stuff all day, in and out. Like, so what's wrong with Googling something? I would love to see people Google. I think that's one of the things... like when I'm interviewing people, you know, at Massdriver, we let people Google stuff - I want to see how you find information. Like, that's more important to me than, do you know the answer to the problem? Do you know how to find the answer to the problem? And I feel like that's not really reflected in a lot of, like, technical job interviews.
I would love to know, how do these hire a bank robber style gigs work? How did you learn how to pass them and kind of prod them for their weak points?
Sure, yeah. Let me kind of just step back and set the stage for it for a second.
So I think as a coach, if you go and you teach people how to pass interviews, the natural thing that always comes up is like, "If I don't know the documentation, can I Google the answer?" I know when anyone asks that question, what they're really trying to kind of probe at is like, "What are the things I can ask? Or what can I Google? Or can I use an LLM?" And this naturally sort of devolves into this conversation on cheating.
Like, "Can I cheat? What is considered cheating? If I was going to use the LLM in my day job, do you count it as cheating?" And just to be clear, I have a very, very clear line as to what's cheating - if you're using an LLM without your interviewer knowing you are, that's cheating. Like, if you can tell them and you don't think it's a problem, and they don't think it's a problem, that's not cheating. Very straightforward.
But because of this conversation, it naturally sort of dovetails into me realizing that it's really easy to cheat in an interview. And that's not something maybe you want to advertise on a podcast, but it's like, it's actually not as hard as people think it would be.
I did a study for a big mock interview company called Interviewing.io. A study is maybe too strong of a word for it, but basically we did experiments where we paired people up and we asked them to cheat. And we had professional interviewers from Google, Facebook, Netflix basically do these interviews.
And we asked, "Hey, did you notice anything wrong with this person? Did you see anything wrong?" And some people would be like, "Oh, they were a little slow at coding. You know, maybe it took them a while to get the solution.", but not one person realized that they actually were cheating in the process.
And this was a huge kind of thing in the news. It made Hacker News, it made Wired. And when the release of the post kind of came out, it's like, "Wow, it's actually much easier to cheat than we think it is." And from there, kind of companies started messaging me saying, "How do we prevent it? Like, what are the strategies?" And stuff like that.
So it started off as just a couple of consulting jobs. And then one person pitched me the idea, like, "Hey, I don't know if this is a problem, but I'd love for you to just prove it to me that it is." Let's take somebody that we recently rejected from the interview process that we said, "No, we don't want them." We'll set them up with a different group of interviewers that don't know this is going on. And I want to see if you can help them cheat through the interview. And we did, and it was a success. And we got them through the process. And this kind of showcases how easy it was to cheat.
It's like this whole thing is not set up to be able to support cheating. And that's kind of what I've been doing ever since. It's a fun thing.
So companies will basically hire me to see can I get through the process myself or can I get somebody else through the process. And most people think, okay, this is just online interviews. But we actually there's cool ways to cheat in person with in-person kind of interviews that we also potentially talk about as well. So, yeah, that's a little bit of the story.
Well, before I answer that, I just want to actually point out the fact that, like, you know, for a Pizza Hut kind of pizza, you're like, "Okay, maybe I'll cheat". Now multiply that to this is a $400,000 a year job. It's like, for one, understandable that people cheat.
I think a lot of people want to just be like, "How could you ever do that?" And I think that's maybe not the best way. Like, it's very clear how you could do that. And some people just kind of need a job, so I'm not saying it's right or anything like that, but it is kind of worth just noting, like, yeah, if you do it for Pizza Hut, you're certainly going to do it for a $500,000 job.
As far as, like, how people cheat, the interesting part about in-person interviews is a lot of people don't realize just how small microphones get. And all you really need is one other person and one of these very small microphones and one of these very small kind of earbuds in order to kind of make it happen. And you can just literally have somebody go through... and it's like the old spy tech gear. I've got some of it down here.
But anyways, it's like, you know, you have a little cam that sort of what's on the whiteboard, what am I hearing, or what is the person hearing, and then, like, do I have somebody that can go Google answers for me? Really, you just need one accomplice and, like, a hundred dollars to make this happen.
This is not an endorsement, just to be clear, but, like, this is actually a lot easier than you think it is.
There's a couple of, like, very specific things you have to sort of check for or very specific things you need to not do. So one of the guys I was working with would always just sort of like, do this with his ear. It's like you got to stop doing that. Like there's something in your ear very clearly if you keep like bringing your hand up to your ear, like trying to hear what's going on. So ditch the sort of spy moment where you're trying to do that kind of stuff.
Then you've got to stop moving as a candidate because if I'm trying to see what's on the whiteboard and you're doing this or you're like giving me the nervous energy where you're kind of moving back and forth, I can't see what's on the screen. So I can't help you, you know, if I'm in another room kind of doing stuff.
But yeah, it's actually a lot easier than people maybe would think it is. And that's the in-person.
Sure. So, I mean, you know, when you think about it, you need somebody that's going to be able to help you Google answers or have an LLM.
But most questions that you ask, I think, if you're in-person, you'll find that you might even be more lenient with somebody than if you're over a screen. Because again, in an interview where you're over a computer or something like that, as you said, you're assuming they're cheating. So anything they do, you're immediately discounting. So I think people tend to ask easier questions during on-sites. And that's true even, believe it or not, at like big tech companies - so the Googles, the Facebooks.
The easier questions tend to be once you've passed the online assessment and you get to the actual thing. Sometimes you'll find that the questions are much easier.
So for one, just kind of keep in mind, like, what are you rating here? Are you keeping your questions consistent throughout it? If you're not, that's maybe a indication that you're doing something kind of wrong if you're making it easier for those.
The next thing I'd say is when it comes to cheating, if you have a question there's basically two things that somebody needs in order to get through the process successfully. They need either somebody to feed them information or a way to access a screen.
Now, I've tried a couple of different ways of getting a screen to be something that could be in front of it - so where they don't need an accomplice and it's straightforward. Like it is not an easy task to be able to do. There have been some things where we've tried building it into like a belt buckle. There's a couple of times where I've tried having it be like on a sleeve or something like that and just sort of like over a sleeve transparently. There's not a whole lot of good options to do this yourself, where you have an LLM that's listening in and then trying to do it.
But you could in feed in theory at some point soon have something to do that. Really and truly, if you go into an interview with Ray Ban sunglasses, I think that's a red flag for most interviewers.
It's a good question and I'd say there's maybe a couple ways to address it. One of the most important things to talk about is we have sort of client side solutions and server side solutions to the problem and neither are perfect.
You could have somebody install a proctoring software. And this actually exists in other industries. So if you have... let's say somebody who's trying to take the bar, who's a lawyer but has a disability and can't go into a testing center, like there are proctoring services that sort of monitor processes in the background and stuff like that. So you download some sort of client software, you install it and then it sort of monitors what's going on on your computer and it sort of tracks your eye movement on a webcam and it's just kind of making sure that you are kind of answering the questions normally.
Now that sounds really good. That would work for a lot of places, but most places aren't doing something like that. I'd say that it would eliminate, if I had to guess, probably 90% of the cheaters. You're going to get some people that just really want that hundred thousand, five hundred thousand dollars salary and like they're going to be able to cheat through this anyways. But that's sort of one of the better options - the client side softwares.
You then have server side softwares. If you've ever heard of HackerRank, or CodeSignal is another one of them, where if you were to buy the enterprise level version of that, you'll find that they come now with anti-cheating software and unfortunately those don't tend to work very well.
Now I've had a couple people reach out to me about it and be like, "Don't say that, like this is the main line of defense.", but transparently it just... they don't work very well. And what they can do is they can say, "Hey, here's your web port. And we see that the person changed tabs so they're now on a different tab", "We can see that they resized their screen", "We can see that this person's looking off the screen". There's lots of things that it can do. It can say, here are some red flags, but we can't know for sure that this person was cheating.
Whereas it's very easy to tell if somebody on a client side version of this, like launches Google and starts googling things - it's very easy to tell this person's cheating. Whereas at best, this gives red flags on the server side versions of this. So they're not perfect.
And both of these suffer from the fact that if you just have a second laptop, you know, you can kind of circumvent both of these problems. You just have one screen in front of you.
And that's how I do it with most of my clients, where I'm like, "Look, I'm just gonna literally sit right over on this other side and I'm just gonna like mirror the screen. I'm gonna know what's on your screen." And if you want to be really, really careful, I can even like have a camera pointing at the screen so we don't have any way of detecting through Bluetooth or if you have any sort of like third screen enabled that you might be able to kind of tell from client side software. And then it's very, very easy to know that you can kind of feed people information like that. So it's still not foolproof.
Yeah. Okay, buckle up. This is a hot take. I've got a couple of thoughts on this.I'm going to say a couple things I think are maybe controversial and goes against what you'll see people online talk about.
So most people say the interview process is broken. And I do actually agree with that. But I think why it's broken - I disagree with most people on.
So let's talk about just the data structures and algorithms, LeetCode-style coding interviews for a second. What's good about them is imagine the world before that. You could be asked anything about anything and whether or not it was a good question or a bad question really kind of just depended on who was doing it.
You might have, let's say 10 years or 20 years of web development experience and I maybe have 20 years of web development experience. But the things we did during that web development experience, there's going to be some overlap, but there might be some things that I just, I don't know. And that doesn't mean that if you ask a question about something I don't know, I'm not experienced.
So I think there's sort of that natural problem where it's like if we actually standardize the test with data structures and algorithms and we say this is what is going to be on the test... no foolers, I'm not going to ask you about C++ memory management... it's going to be very much something that you can study for. In some ways that actually just democratizes it and I think it provides transparency when there was none. Remember, Google, not 15 years ago was asking brain-teaser kind of questions.
So I think that'd be kind of the first thing I'd say. I don't necessarily think these coding puzzles suck as much as some people think it does because the way you would normally pass interviews before that is you actually just knew somebody. So you knew somebody at the company who would tell you what types of questions to kind of prepare for. Like, "Oh, this person really likes, you know, the DOM and like know a lot about what a shadow DOM is" or you know, something of that nature. And then it's like really, really hard, like unless you knew somebody to actually kind of get a job.
So I'm gonna maybe pause there for a second. I want to see is there any pushback on that or how do you feel about that as sort of an initial thought?
I mean, I kind of agree. I mean, I think it makes sense to include those questions when it pertains to the work, right? Again, like, it's like hard algorithmic work, right? Like, I mean, it's again, like if you're making databases or you're literally designing Kubernetes, it's like, okay - distributed systems is going to be really important to the job, right?
But then where like most engineers sit, where it's like - we work for a SaaS, we're taking some stuff from a form, we're sticking it in the database and then doing some authorization rules to show it to somebody else. It's like we're mutating hashes. Like, that's what we're doing.
To me, it becomes more about like, "Okay, well, you know, we have a monolith. Like, what are the pains of, like, working on a monolith? It happens to be in Ruby on Rails. Like, how deep is your experience of going from like a Rails Two to a Three project?"
I feel like the context really matters. And I feel like many times it's so easy as an interviewer to be like, "Oh, let's find something tricky. Let's see if they can answer something tricky." And it's like, I'm not personally interested in whether or not you can answer something tricky.
I'm interested in, will you fit in on this team and can you add values to the business?
Which I feel like is... for many engineers that aren't experienced in interviewing or haven't held a leadership role... like, that's just not where many engineers heads are. It's not, "Is this valuable to the business?", it's like, "Hey, like, I'm an engineer, you're an engineer. Let's do some cool engineer things."
It's like,"Yo, this person's trying to get a fucking job. They need money, right? Like, let's not do some cool engineer things. Like, let's not waste their time and see if they're going to fit in here."
So, I mean, I think that those, like, harder algorithm questions make sense. Like, if you're building satellites, hell yeah, this should be very hard algorithm questions. You want to work at... not Boeing, they'll let anybody work there apparently.
So if we fix the process, and we assume that you aren't asking questions that are leaked or questions that you know easily can just have an answer sort of figured out, then I think the next biggest thing to talk about is, as an interviewer, what are you doing?
A lot of people think that when you ask a question, you should change the question. You should be asking different questions all the time.
The problem is it's really hard to know if you ask the same question to 10 different people versus 10 different questions to 10 people... Like what you're going to end up doing is it's just going to be a vibe check on people. If it's the 10 different questions to 10 different people, it's going to wind up being, who did you like the most? Or who was lucky enough to get a question that was easy enough for them to answer.
Whereas if you ask the same question to 10 different people, you can develop a baseline and be like, relative to other people, how did this person do? So it's not really how did this person do? They could have bombed the question, but if they did much better than the average person, that's kind of going to result in, you know, a better score.
So I think from an interviewer perspective, I think 9 out of 10 places that I work at and do sort of this sort of coaching for people are asking different questions for every candidate. And it's crazy to me.
It's like, how can you possibly judge somebody properly if you're always kind of asking, you know, different questions? It's like, hard to judge. So that's kind of one thing I'd say - bad interviewer process, bad interviewer.
And then there's sort of the AI resistance piece, which is like, are you doing basic checks in your process somewhere to see if somebody is using AI to cheat? Because honestly, if they cheated through the coding interview online assessment that you had, that's not a problem, provided you catch them in the on-site where you're actually walking through more important things - like, how would you design a system? If you know for sure that they're not cheating in that scenario, or you're reasonably confident I guess we'll say, it's less of an issue because if they cheated through the leet code question you asked, it's actually just not that big a deal.
So, I think that'd be maybe how I'd phrase that. I want to pause there. Does that make sense?
Yes, the recruiter call. It's just kind of like trying to figure out like what they're interested in, yada, yada. Really, are they interested in the problem that we're solving?
And like that's one of the key things, right? And that's what we try to put into our interview process. Our interview process, but the way that I've interviewed for years, is like I want to know that this person is excited about what we're doing and that they have an interest in the product. Because I feel like when you don't, what you see three years later with that engineer is they're the engineer that's chasing the shiny baubles, right? They're the ones that are like, "Oh, I'm doing this because the engineering work is interesting, not because of the bottom line of the business." Right?
And so one of the key things for us is like, "You know, we're a dev tool. Are you interested in organic dev tools? Are you interested in solving the infrastructure problems?"
It's like trying to get at like the pain that they felt there and the interest there versus like do you want a well paying job that gets to solve hard technical things? Every engineer wants that, right? So that's kind of like our goal.
And then, after that, our interview process is pretty simple. It's two hours and it's not a take home per se.
We ask you to find an open source project that is in the realm of what we're doing, preferably something that you've used before to show that like you know the space, and we want you to find either something that's bugged the shit out of you about that or an open issue that you can work on.
And you don't tell us what it is, we have no idea what it is. We find out what it is at the beginning of your interview process. And so the only rule is you should have the repo set up ready to go. You should be familiar with the problem statement. We prefer that you don't work on the code ahead of time, but we actually don't know that. And solving the issue is not the goal of our test.
And then what we do is we ping-pong... pair program with the person. And so everything we do is about making that person comfortable, right? Because that first thing in an interview is everybody's nervous. And so we're, "Hey, we're going to pair program. But guess what? You get to pick how we do it. Are we doing ping-pong? Driver-navigator? Like, do you want us to code?" Like, I've been on interviews where I write the code, but the person's telling me what to solve, right? And I'm fine with that.
The whole thing is I want to come in and see what it's like for me being the new employee working with you that knows everything about the problem that we're trying to solve. And like, that is our interview process. Did you pick something interesting? Did you figure out, like, what the problem was, and can you eloquently communicate that to us?
Now we're a small company. This probably doesn't work, scaling up to the Google sizes of the world. But like, that's our interview and it is very, I'd say, "vibey", right? Like, only a few people end up interacting with the person, but the goal is to see how do you communicate a problem. Like, did you prepare for this interview?
When people come in and be like, "Oh, I have no idea." And it's just like, "Okay, so you got to pick." And we tell people, like they know what it is - we're going to pair program, you get to pick how we do it, and we're going to play... I mean we're not going to play dumb, we have no idea what we're working on. I'm the new employee, you're the expert, right? And like that's it.
So like, we've felt it works pretty good. Like, we see people, we see how they work, we see what they're interested in. Like we're asking questions, but like we're asking questions off the cuff. It's like, "Oh, what is that? Like, I'm not as familiar with the Golang syntax." Like, "Yeah, so you pick something from Kubernetes or Terraform. This is great. Like, what is that?" And then you'll see them explain interfaces or like talk about it. It's like, "Okay, they understand how the language works. They understand interesting projects and problems to solve in the space. It's like this person gets what we're trying to do."
I know you can Google and LLM shit. Like, I know that you're going to fit in with the team and like you can communicate with other people that don't know what's going on, which is going to be the rest of time, for hiring.
It's usually for what we would consider like a... I don't want to say tenured engineer, but like an established engineer. Right? Not a distinguished engineer, like Google.
But like juniors we have a lot more leniency towards. I actually love juniors. I love apprenticeships. I love bootcamps. I think they're amazing. One of my favorite engineers I've ever hired was from a bootcamp.
This interview process we developed... I co-developed with somebody like ten years ago at a different company... I interviewed this person. They came in and it was the most ballsy interview I think I've ever seen. They sat down and they were like, "I don't want to write any code." And I'm like, "Okay." And they're like, "I use this JavaScript library and it's documentation sucks ass. I want to go through and build a bunch of examples of like how to use it and like work through their docs." And I was like, "You're fucking hired." Like I didn't say that, but I was just like, "Dude, that's a 10x engineer." He's like, "This is hard for me to use, hard for everybody to use. And my whole goal is to make this easier and more well documented." And I'm just like, "Okay, let's do it." And it was fun to work on.
But I think there's real value in bootcamps. We need more software engineers and those people don't have a traditional computer science background. I think they're some of the ones that suffer the most in this algorithmic nightmare of getting a job. Right? And so those we tend to be a lot more like chill with and the interview process is a very similar interview process.
We still want to see like what their melding into the machine looks like with us, but it's not as... I mean it's never really technical for us. It is very... sociotechnical is kind of what we're aiming for. So it's like I don't mind if you're getting the code... now, if you just can't fucking type the language that you said you know, it's like, "Oh, this person might not know typescript."
Yeah, so there's a line, but it's just like I'm not there looking to see like did you nail this on the first go? Did your test pass on the first one? I'm looking for like what does that style look like? And in the scenario where it's a junior, it's like I'm looking for them to actually be open with like what they don't know. And so like seeing what they LLM or Google is helpful to me. And seeing what they ask back, like, "Hey, I don't know, like what patterns do you think would actually work well here?" It's like, "Oh, this is a person who's looking to learn. They're not just like sitting there cornered and saying I'm just going to guess through this by changing this 200 times in a row."
And I think like that's the stuff that makes good teams, right? It's like I know that we can all communicate well together. Doesn't really matter to me what your technical prowess is. Like if you have technical chops, you can grow those and you can learn. It's hard to learn how to be an effective communicator that works well with a team.
And I think that's one of the things where it's like people have criticized us before. They're like, "Oh, it's not... it's very apples to oranges." And I'm like, "I'm fine with that." I'm trying to build people that fit well in this business and that's always going to be about communication, especially in a remote world. And if we struggle with that part, doesn't matter how good of a developer you are, if you can't communicate it, you can't work with people remotely, you can't work with your team.
So yeah, sorry, that was a very long answer for the junior folks out there.
No, no, actually. So for one, I totally agree. I think some of the best engineers I've ever worked with are self-taught and sometimes bootcamp grads as well. Because the thing is they're curious, you know. So of course that's going to win. If you're interested and you just want to... like because you find it annoying or something like that... like of course that's a huge thing to go for.
So as far as like back to the interview process as a whole. Again, I think the smaller the company, the more you can tailor the process and the more you can deviate from the data structures and algorithms sort of thing. So despite what many people maybe would assume I'd say - like where's the LeetCode? - that's not what I'm going to say.
I think I do really like the process. It sounds like the two things that maybe would be the biggest pain points of your process would be again partially the for positions understanding. It's really hard to tell if somebody's senior if they're not doing some amount of both navigating and driving in something like that. So I think maybe enforcing for certain levels some amount of split - like you have to do some amount of writing code, you have to do some amount of driving as well. Maybe something like that could help. And just sort of like leveling people and doing slightly different things based on the position. Seems like maybe there could be some use there.
The other big thing that seems... and I don't know if you would agree with this or not, so you tell me... but if you've ever seen a debate online, you see somebody that's giving bad points but has won the audience. Not because the points are good, but because like they said something witty or something like that. This is the problem with debates. It's like you don't win if you are the smartest person. You win if you, you entertain the crowd the most.
And I think the problem with the way you've structured it, the biggest risk you have is somebody that just comes in with a kick ass idea and it's like, okay, so they just went the whole time and just iterated on what's the best, most kick ass idea for getting through. I'm sorry, I'm swearing, pardon my French, but what is the best idea? And sort of iterating on the idea. And then maybe technically they really kind of suck. But if they're like, I've got a good idea and then you want to love the person because the idea was so great.
So I think maybe that's kind of one of the biggest potential problems with that. Do you think that's actually a weakness on your end, or do you think you sort of suss out within two hours how technical they are?
I think we get a good idea of it. And so like even when we're doing the driver nav... so for people who aren't familiar with like pair programming, driver nav is like one person's typing but the other person's the brain, right?
And so like I've been in that scenario, I'll type all this stuff. We do like to do ping pong and go back and forth. So we do want to see their hands on keyboard. That's usually what I prefer. Some people don't want to do it at all and they're like, "I'll just do the coding and you can just like shoulder surf." And it's like that's, that's fine too. My goal is... like I don't want you typing nervous about the debate. Like I want the debate. I want them in the coolest, calmest position possible so I can see who they are, right? I know that I'm never going to get 100%, but like that's the goal - get it as close to that as possible.
I think one of the things that could be hard with this as we scale is there are only, you know, two or three people that are doing the interviewing today. I am not a person that gets attracted to shiny baubles. So just because you show up with an interesting problem, I'm not going to be like, "Oh, cool, this is an interesting problem." Like, I don't care. My interesting problem is how are you going to fit into this team? But I could see this, going down the line, we've got two, three, four, five principals that are now hiring and, you know, one of them is just like, "Oh, this is a really cool idea." And it's just like, I can see that falling apart.
And I feel like it's one of those things that's hard, it's like how do you have, in any interview process, benchmarks across interviewers? And what is the rate at which - you know, I don't even know how far you go with this - their hires work out?
I feel like that's something we don't see a lot. Like, "Hey, this person's been doing all of our hiring, and like, a hundred percent of the people that they hire are gone within six months." It's like, "Oh shit." Maybe you've got a bad interviewer or a bad interview process there. It's hard to get to that point until you've reached scale, right?
Oh, I meant more of like, I was amazed at how brave this person was coming into the interview, being like, we're going to write docs today. I mean, we still had to go through and do it. Like, so I got to see them use the library. I got to see them build out the examples, like, explain how it worked. But it was one of those things in my head where I'm like, "I've never had anybody show up and be like, 'We're not going to do code today. We're going to do documentation.'"
One person out of like probably like 200 or 300 people, you know, that I've hired over the years. I was like, "Wow, that was awesome." And the person ended up being fantastic. Their entire tenure was like that working with them.
But yeah, as far as like, "Will the problem be super interesting?" It's like, I think it matters because, you know, people will come in, they'll be like, "Hey, like the front ends in JavaScript, like let's do D3 and make a bunch of crazy like diagrams." Or not diagrams, but like graphs and weird stuff.
And it's like, okay, like that was you wanting to play with that library versus like... because we'll tell people like here's a bunch of open source libraries that we use, if you want to pick one of these, great. Don't feel like you have to, if it's within the realm of what we're doing. And I think that's important to us - again, we're at a later stage - because if they can't grasp that from like the docs on the site and like the conversation and they just show up with something that's just like way out there, it's just like, "Like maybe you don't get it."
Sure, there's so many things to unpack there.
So for one, just as far as depth goes, we have like kind of two separate chapters on it. One of my co-authors, who's the head of Interviewing IO, wrote them. She's amazing and she goes into a lot of depth specifically on some of the major like... you know, in JavaScript we have those, you know, foot guns of like how easy it is to screw up in JavaScript. But this is like the salary negotiation version of that where it's like, "What are all the foot guns that you're going to run into where you're going to shoot yourself in the foot before you even get to the point where you think you're negotiating?" So there's so many things people do right off the bat that I think really set themselves up for failure in the salary.
Just one kind of quick example of that would be something like, you know, saying if you're interviewing at... like, a lot of people are like, "Oh, I'm interviewing at Facebook. Should I tell Google that I'm interviewing at Facebook?" And they give too much information away.
The problem is, as soon as you tell them... like, maybe that's a good thing, and maybe that is a data point you want to share, but when you share, really matters. Because they can say, "Okay, great, but we can't interview you for four weeks. So, you know, in four weeks, come back to us, let us know if you passed the Meta thing and then go through." So you'll find recruiters start, like, gatekeeping people based on the information they've shared.
And so I think that's kind of just one of the examples that tend to really mess people up.
A few thoughts on that. The first and most important one to mention is that I think level setting expectations really matters.
So again, somebody that interviewed, let's say, six years ago... different job market, wildly different... you barely try, you get 20 places that want to interview you. You send out 25 applications, 22 want to interview you. Of the 22, you get six offers. That is actually a very common case for the average tech employee in two thousand nineteen. And average is... okay, we have to kind of define what we mean... but, in general, it was very common for those sort of numbers to be put up.
Now.. I do, again, sort of private coaching with interviews... the average person that I work with, we try and get through about 50 to 100 applications per week. That is just a wildly different thing. And then at the end of about two months, most people have interviewed at about 10 companies. Now what I find is, you know, when you start doing the math on that, like, that's a lot of companies to have kind of done applications for. There are certainly ways to improve that chance.
So some things are like, okay, you know, I went to University of Michigan and I have people at Salesforce that also went to University of Michigan. So let's go contact, not a recruiter, but like an actual person that worked there and was like, "Hey, you work at the place that I want to work." Like, let's actually make that connection and go that way.
I feel like people want to just click a button to be able to get through this, but really, this is more than ever about who you know. And I don't mean that in sort of like, you know, somebody that worked at Ivy League. I just mean finding and leveraging the best places of your network. And people always say that, like, the time you most need your network is when you're least able to just sort of like build it. And like, a lot of people are in the case where they need to build their network over the course of a couple of months before they start consistently getting leads come through.
