Engineering interview tips & tricks

Hello, and welcome to Go time. Today we’re going to be talking about engineering interviews. We’re going to be talking about tips, tricks, gotchas, as well as some potential interviewing horror stories, positive stories, red flags, things to avoid, as well as hopefully some green flags - what should you do to really ensure that you’re successful in your software engineering interview.

I have the absolute pleasure, as always, of being joined by my wonderful, beautiful, intelligent, bafflingly beautiful Natalie as my co-host.

Hi, hi.

Hello.

It gives me joy every time I see you with me.

I’m very happy to see you every time as well, Angelica.

I never get sick of it. And aside from Natalie, we have two other wonderful women; we have the lovely Emma Draper, whose pronouns are she/her, and she is an engineering manager at the New York Times, based in Arizona. Hi, Emma. How are you?

Hi. I’m doing very well.

How are you doing? Good day, excited? First time on Go Time…

First time. I’m very excited to be here. Thanks for having me.

Always a pleasure. And then we also have Jonas, who is a technical enablement manager at Datadog, and who is based in Denver. How are you today, Jonas?

I am great. Happy to be here with you all. Thank you, Angelica.

And what is a technical enablement manager?

So primarily, I focus with customers on how to be more effective and successful with Datadog through trainings, workshops, both public stuff, custom stuff… Teaching, enabling, as the name implies. [laughs]

We’re very excited to have you on as well. Not the first time, but you haven’t been on in a hot second… So great to have you back. So we’re gonna dive right in. So how do you interview as a software engineer? What are the different interview stages? How do you do it? Jonas?

[04:08] Sure, yeah. So most interviews follow this typical format; I think every company can be a little different, so you’ll want to always check with that company, but I think the flow tends to be you will have generally some sort of recruiter screen to start. And that’s either if you applied, or maybe a recruiter reaches out to you… That’s a really basic quick chat usually, more about the role expectations. From there, it’ll depend… Some companies will do a technical screen; that may be with a person, it may be through a program, or a take-home, or something… Or you might have a hiring manager screen; you might have both of those.

And then from there, you usually go into what’s considered like a panel, or like on-site, although we’re in a virtual world, so obviously, that has a different meaning… But from there, you usually have a chunk of interviews that focus on technical capabilities, as well as usually some team collaboration/communication skill set. And there’s usually – so there’s like a date at each one of those. And then once you’ve done the whole panel set, usually that’s it. But again, every place can be a little different. But in my experience, that’s the general format for most engineering interviews.

And are all of the interviews run by fellow engineers? Who typically does the interviews for software engineers?

Yeah, I think once you get particularly to the technical screens and the on-sites, you will generally be with engineers. Sometimes you will also - depending on the teams, you might be meeting with product managers, designers, other people that you would be working with on the team, particularly around things like assessing your teamwork and collaboration; they want to assess, like, can you work with all the other people you might be working with in your function… And then sometimes you’ll also potentially meet with other leaders in the company, usually technical leaders, like a VP of engineering, or a director, or a CTO, even if it’s like a smaller company… But I think the majority will be engineering, for like a more tech company. Again, if you’re interviewing somewhere where maybe they don’t have a lot of engineers, that could be different. But if you’re at a real tech-focused company, that’s the case.

And then I know that you have a combination of both technical in terms of “Code this thing. Talk to me about system design”, but you also have, I guess, technical in the sense of leadership, technical strategy, especially if you’re interviewing for a management role etc. I’d love to hear a little bit, Emma, from you, about how you go about assessing for those kinds of qualities; more like culture, fit leadership qualities etc.

Yeah, I think it highly depends on the role that you’re interviewing for. I think at different levels of engineering you have different impact that’s measured. And how that can be measured could be what is the impact and the scope in which I’m being involved, and bringing the team along on my immediate squad, but also what does that look like for partner squads if you’re in a staff or a senior engineering role… And then at a principal level, and even at some levels of staff, it really does amount to “How am I impacting the tech community at large, and what engagement am I having? How am I contributing to things like open source repositories, or something like the Go Time podcast?” Like, what is my contributions to elevating and working with those in the tech community at large? Does that answer your question?

It does. It does. So I know you touched on this, Jonas, that it’s semi-different at every company… I’d love to hear from your experiences what parts are fixed, and where is there room for you to curate the process for your specific team, the specific role that that person is interviewing for.

[07:50] As the one who’s hiring, as a hiring manager, again, I hate to say “It depends”, but what I have experienced is that at maybe a more enterprise, a mature company, you will probably be following a very standard system much more. And that’s because at this point the company has built this system over time, they’ve tested it, they know it works… And so for the most part, you will follow that. There may be certain ways you can customize based on if you need a certain specialty or type of role, like if you’re really focused in distributed systems, or in security, and so then you might have like a specific technical screen, or part of the technical that’ll be really specific. But then outside of that, you’re still within this very structured framework.

Now, I’ve hired at much smaller companies, where it was just “Go hire people. Good luck.” And then you’re pretty much creating the whole thing yourself. So I think it can be – definitely, that’s a difference, I think, in terms of size of company and maturity of company, is how structured you’re going to be as a hiring manager, versus just on your own.

