Transcript
Hastie: I'm Shane Hastie. I'm the Lead Editor of Culture and Methods on infoq.com, among other things. We have Lusen Mendel of Karat. Finbarr Joy of Superbet. Sally Goble of Attest. Trisha Gee of JetBrains.
Background and What to Look for When Employing Senior Technical People
We're exploring the ideas of recruiting, interviewing, and hiring senior development talent. What do you look for when employing senior technical people?
Mendel: My name is Lusen Mendel. My background is in engineering, engineering management. These days, I work entirely full time on how to hire and assess engineers. One thing that I like to do is start with competencies. Your ultimate success metric when hiring is the performance review, I like to think. Is someone going to succeed in your company? You're walking backwards from there and figuring out, what are the skills and experiences that are relevant for this job, important, useful? Then you have to figure out that step 2 is like, we only have so much time in a hiring process. What is actually important right now, that they're not going to learn on the job or through onboarding? Walk backwards in that way. We can see some of these things come out, for example, with competencies, you want to be really clear on the verbs. An early career engineer might just need to understand a system architecture, but you might need your more senior engineers to be able to create it. That might inform the hiring process in a different way. You can walk backwards from that when you're designing your formats, and questions, and rubrics, and things.
Gee: I think what was just said that was super important and yet so understated, that you don't realize that most of the industry is not identifying the competencies that are required. Is not understanding, may not even have a formal process, a performance review process. Might not know which key skills are required.
I'm Trisha. I work for JetBrains. I have been a Java developer, was a normal, everyday 9:00 to 5:00 Java developer for 15 years. Then I've been doing developer advocacy for the last 6 years for JetBrains and 2 years for MongoDB before then. I was a Java developer in London, which means that what happens is you change jobs, like every 18 months, because that's what you do in order to progress yourself career-wise. I have been involved in a lot of interviews, in terms of me being interviewed. I've also interviewed at a bunch of different companies, like smaller companies, bigger companies.
I can tell you, there are a number of companies who don't necessarily set down upfront what they're looking in a developer, senior or junior. They might have a formal interview process with a number of steps. They don't necessarily brief or train their technical interviewers in, you're looking for these keywords, or you're looking to probe this skill, or you really want to find out whether this person will be comfortable working in these environments. Of course, on top of that, in a lot of interviews, you don't even see someone's code. You might see code on a whiteboard, but you don't test them in a realistic environment. I think that's where a lot of these technical interviews fall down because there's a disconnect between what you're looking for in the interview versus what you actually want that person to do in the day job.
Joy: Finbarr Joy. A longtime CTO, 20 years now, gaming, telecommunications, advertising, even legal, currently working as an advisor. What do you look for? Predominantly, T-shared capabilities? This is about those senior individuals. Ideally, they've got to that point in their career where they're starting to blend out more of the capabilities, therefore, the effect they bring to the team is a lot more meaningful in terms of hoping to build that generalization, a more we can do, to reduce dependencies and make the team more productive. The benefit is that we've now got a senior individual, we can now see them bring benefit to the team. Certainly, levels of T-shared capabilities, if you like. What areas are you generalizing in now? Bringing that as an overall accelerant to the team. Take for granted, there's always a million and one ways to refine some of these competencies, and we've all used those techniques from the upfront test, to the drill-downs. Also, a level of passion, a level of commitment, the pursuit of wanting to pursue the same route, in terms of what this individual is going to bring to the culture of the team.
Goble: I'm Sally. I'm an engineering manager at a small startup at the moment, but before that, I was an engineering manager at a large startup that was growing a lot, and so spent a lot of the last couple of years doing many interviews. I completely agree with Lusen and Trisha that you need to have your core competencies. When I was thinking of this, I was thinking about senior technical people. Contrary to what you might think, one of the things that I'm looking for in senior technical people is more about teamwork than their technical aptitude and ability. That means somebody who is a structure thinker who can break down large problems, but also communicate amazingly well to other people. It's really interesting in that that's a really easy thing to be able to get signal for in an interview. Can somebody listen to you, and listen to the question that you're asking, and can they answer the question in a structured form? Can they then reflect and figure out if you've got the answer that you want, whether that's kind of technical, cultural, behavioral interview that you're doing? The ability to communicate and listen to a question and answer it is super revealing, and so important, as you become more senior.
Gee: I have another thing, which I think is super key for senior individuals. At the senior level, it's very tempting to think that what you want is a high performer who will get their head down and get stuff done. In actual fact, building on from what you all said, what you really want is someone who's going to enable the team. Your 10X developer is not someone who works 10X faster than anyone else, or 10X better than anyone else, is someone who can help level up the rest of the team. When you have a senior developer, they should be able to teach people. A true expert can teach other developers. Again, that's something we don't always look for in interviews. It's something that should be relatively easy to look for in an interview, teach me something that you know. Tell me about it. Teach me how it works, and let me understand how you teach people stuff.
Dealing with the Imbalance between Recruiter's and Candidate's Efforts
Hastie: There's a question that's come up looking at the imbalance between the effort the recruiters put in and the effort that we ask candidates to put in? How do you call that out? How do you deal with recruiters from that point of view?
Joy: I'd certainly encourage candidates to use that as part of their selection criteria. Again, where the lens is senior, these conversations about senior, then there are abundant opportunities out there. The company that is putting a low effort into the interviewing is sending you a signal. I would use that as part of your criteria for which companies you pursue. Move on. There are lots of great companies out there looking for great people who do put the effort in. Take that strong signal. It might be a bit pessimistic, cynical even, but I would certainly say that.
Gee: I would follow on that it's very much about the level you're recruiting for, like you said. For junior developers, one can expect to do a bunch of interviews, a bunch of technical tests. One can expect to jump through hoops. It's going to take time. It's sucky. That's the price you have to pay at the junior level because you have no other way of proving your ability. At the senior level, you should have some portfolio anyway, whether it's GitHub, or Stack Overflow, or conference talks, or blogs, or user group membership. I know that not everyone has that and I know that not everyone who's good has that. If you do have a GitHub portfolio, you should not have to jump through someone's mindless technical test. Because your code is already visible, you already have a portfolio. You can use those things to say to a recruiter, "I know that you want to judge my technical abilities, or I know you want to grill me on these things. I've already invested time and effort into something that you can use. I'd really rather like you to look at that rather than me invest another 4 hours in something which I've proved in a different way."
Mendel: I'd like to add on to this about being creative in two ways. One is around the interview tracks that might exist. I think what Trisha said is true. For junior engineers, it's a more competitive space in these roles. There's this question of balancing costs, and filtering, and trying to go about that in a way that doesn't degrade quality of signal or quality of experience, while still being pragmatic about whatever costs a company is facing. Not everyone maybe can have phone calls, and maybe has to do tests and things.
I think there's two parts to this. One, I just want to talk about accommodation. The gates of this track can sometimes be more difficult for some people to approach than others. When there were on-sites, people would have to have PTO to go through all of this. Maybe that's a silver lining for a lot of interviews being more remote now. It's a little easier to fit them in. Although if as a company, if you can provide interviewing 24/7, if you can provide some of these things that can make a huge difference. At Karat, more than half of our candidates use nights and weekends to do their first round technical interviews. Other accommodations, maybe you would like to have a homework problem, but you have something in parallel. You allow a conversation instead. Or maybe you primarily have whiteboarding, but for some people who just have a level of anxiety with that thing, and for seniors, maybe you can accommodate in a certain way. You can target your resources. You also provide, in your case, if you'd like to do this a different way, you can do it that way. You find ways to build your funnels, in a way. It takes more work to have multiple tracks, and to make sure you're applying that intentionally. Of course, you can use accommodations, in how you target your resources for senior engineers, or for certain demographics that you find valuable, or certain experiences, whatever the case is.
Another thing that can be helpful is providing redos. If sometimes people have a bad day, just let them try again, with different questions. It's more work. You have to have twice as many questions, and takes twice as much time, but then maybe a second hour for a more senior hire is worth it. We find that redos also very much help candidates. If you don't have the resources to give everyone a redo, maybe you decide, we're going to give women in tech these redos right now, or whatever. We're going to give people from this location. We target our resources all the time in sourcing. That could be helpful.
The other way to be creative here, is just, again, thinking about the formats and with the competencies and be creative with them. Because I think sometimes we want everything. We're like, we want our senior engineer to do X, Y, and Z, and all the things that Sally and Trisha mentioned. Also, can they write some code and solve this whiteboard? Just choose. Be ruthless, prioritize, and decide, is this better for a behavioral or a debugging interview? Or, should they review a project they've already written? Or, should we give them some code to do a code review? Or, should they do a coding problem? Roles are different, companies are different. I don't think there's any one answer here. Being creative could be helpful, and really trying to prioritize, because I think we tend to just raise the bar. We just tend to spiral up.
How to Compete for Senior Talent against Technical Giants
Hastie: Raising the bar and looking for unicorns, how do we compete for the senior talent against the technical giants, if you don't have the deep pockets?
Goble: Representing a company that doesn't probably have as deeper pockets as some of the others. A couple things. Firstly, I think, as a small company, and as a senior engineer, you're going to have more impact. You're going to work on maybe not as difficult technical problems or problems with such scale as one of the giants, but you're certainly going to be working on things that your users, your customers will see every day. I think that's a really big sell for working in a small company that you end up being a bigger fish in a smaller pond to start with. That's a very good sign, I think. Another thing is when you're working for a smaller company, especially one like mine, is that you get to grow with the company and see all the complexities of that. That you're not in a company that has already reached this particular size and scale and complexity that you can grow as the company grows.
Gee: I don't know if this is so relevant in 2020, but offering remote work is a huge benefit, because if you are living in San Francisco, or cities like London and Dublin, they are expensive cities to live in, but not everyone wants to live there. Not everyone wants to live in that rat race. One of the reasons why I worked for MongoDB and for JetBrains is because they offered remote work, and I could relocate to Spain. I can live in the south of Spain where the weather's nice, where they have a family environment, and I can raise my kids here. My salary can go an awful lot further. They didn't have to pay me tech giant salary, but they pay me a nice salary that goes a lot further. That's one thing that you can do.
Joy: Another one for me, and I think it addresses another one of the questions we've got live as well, how do you keep senior engineers challenged? A great way of competing with the big boys is you make sure that as a senior, your only contribution is not assumed to be just cutting code faster than everybody else. You're contributing to the direction of the company. You're contributing to the direction of the proposition. We want your imagination to contribute to the product direction itself. Your purpose is eminently bigger than it would be at a larger organization. I think there are a lot of individuals that the brand names aside, that makes a bigger difference. What will it make to do my personal contribution? We all have an advantage in that conversation, I think.
Mendel: Just to maybe continue on a diversity and inclusion front. Resources aren't necessarily tied to the size of a company, but companies that are smaller, it might also be just easier to move your ship or to start out with a more inclusive environment that could just be a better place to work, and more welcoming, and flexible. That can be a big draw.
Nurturing and Encouraging Diversity and Inclusion through Hiring Practices
Hastie: Can I delve deeper into the diversity and inclusion? How do we, through our hiring practices, encourage and nurture diversity and inclusion?
Gee: This has been written about a lot. There's lots of different answers. I'm sure everyone else on this panel has loads of good answers. It is very hard. I worked for a bunch of companies where I was part of their recruitment process for Java developers. We fell into the same trap as a lot of other companies in the same problem. We just said, we have no women applying. We have no people of color applying. We can't even do any affirmative action, because we don't even have the applications. That's exactly part of the problem, isn't it? It is way back in your pipeline. It's about your job description. It is about the words you use. It's about the faces you have on the website. It's about the role models you look like you're providing. If you have people speaking at conferences, obviously, this is my thing, because I'm a developer advocate. I work for companies that did advocacy, but they're not advocacy companies. If those people are all white men, then it just subconsciously puts other types of people from applying to your company. Make sure you have diverse faces out there, diverse names. Diversity is not something you tack on to the end of everything else. It's something you have to put front and center if you really do care about it. That's how you start making changes.
Goble: The list is endless, of things that you can do to improve and nurture your diversity. Trisha has spoken of loads of them. I think another important one is to not necessarily rely on the pool of talent you might expect, so not necessarily to do all your recruitment from the same places from your Russell Group universities in the UK, or from the Ivy League universities, because those aren't where all of the engineers are, who come from diverse backgrounds.
I think a really important and effective part, and a time consuming thing to do is to spend a lot of time reaching out to people from those areas, so not expecting them to come to you. Because, generally, people who are from diverse backgrounds, once they're in a company that they feel safe in, they will stay there. It will take a lot to convince people to move to a different company. I think being able to reach out to people and play a long game of talking to them, and reassuring them that a move to your company would be a good one is really an important part.
Also, because people generally from diverse backgrounds have massive imposter syndrome, we all have it to a greater or lesser extent, but I think if you're from an underrepresented group, then you probably have it more than others. Being able to have conversations and reassure people that they should apply for your job is a really strong game changer in terms of increasing diversity.
Gee: I really want to follow up from that specifically. I think that from my experience as a woman in technology, I cannot speak to all underrepresented groups, but you basically go through two phases. One, imposter syndrome, "I couldn't possibly apply for that. I'm not good enough." In which case, you never apply to these things. Then when you suddenly are good enough and/or get the confidence to understand how good you are, once you start putting yourself out there, you no longer have to apply for anything because people are coming to you. I will not apply for a job from now on because people will come to me. I don't do CFPs for conferences anymore, because conferences reach out to me because they need women speakers. It becomes extremely difficult to attract people from those groups to apply. Because, firstly, they don't often because of imposter syndrome. Then they don't because they've already been poached. The people who are more proactive than your organization have already taken that action and made that happen for them.
Mendel: I thought I might share some hand data with the group here. Here, we've done over 70,000 technical interviews. We have a scientific process for writing questions and creating this environment for our interview engineers to succeed. Our interview engineers are practicing professional engineers who then conduct these interviews. We have a little bit of a consistent process to look at what's happening. A couple things I thought that could be helpful. One thing we've noticed is that about 40% of candidates who then go on to succeed in their own sites and get offers, 40% of them will receive some guidance from an interviewer during the interview. That's a very difficult thing to do during skill assessment interviews. It's very difficult to do that consistently and to get all interviewers on the same page about when is someone stuck versus is it signal or is it noise? Is this person just, maybe their personality quirk is very interactive? Am I giving them help? Are we just interacting? Am I encouraging them? Does this impact the assessment signal or not? Just trying to get everyone on the same page for whatever that ramp-up and impact means for you for a particular role. That can be difficult, but there is great benefit in that.
Also, we also get feedback from our candidates after an interview. We're in a position where, because we're not making hiring decisions, I think hopefully people feel like they can be honest with us, because we're not making a decision on you. It's a difficult user situation. Most of our users, most of our candidates are going to be unhappy. They're not going to get what they want from this process. How can we still have them be so happy that they're saying nice things on Glassdoor and Twitter, about the companies that they're working with, not just us? A lot of the nice things that people say is, "I really had a hard time in this interview. I probably bombed it. It was so nice to receive some help. I really enjoyed that." That is one way to also evaluate teamwork is to pair with someone during an interview.
The other piece of data I wanted to share, and this was very recent, literally, just like two days ago. This maybe doesn't impact senior engineers so much. In early career hiring, often in the U.S., which is my experience, the companies are going to specific schools like MIT, Stanford, and other ones like that. For the tech companies we work with that we're doing interviews for, we looked at the interview success rate of candidates coming from different sources, and these were for some high bar companies. In this particular case, it was quite outstanding to me. I would have expected, of course, the top universities will be at the top. They'll have the biggest signal to noise. We'll just see the tiering of the schools in the data. It was totally the reverse. MIT was way down. There was a couple dozen above it. I went to MIT, so I'm allowed to call it out. It was really cool to see that it was quite incredible that candidates from other schools, you would actually be more efficient to go and talk to them. That was very cool to see that.
Joy: I was going to say, just to concur with that. It took me far too long in my career before I realized, how so many good people don't even have computer science backgrounds, let alone from the redbrick universities, some of the best people I've known didn't even have that whole background. I think that did make a difference. Absolutely, will help diversity to bring that prospective employer.
Gee: I have some more quotes which back this up as well. Some of these are older. It just shows that our ability to recruit has not really changed over the last few decades. One was a quote from Google. This is from an article in New York Times in 2013. "On the hiring side, we found that brain teasers are a complete waste of time. They don't predict anything. They serve primarily to make the interviewer feel smart." Again, like trying to test people in the interview, there was no correlation between interview score and performance.
Way back in the '50s, "The scientific validity of aptitude testing was at best equivocal. In 1957, a paper concluded that in every case, the correlation between test scores and subsequent performance reviews was not significantly different from zero." Then there's another piece about how, "Most successful team includes an ex-farmer, a former tabulating machine operator, an ex-key punch operator, a girl who'd done secretarial work, a musician, and a graduate in mathematics. The last was considered the least competent." That's in 1968. Yes, diversity, the way that we've been measuring ability is impacting our ability to attract and retain diverse talent. In fact, talent full stop, actually.
How Interview Performance Correlates with Job Performance
Hastie: Leading on from that one, how does interview performance correlate with job performance?
Gee: It doesn't.
Hastie: What do we need to do? We made the point already that for senior people, we're looking for evidence of teamwork in the interview? What are some of the things we can tease out or that we can do to improve finding that teamwork evidence?
Gee: One of the things we did in one of my last companies, which had quite a traditional interviewing process, whereby you submit your CVs. You have a technical phone screen, and you have a whiteboard exercise. We found that the best way to predict whether someone was going to be good at the job was to literally sit and pair with them in the job. Because that's what we did, we pair programmed every day anyway. It was done that we're doing this interview process where you don't see someone's code, you don't pair with them. Pairing is a great way of checking whether someone can do it anyway. A, it checks their communication skills. Are they talking to you? Are they asking questions? Are they telling you what's going on in their head? B, you get to see them write code. Do they know the code? Do they know how to write code? Obviously, this comes from the biased point of view of I now work for JetBrains because I got so good using IntelliJ IDEA that they poached me to come and work for JetBrains. Do they know how to use the IDE? Do they know how to debug? Do they write their tests first? You don't get these things by doing a whiteboard interview. You do get this by sitting down with someone and pairing with them like you would in the normal everyday job.
Mendel: Trisha, since you were poached, I was trying to remember, what is the word for when people get stolen? That is one thing we don't think about when trying to recruit at the senior level in terms of diversity and inclusion, is that, actively go and steal women and people of color, apply that poaching. I was talking with an engineering VP one time and he admitted to me. He was like, I have this blind spot. It's like a weird protectering of women. He's like, "Let them decide. Just go ask, put the resources there. If you have referral bonuses, consider giving different referral bonuses for different competencies and experiences that you find valuable." The same way if you're trying to hire 10 engineers, it would be really great if there was a React expert. That would just be really nice, that not every one of them has to be a React expert. If we hire 10 people, and we don't get that, what a missed opportunity? That can be extended in a lot of different ways. That maybe is one way to approach thinking about the recruiting and hiring of senior engineers, and not thinking of it in terms of affirmative action or anything like that.
How to Come up With Relevant and Transparent Job Descriptions
Hastie: What about job descriptions? Job descriptions, and seniority levels, are questions that are also ambiguous? How do we come up with relevant job descriptions? How do we make them really transparent or visible?
Joy: It's a wicked problem. There's no two ways about it, whichever leveling you adopt, there are going to be challenges with it. Some of the effective approaches I've seen relate to, what's the blast radius of individuals? How much authority, if you like, or ownership does the individual carry? Can we grade that, so that, at the ultimate level, you're responsible for the entirety of the whole platform we're building? We got ownership. Can we build in levels tied to that, supervision, so at the very junior level, who needs a lot of supervision, at a very senior level, not so much?
I think there's a parallel with the other question that's been asked about, what about where there aren't high positions like architects or team leads? If you're making sure that the practice itself has real purpose, again, so phases of improvement, as an engineer, I can be given increasing levels of responsibility. You don't need these badges, because there's always a challenge in front. As long as there are increasing levels of challenge, as long as the organization sponsors, as an engineer, there's no reason why you can't be given the ultimate grading if you like. You shouldn't need the badge that means you're a man manager, or a project manager, or you're taking that other route. As an engineer, you should be able to pursue the practice. It's about, what's the benefit you bring? What's the outcome you bring to the organization, by your level of engineering, or the level of enablement you bring to the team? I think those are related.
Goble: I don't think I've ever seen a job description that's been anywhere near useful. I don't think I've ever applied for a job that's got a job description that's anything like the job that it was ever going to be. They're just useless, aren't they, really? I think it is circling back to the thing that Lusen said right at the beginning was about great frameworks. I think, Trisha as well. If you're looking for the competencies of a person, and you have your growth framework, just share your growth framework, and then get people to apply on the basis of that. You have a much more realistic idea of the sorts of things that you're doing, scope and impact you will have at a particular level. Then find out about the company, and then you will know. Then you'll have a map, what are the competencies that we expect? What does the company do? Surely, everybody can make a decision about what a job is going to be based on those two things. Everybody should have their growth frameworks out in the open for all to see.
Then have conversations. That's another thing, through the interview process. You've looked at their growth framework online, you think it looks great. They've got one, that's a bonus. You've looked at the company, you think the company sounds interesting. You've maybe had a conversation with the recruiter about what they do, and what the challenges are. Then grill a team as you're going through the interview process. Ask them about their challenges and what they face day-to-day. Don't think that that bit at the end, where the interviewer says, have you got any questions for us? Is just a 5-minute rubber stamp really. Grill people about what the company is like and what sorts of things they do, and the challenges they have. Then by the end of that process, then you'll have enough information, hopefully, to make a decision about whether you're the right fit for them, and they're the right fit for you.
Gee: One of the reasons why my previous company got into doing developer advocacy was not around doing technical advocacy, as in, this is how you use our platform and this is how you use our open source stuff. It was literally a recruitment exercise. By doing a developer advocacy type stuff in terms of having the developer speak at conferences about some of the interesting technical problems they solved, having an aggregate of the individual developer blogs so that, A, you can see that individual developers are encouraged to blog. You can see what people are working on. You can see what the tone of the individuals is. That works really well for ThoughtWorks as well, who I briefly worked for too. That kind of thing, blogging, conferences, even Twitter to some extent, all of those things are giving insight on what you're saying. You don't have to wait for someone to get to an interview to ask the questions of the team. If you've got a culture that you're genuinely proud of, that you've built on purpose, publish that culture. Make it accessible to people, so people can go, "This has got some cool people working in it." Particularly if you do have a team, which actually has some diversity of some kind. You can showcase those voices, "We are inclusive. We really do mean what we say on our mission statement."
Mendel: I love that because we live in such an authenticity is everything world. Forget marketing, have your developers be directly there in the public. Sally, I want to build on what you said, because I wrote down in my notes, I was like, should job descriptions for hiring be the same as job descriptions for promotions and internally for performance reviews? I think that's pretty awesome, if they exist. Or, it's a good time to get started doing that when you're about to bring people into your community and want to create a nice, safe, and healthy relationship with them.
The one nuance I would add onto this is that job descriptions that are external, they are invitations. This is not the time to filter people out, because self-selection is a decision you don't get to make and that sucks. We want to make all the decisions. I want everyone to apply. We've got really great processes to make decisions that are going to be the right decisions for us. Don't let the decisions get taken away from you and placed onto candidates. If job descriptions or invitations, that means you want them to be welcoming. I think sometimes having more kinds of invitations and more specificity can be really helpful, because people like to be invited to things in different ways. When we work with companies, or when I work with companies, I see a single JD, a single job description, and I'm like, "Early career engineers think they shouldn't apply. This looks really ambitious." Then the senior engineers were like, "This isn't that challenging, break it apart." I think you can brand these invitations in other ways too, to really speak to people who are in different parts of their career looking for different things.
Hiring Senior Developers When the Existing Developer Teams Are at a Junior Level
Hastie: How do you hire a senior dev, when our existing dev teams are at a junior level? They're not qualified to evaluate somebody. How does this hypothetical team make the decisions?
Gee: That's perfect, because your senior dev is supposed to be leading your junior devs. The junior devs are absolutely the right people to decide whether this is the right person to learn off, because that's what their job is. Their job is supposed to be leading these people. Maybe not leading as in managing, but they're supposed to be there to provide inspiration and aspiration, and stuff like that. When I worked at this other company I was talking about, we had to hire a CTO while I was there. They got all the development team to interview the CTO, because he's going to be our boss. Especially, as the only woman on the team, I want to be able to say, "No, you can't hire this person." It's really important to have the juniors interview and give their perspective on the senior person.
Mendel: I love this. Absolutely, turn those tables around. Worker led cooperative. Also, sometimes it can be helpful. It depends on the situation you're in. At Karat we sometimes work with companies that are still developing those competencies, like the technical competencies. I am technically on the marketing team as a dev role. I'm not usually in this position, I'm not trying to sell anything here. I do give workshops, for example, on interview best practices. I think that sometimes companies come to Karat to get started and to figure out some of that.
What I'm trying to say is that, sometimes in tech companies I find managers, it's like, the blind leading the blind. That can be a painful experience for everyone. Try to find experts when that makes sense to fill in gaps, not as a replacement for your team being involved in hiring managers, but just in addition. I also think that's a super interesting question. If I may go into engineering speak here, an NP, a non-polynomial time problem is really hard. To come up with that solution is like, why we have security. If I give you a solution to an NP hard problem and ask you to verify if it is a true solution, you can do that in polynomial time. It's an easy check.
This is my hypothesis of, can a junior engineer assess a senior level talent? To be senior is NP hard. It's very difficult to go and create these architectures or solve these problems, or lead this team and be this enabler. Can someone else who's set up to succeed verify that that exists? That's my hypothesis. I think that can happen, given the right framework to succeed.
Should Senior Developers be hired from Outside or Grown from Within?
Hastie: Building possibly on this one as well, hire from outside or grow from within to create these senior developers? For that hypothetical organization with largely juniors, would it be better for them to grow from within or maybe go and look outside?
Joy: I'm a strong believer in where you can grow from within. There's always pressure on time. There's always pressure on productivity. Given the other challenges we've already highlighted about, how do you keep people engaged? How do you prevent turnover? How do you keep it challenging? That's all right in that domain. That should be part of the story. You can join as a junior. You can be a senior with an X amount of time. We sponsor that development, bearing in mind the building domain knowledge is priceless. Always holding on to that, as long as you can, and the stretch of, genuinely, what it takes to help individuals succeed. I think it can be a lazy response to always be pulling outside to get the seniors, always headhunting the seniors. Pull as many as you can through. It all builds team strength, overall.
Gee: I agree with that. I feel like getting outside talent seems logical. Of course, you want to hire the right person with the right skills and bring them into this role. We don't have that right now. It's going to cost us time, effort, and money to invest in our more junior people to grow them, so let's just get the right person right now. It's very tempting. The reality is, in my experience in industry, that person who looks great on paper goes through the interview process, they've got their portfolio, or whatever. You still don't know them. There's still a gap. When you get them on board, there will be a gap, whether it's a domain gap, whether it's because you didn't properly evaluate their skills, whether it's because they're not great team fit, or just because it takes that long to get people up to speed. That person who seems like a shrink wrap fit for that role is not and will never be. It's almost always not as efficient as you think to hire from outside. There's always a much greater cost than you think.
Goble: I think I'm just going to be equivocal and really boring and just say, both. You can't do one or the other. Apart from anything, if you want to encourage a more diverse team, just having people, it's not just diversity of individuals, but it's diversity of thought. If you're going to only grow your own team from internal, then you won't have an external perspective, which can sometimes be an interesting one to have. I think you've got to have both. I think, Trisha, you're right. You can't just have a magic wand and get somebody externally who's going to be better, but you can't only be bringing up your internal talent and growing them as well. Especially, not if you start off with an un-diverse group to start with.
Mendel: This isn't a super detailed story, but you reminded me, Sally. Sometimes I think about how, just as a manager myself in the past, sometimes you believe in someone and you open the door, and they rise to the challenge. You're like, "Of course, this wasn't going to be a big deal. Of course, we have these growth paths." You have to remind yourself, why was I surprised? Then other times, I've definitely hired people, or in this case, promoted people, or change responsibilities, and realize, "I set them up to fail. That was a gap that was way too big. I made some assumptions." It's interesting. It's like, I've been working with this person for years. Maybe this tends to happen more so under a year, but still, a long time compared to an interview process, and really trying to narrow in on that signal. I don't have any answers here. It's a difficult problem. I do wonder these days how to apply the structures and the learnings that I've been having at Karat with the interview process. How does that apply to a performance review or a promotion? I'm sure there's some overlap in an interesting way.
Hiring the right Talent, Remotely
Hastie: There is a question that's in our question backlog about recruiting for remote locations. Trisha, you mentioned earlier on, your experience of being remote for quite a long time. For many organizations, and many people, this year has thrown them into this remote environment and perhaps not as well prepared or not used to it even now. How do we build that rapport that will enable us to actually get to know, is this the right person, when we are facing each other through a screen?
Goble: I'd like to answer this because I've just been through this process myself. I got made redundant in May. I went through a whole raft of interviews. Actually, I thought it was amazing. I loved it. I loved remote interviewing. I found it much less stressful than going into an office. One minute I was making a cup of tea in my kitchen, the next minute I was sitting down ready to be interviewed. For me, who's got to see really early for everything, the anxiety of making time in my schedule to get across town, to arrive at an interview place half an hour early, have the nerves going to do the interview. That all disappeared. I found it hugely beneficial. I felt like I was on my own terms, as well, I was in my own environment. I felt like I had one up on everybody else, actually, by being in the comfort of my own home.
Also, another thing is when you're interviewing with several people, they're not together either, they're all in their own individual boxes. You feel it's a three-way conversation rather than two against one. I thought that was super useful. If you have your rubric, you have your plan of your interview, you know how to accept it at the end. It doesn't really matter if you're in person, or you're remote. Also, candidates don't have to take as much time out of their day to go through an interview. That's a bonus for candidates. The one difficult thing is, if you're trying to sell your company, you can't take them into your work environment. You can't show them your lovely office or your roof garden. They can't see the way people are working, can't get the vibe of the office. As an employee, you just have to find ways around that.
Gee: I've been on the other side of it. We've been hiring people. I've been at JetBrains for 6 years. This year was the first time I was actually hiring someone for my team. Although I've been remote for 7 or 8 years, it's the first time I've done remote hiring. Our team has always been remote. We've always hired remote. It's got nothing to do with this year. It just happens to coincide with this year. I do find it challenging, because in the past, I did phone screens, technical phone screens and whiteboard face-to-face stuff. I was hiring developers. This time, I'm doing a remote interview, and I'm hiring a developer advocate, which is a different skill set. There's overlapping skills, but it's different.
I agree with a lot of what Sally said. It's nice because even as an interviewer, I don't have to go, "I've just got to drop everything and go into a different office." I know I'm lowering the barrier to entry to the people who are being interviewed. I know they're more comfortable. Like you said, they're at home in their desk with their coffee. They've sorted themselves out. They haven't had a stressful Tube journey. They're probably not going to be late. It's more relaxed. It is a different skill. It's perhaps a little bit easier for someone like me who's been working remote for a long time to make that person feel at ease and to get that rapport face-to-face. I honestly thought it was much more relaxed than being in an office, sat across the table from each other, firing questions at them.
The thing that I've been trying to do with my interview technique over the years is I no longer want to ask questions and get the right answers. I want to ask a whole bunch of questions, start a whole bunch of conversations, to trigger the stuff that you're good at, not to find out what you're good at, but to trigger your moment of, "I've got this cool thing I want to talk about." I just found that a little bit easier remotely because you're not in that super stressful situation. It is caveated with the fact that I'm hiring developer advocates who are generally a little bit better at the interpersonal talking stuff anyway. I don't know how relevant that is. It is different. It does involve a certain amount of change and learning, but I think it's overall a much better thing and you're lowering the barrier to entry for people to interview for your company.
Advice for Interviewees
Hastie: I'd ask each of you, some advice for interviewees.
Goble: I've got two bits I'll start off with. First of all, I would say, remember that quite often the interviewers are as anxious as the interviewees. Most people find interviewing super stressful, most interviewers, not just interviewees. Most interviewers find it really stressful and hard work and get anxious about it, find it difficult. Lots of engineers who are doing interviews find that really challenging as well. If you're feeling nervous, remember that they're also feeling nervous and that might make you feel better, is my first one.
My second bit of advice was practice interviewing. Don't wait until you want another job to start interviewing, because you'll probably be several years rusty of doing it. Maybe I shouldn't seem to say this is somebody who runs a team, go out and practice interviewing before you will need to do it for real. Another piece of advice that somebody gave me when I was interviewing is, don't make the job that you really want the first interview that you do, which is the same thing. Interview for about three or four jobs that you don't really want before you interview for the one that you do want.
Gee: I back up all of that advice, particularly the practice one. I've written about this before. Interviewing is a skill. The skill of interviewing is not the same as the skill of doing your job. You have to practice the skill of interviewing to get better at it. That's just the reality of the situation right now. I have had a number of friends and colleagues, when they're vaguely interested in maybe looking for other jobs or something comes their way, and they're making a decision as to whether or not they should go to this interview. I'm completely on board with just go. It's just practice. If you don't care, that's the best time to be practicing. Actually, you might find something interesting anyway.
My advice, as well as that, is, you are interviewing the company. People told me this when I was a junior and I was like, "I don't really care. I need a job." Certainly, as a senior, you are absolutely interviewing that company. That bit where they ask you any other questions at the end, which I'm always really bad at, that is absolutely your opportunity to say, things like, how many people did you promote last year from junior to senior? If that's what interests you. Can I go out for a drink with the team and get to meet them? What do you do when the build fails? All that kind of thing. It's not about right or wrong answers, it's dating. Does this company fit me? If it doesn't, that's fine. Doesn't mean you're a bad person or the company is a bad company. It's just not a fit. There's plenty out there. Just keep going. Keep practicing until you find that fit.
Which reminds me on my third piece, which is, be yourself. I know it's hard. It's particularly hard for underrepresented groups, particularly when we have imposter syndrome. If you're going to find a company that you want to fit with, you have to be yourself in that interview so that you can figure out if they're going to say something weird to you straight away for being a woman or whatever, you can just strike them off the list immediately. If they're going to be welcoming and if it's a comfortable place, if you spark with them, because you will yourself, that's great. That's a really good piece of data. Be yourself and absolutely interview them.
Joy: Yes, to abundantly agree with all of that there. Some great advice. A bit of advice I was given along similar lines was under-maintain your plan. Assume the rehearsal. Practice on getting it right. Keep your plan moving, give yourself something like a 90-day cycle. How am I better at this? Especially, as a senior. Great advice, though, from Trisha, bear in mind what you're bringing to the conversation. It's as much for the company to entice you as it is for you to win, if you like. Yes, great advice.
Mendel: I think I'll add that one of the things that I believe is a disproportionate lever on hiring decisions, perhaps that I see from hiring manager feedback, is, the candidate was too quiet, or the candidate was too rambly. Interviews are conversations. It's why practice is really helpful, even if it's not real. Talk to a friend or your dog. The communication does really play a strong role in how hiring managers make decisions. Even though it can be a stressful situation, and maybe I could be quite rambly, but I think I'm still a good employee. As hiring managers and interviewers, let's rethink our competencies and make sure it's signal not noise. That aside, for candidates, communication is where it's at. I think that my biggest advice on that front is be positive.
For problem solving interviews, ask questions up front. Engage. Have that conversation. The worst thing you can do is write the code or explain the solution in the first 5 minutes. Have that conversation up front. Have the conversation at the end, the bit about asking questions. Be strategic. I don't think that's the time to ask every question you want, wait until you get the offer. Then you can bring up other things. Never make a decision or force a negative decision until you have the best offer you could hope to have. If negotiation is a part of it, then you get to make a decision if that happens. Maybe be strategic, be positive. Sometimes that means we get to bring our authentic selves and have certain boundaries. Sometimes that means being strategic in a different way. Focus on the communication, instead of just conversations.
Gee: One of the companies I used to interview people for, we used to always sit in pairs. A lot of people I paired with, they would literally ask questions until a candidate said, I don't know. The reason being, not to make the candidate feel stupid, but to see, will they say, "I don't know." Because it's perfectly fine in an interview to say, "I don't know the answer to that question." Many of the jobs I've taken were because during the interview, I said I don't know. Then the interviewers coached me through it. I was like, "I want to work here." Don't be afraid to say I don't know.
Hastie: That's good advice for life in general.
See more presentations with transcripts