Okay. But when someone’s thinking about interviewing as a software engineer, they can overall expect to have some system design, some kind of leadership and strategy, some kind of cross-functional collaboration… So cross-functional, we mean like with a product manager, project design, depending on the company, depending on the team… A kind of practical coding, which perhaps would be what most are familiar with, i.e. like “Code this thing, solve this problem, code review this thing while we watch and we see how you think through this problem…” Debugging, as well as sometimes, again, dependent on the company you are interviewing for, some algorithm database interview. Is that high-level what people should expect? Or is there anything else that I may have missed? If listeners are saying, “Oh, what are the different interviews I should be thinking through?”

I guess I would say from my perspective it matters what company are you interviewing for, what role are you aspiring to be hired at, and then what is the composition of the team currently? And that will help structure what those interviews look like. So the roles and expectations will craft what types of interviews you’re going to see, the composition will indicate what the team’s composition, which - you can ask that in the recruiting screen or the hiring manager screen, is “What does the team dynamic look like, and who are the members of the team?” I think it will help provide insight into who you’ll be interviewing with. And then I think what the company’s mission is, and what problems they’re solving for will likely be key indicators of the types of questions that you’re gonna see in the interview process.

Yeah, I would just echo… I think everything you touched on is right, Angelica, in that if you just know you’re going to be interviewing, that’s a good way to start studying and preparing.. But then very much to Emma’s point - talk to the recruiter, talk to the hiring manager, because everyone will be potentially a little different, and so don’t be afraid to ask, “What is it? What’s your process?” and get as much info as you can, so that you can actually be really specific for that role and be really ready for it.

I really agree with you, and I think that also, even sometimes I read that as part of the job description, and that’s a great thing to include there… So that you know how much effort you’re going to have to put into that. You both agreed on what the steps are that are the same everywhere… What are your thoughts of automating one of the steps? For example, I can already see some companies using tools like LeetCode, and so on.

Yeah, I’ve had mixed feedback on the different tools. If you’re considering them, definitely do research on it. I know I’ve used some that seemed kind of helpful, and some that have been dropped, because you just don’t get very good signal from them… In a perfect world, I would like to never use them, or have to use them, because ultimately, I think you get the best signal from being in front of a person and having stuff specific to what you’re trying to hire. I do understand their place… If you are really rapidly trying to scale and hire a lot of people, and you don’t have a lot of existing engineers that can spend their entire time interviewing, so I can see the place for it… But ultimately, I think it’s not the best tool, and I think particularly if you’re trying to hire more senior and experienced people, you’re never going to get the signal from that. You might even turn away candidates with stuff like that… So use it wisely, sparingly, know what it’s good for and what it’s not… Have you used them much, Emma?

[12:07] I haven’t. I don’t have a lot of exposure to – I mean, in terms of how you can automate the hiring process, I’ve used a centralized ATS, which I think is really helpful, like Greenhouse. So what candidates are applying… You can then move them through, which I think is great… But in terms of how you administer interviews and using automation there, I don’t have a lot of experience. And I am not opposed, but I do think that I would proceed with caution to what Jonas mentioned, for the main reason of - it’s really important to the culture of the team and how that’s set from a micro-culture perspective of the roles that you’re hiring for that the team gets a lot of exposure. And we’re talking about six interviews total, where you get 40 minutes to get a gauge of if that individual is going to be a great add to the team. So minimizing that and reducing it by any amount is like – um, I don’t know if it’s worth the steps it might remove, I guess…

So you both agree that this is not – like, use with caution is the thing that you would both say? And is this your answer for automating any of the steps? Or are you in particular opposed to automating the first interview, or the technical? Or is there one that makes more sense or less sense to automate?

Yeah, I’ve only seen these used in the very first step. And that’s the only place I would. And again, it’s because you’re really just trying to – if you get a ton of applicants and have a limited pool of people that can actually do that initial screen, then it can be a helpful tool just to help quick-filter basic coding ability, and that’s where I think it can be effective, just to help that process. But yeah, I think to Emma’s point, after that you have relatively such little time to actually assess the person and get a sense for it… And if you’re starting to automate those later stages, I don’t think you’re gonna get to a signal; you’re probably not creating a good candidate experience either… So I don’t see you getting a lot of benefit on either side.

I also can think of it – again, I haven’t interviewed and it be automated, I haven’t gone through that process, but I almost would say it’s like when you call and the service is just putting you through these prompts, and you’re like “I just want to speak to a person…” From an interviewee perspective, it really is nice to meet with people who have been at the company, who can speak to what the culture is like today, what challenges and areas for improvement they’ve identified… You don’t get those from a system that’s prompting you with questions, so I think I’d be like “Zero! How do I get to a person?!” [laughs]

I’ve had that… I’ve had really terrible experiences with automated interviews. Not in the software engineering space, but in my prior life in Academia. I had a whole interview that was an hour and a half long, and it was just a robot asking me a question and then getting me to record a video of me… And they were like deep questions, they were like “What does diversity mean to you?” And they were like, “Okay, ready to record?” And then one of them would start the interview, it would auto-start the recording, and you have 30 seconds to give your answer. And if you stuttered, it was like “Next question…” So I would plus-one that.

So we’ve talked through the high-level at different stages, but I’d love to hear a little bit about the difference of interview process depending on the level, i.e. if someone coming in as associate, a staff, a mid-level, a senior - what are the key differences at each level?

I’ve seen different ways that’s approached. At some companies the interview process is still very much the same, but the rubrics, and they cater the questions a bit different for leveling. So that’s one way I’ve seen it done. Others, there is an actual different inner flow, where you might have maybe a bit less for like an associate, because you don’t want to put them through a system design maybe, because they haven’t done a lot of system design probably… Whereas, maybe if you’re interviewing staff and principal, you would do that; you might do an additional one, that’s where you might have them actually meet with someone like a VP, because you want to really assess their strategic thinking… Whereas with the other way I’ve seen it is you kind of use the same format, just the questions are catered a little differently for the level, and then you have a rubric… So those are the two different ways I’ve seen it done. Is it similar for you, Emma, or anything else?

[16:19] No, I think you touched on the main key things that I’ve seen, which is it’ll likely be a reduced and shortened process for junior engineers or associate-level engineers… So you’ll just have, again, perhaps the same interview structure, but there will be interviews that you’re not going to see, like system design, and maybe you’ll lean heavier on the code review and debugging, so that there’s a key indicator of what collaboration with the individual and mentorship opportunities would look like.

And then I think the other primary thing that I’ll just echo is evaluation criteria I think is really important. So how you’re evaluating that individual is going to be different, and the things that you’re looking for at a staff level or a principal level, going back to impact, is going to be different from what my expectations as a hiring manager are for an associate or software engineer. So those are great additives, but I wouldn’t expect an associate-level engineer coming out of college to say, “Oh, I’m in all of these women in tech groups, and I host Go Time.” Like, that’s amazing, but that wouldn’t be my expectation; like, you just went through school, right? So…

So do you feel like it would be a fair statement - slash I’m looking for a reaction from you here - to say that you can give a little bit more leeway to hire someone and they can learn on the job when they’re more junior, but maybe you have less of a tolerance for like knowledge gaps as we get higher up i.e. a senior software engineer? …you might maybe not give them as much leeway to learn on the job, and more lean upon them demonstrating having worked in a system, having done something at a prior job. I would love to get just a reaction, a thought around that.

I look for ability to learn, and that self-starter initiative in any level. I think that that just speaks highly of what type of learner the engineers are… And that when they get on the job, they’re gonna face – even if they have tons of experience, there’s gonna be a whole new problem set that they likely haven’t faced before, so I definitely want to see how they deal with ambiguity at any level. And I think that it’s more about, in my mind, hire staff and senior-level engineers - I think it’s more about what kind of experience you’re bringing to the table. So how you’ve dealt with systems at scale, right? That is not something likely junior-level engineers have exposure to, and so I’m looking for you to be a resource for the team to be able to lean on and learn from… So I think that that’s probably the main difference. But Jonas, I’m definitely curious what your experience is.

Yeah, I would agree that – yeah, ability to learn I think is pretty important in any role, because of the nature of tech… But yeah, really as you start to go more senior, it’s where that ability to really lead and provide that expertise from experience to lead and guide a team - that becomes really important. And it’s really where I think the depth of knowledge starts to become more important; like, you should have gained a lot more depth in that area, depending on the role, and that’s what I would tend to be expecting more. And then add ability to really speak to different trade-offs, and still be able to admit that you don’t know everything… I mean, obviously, we’re always like – even at the most seniors, like you know that, but like, you’re able to really understand where your limits are even, and speak to that, but then also show a lot of depth in other areas. I think that can show a lot of maturity and that’s really great.

Definitely. I very agree with you both also that you should probably not apply to a job where you mean 100% of requirements or you’ll just be bored.

Yeah.

So it makes a lot of sense, what you all say…

What are your thoughts on interviewing at a startup, versus at the corporate?

I’m curious – I have not worked at a ton of startups. I have worked for very small organizations, and so I will say, you might be interviewing with very few technical people, because they may not have a lot. I interviewed where I was the first technical person. That was a weird interview, because no one knew how to assess me… [laughs]

“How do you self-evaluate yourself? On a scale of 1 to 10…”

It’s like grading… It’s like, “How well did I do on this exam?” [laughter]

“I was great!” So my sense is probably startups, you may have some of that; it’s probably not always gonna be a structure, because it’s a small company and you might be one of the first engineers getting hired; you’ll probably interview with like the CTO, or the CEO, which in an enterprise if you’re interviewing with the CTO, you’re either really high up, or like something’s broken in their process, and that’s probably a concern. But I don’t know, have you had more startup experience, Emma?

So I worked at a small startup, and that interview process, when I was going through it I did interview with the CEO. So speaking of just when you have really small organizations - the pool of people able to conduct an interview is much smaller. And that interview was intense. I mean, I think it was 20 minutes, and it was just rapid-fire, whatever questions kind of popcorned up, I was expected to answer, and to be really – I think that’s where brief and concise answers… It’s a good muscle to exercise, like, how are you able to answer the question pointfully, without rambling. So I think at a startup, that was more – I think it’s applied at any level of interviewing, but I definitely noticed it when I was on a call with the CEO, and just… What you say matters. Their time is really limited, and so you don’t wanna mess it up.

[24:01] And then as people are thinking through how much time it’s going to take to interview - how long does a typical interview process take? If you’re working at your current job, and you’re saying, “Oh, I kind of want to find myself a new job…” what are the expectations around the length of that process before you may or may not (hopefully you will) get that job offer?

I think that there’s a difference between how long the job search takes, and then the interview process. So I would delineate between those two things. If you think that you’ve hit a ceiling at your existing company or in your existing role and you want to start exploring, I would give yourself a lot of time to find that right fit, right? Because there’s this really unique balance of finding people that you’re inspired by, as well as the mission that you’re aligned with… And that doesn’t happen overnight. And oftentimes, it’s applying to a lot of companies and hearing back from a really small margin and fraction of those. And then, in my experience, once the interview process has kicked off, it can take anywhere from - at the small startups it was a week, or a week and a half, two weeks; it was really accelerated… Versus at The New York Times when conversations started, and it probably took in total four months, or five months. So it’s just about what that role’s opening is, and what their timeline looks as a company to fill that position.

Yeah, I think that’s right. It can definitely range on the type of company and what their goals are for the hiring, and their process. I mean, I think in terms of the overall time you spend interviewing, I think it’s about six to eight hours of actual interviews; that feels about the norm. But yeah, there can definitely be gaps, like between where those different gates are… And because – and especially at an enterprise New York Times or something there might be, “We need to do so many candidates before we can move to another gate.” Like, some of those checks and balances that are just not even in your control. I think sometimes as a candidate you can feel like “Oh, no…!” but having then been on the other side, it’s also like some of it is just there are certain processes in place, and they have to go through the wait sometimes between your final interview and an offer… There can be so much happening in the background sometimes. So that’s just something to consider, especially I think at larger organizations; startups, or smaller, they can move a little faster. So yeah, I think be ready for that; sometimes it might take longer than you hope.

Yeah. And I would say lean on your recruiter, or the hiring team that has brought you on, and just ask. I was really lucky to have an over-communicative recruiter, that was just telling me “Nothing’s gonna happen for about a month. Don’t have anything for you, again.” That’s also fine. But I think it’s nice to know where you’re at, and that the company is still thinking of you and considering you, right? So I would just say you can ask. Ask questions.

Yeah. Plus one on that. Make your recruiter your friend. Talk to them all the time.

So in Germany, where I am based, the average developer has a three months’ notice in the contract, and the average manager would have even – well, not average manager, but many managers would have six months of a notice. So I wonder if the answer would be different if it’s here… It would be interesting to run – maybe we can make this into an unpopular opinion so it will be a poll, or something… I can imagine if this is like a four-month interview, and then another six months of waiting… It’s like, you’re gonna get somebody next year. So I would expect them to be faster, but my experience is mostly with startups, so it’s always fast. But it is interesting…

Yeah.

So zooming in on that duration of the process… How long should a coding assignment take if you do it at home, versus if you do it on-site, on Zoom, or whatever the equivalent is? Please don’t say eight hours. [laughs]

No, I was gonna say – I mean, I think there’s like what happens in reality versus my advice… I prefer to keep them roughly the same. I’ve definitely seen some where it’s like this take-home exercise “Yeah, it’s been four hours”, and that’s kind of absurd to me, because you’re interviewing at a ton of places, and you would never ask someone to sit in an office for four hours… I mean, hopefully you wouldn’t; maybe someone would. But I just don’t think that’s realistic. But I’ve interviewed and had like, “Here’s a take-home. It’s four hours”, and I was just like “Oh, my God…” It was not a great experience.

[28:27] I think take-homes can be a nice option, but you should treat it the same as you would an in-person one, and try to keep it around an hour, maybe 90 minutes, depending what it is… But I just think after that point, you’re just exhausting people. I don’t know if you’re gonna get much better signal… Unless you actually expect your engineers to sit at their computers working on one thing for four hours…

When you do this specifically, do you say like “Start a timer, and 90 minutes - whatever, you’re done. Even if you didn’t finish, just submit what you had.” Or do you say like “It should take 90 minutes, and this is what you should do”, and then it ends up in people sometimes taking longer, sometimes less? Which of the two approaches do you prefer?

I feel a little torn on this honestly, I feel like I’d rather just give them the recommended time, because the idea of a timer feels stressful to me… when I’ve done it with a with a timer–

Not a real timer, but in the sense of “Don’t do over 90 minutes” is what I meant.

Yeah, yeah… I think I would rather just say “Yeah, please don’t spend more than this.” Because there are other tools that then do that, but they enforce it. So you start the exercise and it’s forced, and that can feel stressful. I want to minimize stress as much as possible. So yeah, ideally, when I have seen it, it’s more just like “Here is an exercise. Please spend no more than 90 minutes on it. It shouldn’t require more than that.”

And then the guideline is basically if it’s been 90 minutes and you didn’t finish, just submit what you have. You don’t say “I expect this to take 90 minutes, and I expect you to do A, B, C.”

No… Yeah, I was gonna say, it’s usually pretty open.

Emma, what are your thoughts?

I have a follow-up that I really need to say… If you’re a software engineer and you’re interviewing for a company, and they’re like “Do this thing. Create this app. It should take no longer than 90 minutes”, it’s like, I’m gonna put my hands up and say, “I will spend all night to make it the perfect app I’ve ever built in my entire life, to submit…” So what I wanted to bring up was the reality of like, even if you say - and maybe this is just me - like “Hey, build this basic search engine for searching cat memes”, I’m gonna build that and have the most beautiful UI, the most optimized… Like, how do you get around that? And the fact that maybe if I follow the rules, and I’m wonderful, and I only spend 90 minutes, and I provide you with what you wanted, maybe I just I didn’t manage to finish it, but I did follow the guidelines, versus someone else who has submitted and they spent all night on this beautifully perfected… Like, do you take that into consideration and go, “Hm, this is really good. Angelica didn’t do this in 90 minutes…” How do you mitigate that?

So when I’ve used these - and I’ll say I’ve only done take-homes to do interviews a couple times - is one is really how you structure it. So I would not be like “Build an app”, because to your point, there’s almost no end, and you can go so far with that… Usually, it’s something that’s already pre-built, and then it’s like three pieces that I want you to fix, or add to, or something… So it’s kind of targeted; I’m not going to leave it so open-ended that it makes it really easy for you to want to keep working on it forever… Because I know what you mean; I would do the same. I think so many people – you want to be perfect. So if it’s too open-ended, then you leave it like that… So the idea is to have a very specific set of problems that people can touch in, and hopefully that – so basically even if you do them perfectly… Like, there’s nothing further to do, if that makes sense. There’s no extra credit, even if you really wanted it. But I don’t know if you have any other – have you used them much, Emma, or any other approaches there?

[32:12] So I tend to lean in favor of a technical screen in-person as opposed to a take-home. If I have either been sent a take-home to fill out myself, or if I’m sending that to candidates, in my personal experience, if I see it and it’s going to take – I mean, I’ve received one that was just an absurd number of questions… And my reaction is, “Okay, I’m going to politely bow out”, because like you said, this isn’t your full-time job. Like, you have a full-time job and you’re also exploring other companies… So I think being really mindful of the fact that this also should be a good hiring experience for the candidates is huge, and crucial, and I think ultimately determines the success of being able to fill the roles well and quickly.

When I have crafted or helped craft, what those take-homes look like - it is very similar to what Jonas is saying. The first question is something like “Remove the duplicates in this array.” And then the follow-up questions would be, “Can you do that using recursion?” or “Can you do that and inherit a class?” or something like that. So it builds upon itself. And it should be, in my mind, less than five questions. It shouldn’t take very, very long. But I also don’t believe that that – in my experience, it hasn’t been time-boxed by the recruiters… Like, “I’m going to hand you this take-home, and you need to get back to me by Tuesday afternoon.” It’s typically “Here’s the take home. When you finish it, we’ll schedule the rest of the interviews.”

You talked a lot about the many, many different parts that make up the full interview process, and the fact that it could be spread over many months, it could be one day of intense interviews… I’ve certainly experienced and done that… So how do you prepare for all this? How do you get yourself ready to do all these many different interviews?

Yeah. I mean, ultimately, practicing. And I think I even saw a study that basically said people are more successful the more they practice… Which isn’t surprising, but it just shows you that, unfortunately, I think for the most part, interviewing is a skill, and you have to practice to develop it. There’s a whole other conversation we could have on how to actually assess juniors maybe that’s like another day. So I think for the world we’re in, and what you’re gonna face, you have to practice and just like set aside time every day, every week… Understand your schedule and plan around that, and know how much prep you think you’re going to need to be comfortable… Because we can dig into different tips there, but the main thing is try to have a learning plan and prioritize it.

I feel like I definitely didn’t do that well earlier on, and so then you just go in like a wormhole of answering like coder challenges, and then suddenly you’re like “Oh, but that actually isn’t what I need to practice.” You know, you can just get really stuck in one thing. So try to actually step back and be like “Okay, these are the types of companies, these are the types of roles, so I should like focus on this thing with API design”, or whatever you know your weaknesses are where you need to really practice and have a plan for it… Because otherwise, you could spend a lot of time studying stuff that won’t be relevant, and that really is rough.

If I were going to tips and tricks, I like to create a document and a list of questions that I would like to practice, to Jonas’s point. A kind of learning plan of what I would like to cover in preparation for – and again, it’s more broad. It’s not specific to a particular role, but the roles that I’m applying to at large… And then thinking through what attributes do I believe are going to be assessed. And then I think it’s really important to practice speaking out loud against those problems. Because I think it’s one thing for an engineer and for anyone to be able to solve a problem, and that’s wonderful and great, but I also think it’s crucial for obvious reasons that you are able to talk through in an interview, how you came to that conclusion, how you’re thinking about the problem space, and the delivery of those answers needs to be understood and digestible.

[36:27] So I think that in preparation for the technical portions of your interview, I think you should familiarize yourself with pretending or doing some sort of role-play, and just say “This is what collaborating meet with me would look like and mean, and so this is how I’m thinking about doing checks against “Is this what I’m supposed to be solving for?” and questions like that. Because I don’t think you can do that if you’re just writing down the answer to a coding problem on a piece of paper. You won’t be doing that, especially in a virtual setting.

And prepping those stories, prepping your examples.

Yes.

And what is your fun, little story that demonstrates you’ve done this thing, whether made up or real?

[laughs] Oh, and just read your resume, and then remind yourself what’s in there… Because sometimes you write it, and then you just send it out there… And then practice talking through those examples; because to your point, it’s crazy how you just forget everything you’ve ever done when someone asks you about it suddenly. Right? Like you have to kind of – like I was practicing…

“Tell me about yourself.”

Yeah, right? I even did a practice with a friend recently, who was getting into an interview again, because it’s just –especially if you haven’t interviewed in a while, right? You just need to wake up that part of your brain that knows how to talk about yourself in a nice, concise, very clear and direct way… So yeah, practice that, for sure.

So when you’re asked to talk about like a challenge you faced, or tell us about a time you like failed, how honest should you be about that? Like, “Hey, I once took down the production DB…” True story. [laughter] Like, how honest should you be with those stories? Or how do you frame it as a win?

Yeah, the weird thing about those - and it’s helpful because I now have interviewed but think about what the interviewer is trying to learn from it. Generally, those questions are trying to get at your ability to learn, your ability to have empathy, your ability to recognize mistakes… To me, it’s not so much about how honest, it’s more about how well do you craft that story, so that it comes off like “I brought down a production database”, right? You can say that, because I think most people accept that engineers make mistakes… But it’s more about like how you say it, right? Can you speak to the fact of like “This was the mistake I realized. Here’s what we did to improve, and I got this from it.” That’s really more what you’re trying to get at.

Again, I think you want to be careful about treading into weird waters of, I don’t know, maybe really weird interpersonal conflicts or something, because that could just start sounding a bit like “Ooh, I don’t know…” For the most part, you want to just think about what the takeaway from that story is, and that’s really what counts, and make sure that comes through.

Yeah. I agree with everything Jonas is saying. I think that as with anything, it’s not that you haven’t made mistakes; that would be absurd, if your interview – like, that would be a red flag for me as an interviewee, if the interviewer that I am running through this process with is looking for perfection. I think that that’s an unrealistic expectation. So I think there needs to be this mindfulness of the interviewer… The interviewer’s job is not to trip candidates up when they ask a question, it’s to better understand what the key takeaways and the lessons learned are, especially in a question like “What is a difficult experience that you’ve encountered in your career, whether that’s a difficult situation with a colleague, or a system, a production-level issue that you’ve released, and how you dealt with it?” I think that it’s “How do you deal with adversity”, right? That amounts to, you know, are you the type of person that doesn’t tell anyone when there’s a production-level outage, and you’ve introduced a bug fix? Or are you the first one to say, “Something’s gone awry, and I need some help. Who is my network of people that I can reach out to to help?”

[40:24] I also have a genuine follow-up question that came up to me, very similar to what Angelica was asking… My question is how would you craft your answer to “Tell me about yourself”? Because many interviews begin with this; like, two minutes where you have to put everything into context, and also tell your life story, also put the important things… What should be there, what should not be there? How long should it take? How do you do this?

Yeah, I would definitely recommend not too long. Like, keep it at a minute. I tend to avoid that question, to your point, because I think it does end up being a little too weird and open-ended… And because I have seen sometimes you ask it and someone just starts talking, and they’re going for like a really – and you know, in these interviews you only have so much time. And so sometimes he would like starts to tell –

That was me at my very first job interview… [laughter]

Sometimes it can be interesting!

“I studied in high school…”

Yeah… You give like your whole life story, and it’s like, it’s nice, but it’s also like “Oh, my God, we have 45 minutes, and I have ten other questions to ask you.” So yeah, I usually think it’s good to just talk a little bit about – like, try to find a way to summarize your career journey through a couple key points… Like, “Yeah, I’ve spent most of my experience working in backend engineering, I’ve recently transitioned to management, because I’m really interested in how to empower people, and I’m looking for new roles because I’m looking for a new challenge in mentorship.” Like, hit a couple key points that highlight where you’ve grown, where your key experience has been, and then what you’re looking for… And I think that usually gives enough of an open, where the person could follow up on any of that if they want to, or they can just be like “Great!” and then move on to the next thing if they want… But they at least have a little bit of context about you.

It’s amazing how many people sometimes don’t read resumes… So I do think it’s a nice chance to just highlight a couple things from your resume, in case they didn’t read it… Because at least you’re calling that out; because otherwise it actually may not come up in your interview at all.

The thing I’m thinking through is - you know how you can watch a preview for a movie, right? That’s how I think about that question, if you do get asked it, is “What are the highlights? What would you say about yourself that either is on your resume, and you just want to bold and underline, and say “Hey, this is really great, and this speaks to who I am, and my type of character, and how I approach leadership, or mentorship, or great things that I’ve done as a software engineer”, and then allowing space and room for the interviewers to either probe further… But at the end of the day, there’s a list of questions that they’re trying to get through. “Tell me about yourself” is not the main one, so… Yeah, I would just leave that open for the interviewers.

Okay. And then the other side of this question, as an interviewer this time, what are some things that you’re looking for in a candidate, and you want to make sure that they happened in the interview?

For something like the technical side, the coding challenges or system design, some things I’m looking for is, one, are they able to dig in and ask more questions, and get more clarification, and try to really understand the problem? But it doesn’t always happen, and most people just jump in, and they end up missing big things, because they don’t take the time to do that understanding… So that’s usually really important to me. Because again, I don’t expect you to know everything, but I do want to see how you try to understand the problem. So I’m usually looking for that.

And then yeah, that ability to really speak to why they’re doing certain things… Because that’s the biggest – I think in a technical thing, you want to make sure they understand the trade-offs of different algorithms they use, or different libraries, or approaches, and not just that they have always done it one way and memorized that one way to do it… Which happens, right? Sometimes we fall into that, and it’s like “I don’t know, that’s just the way I’ve always said it.” But ideally, it’s someone that has a bit of experience, that can speak to trade-offs, why they would do this, why not, or where the limitations might be…

[44:17] I also think though being okay to admit where – “Oh, but this I’m not 100% sure, and so I would do this to understand it further.” That’s okay too, again, because I don’t expect you to know everything, so it’s okay… You don’t need to pretend. It’s also okay at a certain point to be like “This piece I don’t know very well, so I would look into it”, or something.

And then I think just more on the team and communication, it’s really all about just “Will you be a good teammate? Are you going to work effectively in this team? Are you going to be a good mentor, or partner, depending on that maturity? Will you be able to learn? Will you be able to add to this culture in some way, or extend, or bring us something? And will you work well with different partners or peers, depending on the role, depending on that need?” Yeah, what else? What am I missing, Emma? I feel like I’m jumping around all the interviews… What else is there?

I think you definitely touched on the things that I feel are most important. I think it’s a red flag if a candidate should likely have said, “I’m not sure, but I would be happy finding out, and this is what my process for further exploring the solution would look like.” I think interviewers can definitely tell when you’re not being genuine, and I think it’s crucial for a candidate to be honest and humble.

I think it’s crucial that they ask clarifying questions before beginning to explain how they’re going to solution their problem. As engineers, we love to build things, but you don’t want to jump in and start solutioning prior to really understanding what problems you’re solving for. And I think that goes across the board. So yeah, I’d caution that candidate should start with explaining the logic behind the solution that they’re thinking through, and then allow the team the opportunity to collaborate and say, “Can I validate my working assumptions with you?”

And I would also say, refreshing yourself on what you have on your resume and not exaggerating the scope of your role… Because that’s just an easy red flag for me, if I see someone who doesn’t actually have the experience that they’re speaking to… It’s obvious.

So in the spirit of being clear and concise, which is very important in an interview, I would love to hear your three green flags and your three red flags. Jonas.

Sorry, just to confirm, I would like to validate… As Emma said. So a red flag is obviously like a deal-breaker; a green flag - is it like immediate throw at them a job offer, or just like a checklist that this definitely has to happen? What do you mean with a green flag?

Like something that is an indication that they could be the right person for the job. So it’s something that if they say something, if they demonstrate a certain skill… It might even be like they have a friendly, personable demeanor in the interview. That could be a green flag, and it just makes you as an interviewer more likely to give them a yes.

Well, I’ll just repeat myself with that, like, asking clarifying questions, digging in, showing that effort to want to understand really well… I think candidates that seem to really almost be like a step ahead, so they’re a little future thinking with each of their solutions, to where it’s like I almost don’t even have to ask the question of like “Oh, but what would happen in this error scenario?” because they’re already starting to think… You know, they’re kind of like, “Alright, so this is how I do this, but then in this –” They can almost take you through, because they’re thinking through in very clear steps of how the scope or complexity would expand. I think that logical ability to think really clearly and express it is great; when I see candidates do that well, I’m like “Yeah, let’s do it.”

And just generally anyone that shows just a really strong empathy for others, and like someone that just wants to be part of a good team, and is okay learning from failure… You know, low ego, and just generally wants to be a strong teammate is really, really important. I don’t know… That’s the thing, we can always learn a lot of stuff. Like, you can teach someone Go, but can you teach them how to be a good collaborator? Yeah, but that’s harder. There’s a lot less textbooks out there… [laughs]

[50:22] Definitely. Do you want to do your red flags? Or do you want me to go on green lights, and give you a pause?

Yeah, do your green, and then let me think of my red, and then yeah… [laughs]

Good. So I think being able to pull from being concise, but being able to grab the interviewer’s attention with the examples that you’re giving… I really appreciate it when candidates pause before answering; it shows a thoughtfulness to understanding the question before – again, it’s that, like, jump to solution before you really understand. I think that it’s totally appropriate and okay, and kind of preferred if you say, “I’m gonna take a minute to make sure, just to answer your question thoughtfully.” I think that that’s great.

I really appreciate it and love when a candidate comes into the interview and has researched anything they can about the company, about the mission, about what language has probed for the recruiter to say “What language does this team program? What problems are they solving for?” Like, you can ask… I think it speaks volumes when a candidate has done that initial research and legwork to just show interest in, and initiative, when taking the interview.

And then the last one I would say is - perhaps a little bit antiquated, but I really love it when there’s like a thank you. And that could be in any way, but if I get an email from a candidate that says thank you, or I get a LinkedIn message… And I’ve done this myself after all interviews. I just think recognizing that people have taken time to jump on a call with you… It just shows that connection, right? Like, “Hey, I really enjoyed…” and what you perhaps enjoyed from the interview; what you took away. I think that that is not done enough, and it’s like a green light. Alright, red flags… [laughter]

Back over to you. What should you just not do?

Yeah. Red flags… I mean, hopefully I don’t have to say this, but obviously, any sign of like sexism, racism, ableism, ageism, any of that - just immediately no. I’ll just make sure I say that, because sadly, I’ve encountered it interviewing. I think, opposite of a green flag a bit, just really not asking questions or communicating, particularly in technical… It’s hard for me to even understand what’s happening if I don’t get anything… And even if it is – because I do this a bit; when I’ve had to do more like the whiteboarding ones, I’ll say, “Hey, I’m gonna work through this a bit silently, so I can think, because that’s how I think… And then I’m going to give you a summary afterwards.” Like, even letting someone know up front if you have a different style, right? Because I do understand that people have different styles of learning and communicating… But saying that upfront can save you time and make the interviewer better. So not doing that.

And then I think the other one that I’ve seen sometimes is an attitude that sort of implies the user or the customer is dumb. There’s a lack of empathy there, I think, or a lack of creativity in terms of as engineers, how we can make our things actually better and easier to use… That’s something I’ve just seen sometimes, and they’re just like “Oh, those users…” And like, I get it, I definitely can understand, but I think especially in an interview setting, try to really show empathy for users, and trying to make the best product you can for them.

What do they not do, Emma?

I think, to Jonas’ point – I mean, first I’ll bold and underline, don’t come into an interview – just please don’t be racist, or sexist… That’s just –

Or ask the interviewer how old they are…

[53:52] I don’t wanna speak to you… It’s just – I don’t want to speak to you. Sorry, but there’s no room for that. I think it’s a red flag to me if, when pulling from your answer bank, a candidate showcases the quality of needing to be right, versus needing to be understood. I think that that speaks to their character, of how do they show up and up-level their team. I think if you are always needing to be and there are subtleties of your answer that say, “I enter into a room and my way is the right way, and that is the end of it”, those candidates I just won’t pass forward.

And trying to think through what else… I think not being able to bring strong examples to the table of how you have dealt with moments in your career where you disagree, either with leadership, or with your boss, or how you challenge biases in the workplace… I think candidates need to be able to show how they do that and how they provide actionable and valuable feedback… Because I think that it comes back to - I as a manager won’t do everything right, and so I definitely am looking for members of my team that hold me accountable, but that also do so in a way that’s compassionate, like Jonas said. So I think it’s a red flag if, again, somebody is not able to demonstrate those qualities.

So as is the case with it seems every Go Time episode me and Natalie do, we’re going to have to have a follow-up, because we’re coming to the end of our time… But not before we do Unpopular Opinion.

So, Emma, what is your unpopular opinion?

Do we just give one?

Yes.

Oh, okay.

First time on Go Time. So, unpopular opinion - we’re gonna ask you for an opinion that you believe may or may not be unpopular… We’re then going to tweet about it, and we’re going to have a Twitter poll where people will vote on whether they agree or disagree with your opinion. If your opinion is too popular, you’re gonna have to come back on Go Time and give a better unpopular opinion.

Okay, I’m gonna hope that this doesn’t go viral… [laughs] I think that mustard is better than ketchup.

Okay…

Do I need to…?

Is there data to support that claim?

Emma is right.

I thought it was an opinion… [laughter]

Universally, like with any food…

Yup.

Like, you’d rather put your pretzel in mustard than ketchup?

Yup.

No a pretzel makes sense. But hot dogs. So hot dog…? Burgers…?

Yup. Teeny-tiny little, like, pigs in a blanket? 100%, all the time, and mustard.

Do you have a preference? Is it Dijon? Or any mustard?

I’m not gonna be particular. I just like mustard better.

Solid. Okay, we will see.

You wouldn’t ask me what ketchup I prefer… Like, it’s just ketchup.

I wouldn’t. I would ask what kind of ketchup.

The red one.

The red one. [laughter]

I would say clearly you don’t like ketchup, because this can get contentious, so whether you’re like a Heinz person, or… You know, there is–

Inside the ketchup battle. [laughter]

In some countries Heinz is not a ketchup, because like percents of tomatoes… Same as Pringles. Not exactly chips and all those…

[laughs] True.

We’ve unlocked Pandora’s box of condiments…

Somebody didn’t read the docs. [laughter]

Jonas. Unpopular opinion.

Yeah… So think I want to do a bit of a tech one, because this came up recently as I was redoing my setup… But I think you don’t really need dual monitors. I think one good monitor is all you need. And I don’t know, I feel like people get really into dual monitors, but I just think ultimately, it creates too much distraction… Humans are actually not good at multitasking, so one monitor… A good size. Like, I get – like, a tiny little laptop is too much… But get a good one monitor and you’ll be able to do everything you need. That’s probably my unpopular opinion. Let’s see…

I think that might be popular.

I don’t know, I feel like people get so into – like, you see people’s work-from-home displays, and they’ve got this… Well, super-widescreen I guess it’s technically one, but I might count that as two. But like everyone’s got dual, or like the vertical and the horizontal, and… I just think you don’t need it. You only need one.

I feel like the hacker movies have done us a disservice, where everybody is like this… It’s not how it works. [laughter] You just need one screen.

Well, we’ll see if everyone agrees with you. And on that unpopular/possibly popular opinion note, it’s been a pleasure talking to you all today… We’ll have to get you back on very, very soon, side note being I’m loving looking at these lovely four ladies faces on Go Time… Side note… Couldn’t stop the episode without saying that… But let’s say goodbye to our lovely listeners.