In this episode, I talk with Derrick Mar, CTO and co-founder of Pathrise. This is the episode you need to listen to to get ready for technical interviews.
Transcript for episode 74 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
This is Test and Code, episode 74, recruiting interviewing and the whole hiring process does have its flaws. And in episode 72, I talked with April Wensell about how we might go about fixing it from the company side. But what if your of the person being interviewed. You don’t have control of how the interview process is run, but you can prepare yourself for what you might be facing.
In this episode, I talked with Derek Maher, CTO and co founder of Path Rides.
This is the episode you need to listen to to get ready for software interviews. We discussed four aspects of technical interviews that interviewers are looking for, how to practice for the interview, techniques for synchronizing with interviewer, and asking for hints, and even how to ask the recruiter or hiring manager how to prepare for the interview before it happens. If you or anyone you know has a software interview coming up, this episode will help you both feel more comfortable about the interview before you show up and give you concrete tips on how to do better during the interview.
Welcome to Test Encode, the podcast about software development, software testing, and Python.
In today’s episode of Test and Code, I have Derek Mar and he’s working with a company called Path Rise, and we’re going to talk about all sorts of fun stuff. So, Derek, before we get jump into it too much, we introduce yourself.
Nice to meet you, Brian. Yeah. So as you know, I’m Derek, the CTO and one of the co founders here at PathWise.
Path Rice, at a very high level is a career accelerator for aspiring engineers and also mid level engineers, where we do everything as we can as an internal team to help our fellows who joined the program to get the best possible job and career in software engineering and also in other technology industries, primarily right now, product design and product management and data.
Before that, I was a software engineer at Facebook, worked on a couple of teams. One is the 3D and Fee team and also worked on the payments team as well. And then before that was at a company called Great Scope, worked on Full stack development, Ruby on Rails there.
One of the things we talked about on the show before is technical interviews and hiring people, but that’s kind of what we wanted to talk about was helping people with technical interviews and stuff.
So I think one of the key insights with technical interviewing is that a lot of it is actually behavioral. Right. And how you actually present the information and how you go about talking through your thoughts and then coming to a solution and then verifying that solution. Right.
Usually when I’ve talked to several hiring managers and generally it comes down to four main things as the rubric. First is like communication, and communication has to do with all those behavioral skills. And the second is problem solving, how you actually go about solving the problem, talking about big Ole notation, different ways to actually approach it with data structures and talking about the trade offs between them. The third is coding or execution, actually coding it and executing it in the way that you discussed in the problem solving stage. And the last is verification, stating your assumptions, again, figuring out if it’s actually 100% correct. What test cases do you test? How do you verify that it’s 100% correct? So generally, those are the four things that for software engineering interviews that interviewers are looking for.
One of the things that is surprising to some people coming into technical interview is the length. Sometimes they’re long. Is there an average range?
Usually it starts with the intro call, which is about 15 to 30 minutes. Then you go into a first round or take home assignment.
And if you don’t do take home assignment, usually the first round is 45 minutes, can range from 30 to 60 minutes, sometimes longer for those that want to be really thorough. But it’s expensive. Right. That’s why you don’t see in the first round, companies going over 60 minutes most of the time. And then the onsite again, ranges from about 30 to 60 minutes per interview.
Yeah. So the individual interview is going to be 30 to 60 minutes, but a person might interview with several different people as a company in the same session.
Yeah. Which means what happens on the onsite round.
So the onsite can be I guess it varies by company. The longest I saw was like a six hour day, which is pretty long, but it includes somebody will take you out to lunch, probably in the middle of it or something.
Yeah. I mean, it ranges from as small as two to three. Sometimes some companies don’t even do on site. Sometimes they make a call after the first round. There are some companies that make it I don’t know how they’re able to accommodate for the cost here, but over the course of three days, I think Travis CI was known for that where they do interviews over three days, and they would actually pay for you to stay over the night so you can come back. So there are some companies that are really thorough, but that’s very fair.
Yeah. That’s something else that’s being tense.
That actually sounds interesting, but I don’t know if I’d be up for it.
The four components, how does somebody get ready for that then and make the most of it.
Yeah.
The first advice they would give, if you’re talking about preparation, ask for more information on how to prepare. Right. I’ve seen this so much. Like, for example, if a company like here’s your onsite, it’s going to be three to 4 hours long. Here’s who you’re going to be talking about. They go like, okay, thanks. I’m going to go. I’ll see you there.
Rather than doing that, you should respond with, I’m really excited.
Is it possible to get on a 15 minutes call so I can learn a little more about the vision and how to prepare. About 40% to 50% of the time, a recruiter will actually do that. And then you can get so much more information about what the interview is going to be on.
But even then, you want to push back more.
The recruiter says, oh, yeah, this is going to be whiteboarding interviews. That’s actually one of our fellows. We told him to say that. And then the response was, oh, you don’t need to prepare. You just have to come and show up. And we’re just like, okay, that doesn’t make sense, right? Obviously, you can prepare for something. So we told our fellow to respond back with like, oh, is it going to be data structures and algorithm focused, or are we going to be testing like Selenium if it’s a testing engineer position? So we told him to respond with a couple of options. And the recruiter actually got back with tangible results. Oh, yeah, it is going to be focused on whiteboarding interviews that are data structures and algorithms. I would focus on data structures like Heaps and tries as well, because those may be asked. And that’s so huge, even that small little amount of information change your trajectory of what you prepare for. Right. And it’s just a couple of emails. If they don’t respond, which happens, there’s no negative consequences of that. All they know is that you’re more excited and you want to prepare. Right. That’s the first thing I would recommend is actually like doing that.
Another tip as well is that I think when you’re given the names of people that you’re interviewing with, you want to actually reach out to them beforehand as well.
Yeah. And it’s something that I think it is important to highlight. I’m surprised how many people will show up and not know what our company does and not know anything about any of the people interviewing them, even though we’ve told them the simplest thing you can do is just Google these people’s names and see if you can find out who they are. They might have a LinkedIn page or something.
This episode is brought to you by you, especially Patreon supporters and PITest book Purchasers is that a word at testandcode.com? There’s a menu item called Donate that takes you to the Patreon campaign where you can join over 50 other people in supporting the show by donating a buck or two per episode to keep the show going. There’s even nine people pledging $5 or more like new patron Cliff Wildman. Thanks Cliff and everyone else and also the people that have purchased Python testing with pytest also support the show. I wrote that book not just to teach you all the power of pytest, but really to get your head around how to think about testing with Pytest. The most awesome moments for me at Python were all of the people that came up to me and told me stories about how much the book helped them. Truly very cool. You can buy it anywhere. Find books are sold, but if you’re opting for the ebook, grab that from Pragmatic directly.
Why data structures and algorithms. Why do people interview over that? Just because it’s easy to do.
Yeah, I think this is a lot of people are very opinionated on this. Like some really hate that process.
They have a lot of qualms against it in the sense that it’s not related to a lot of software engineering work that’s actually done. If you’re full stack developer and you’re building like a Web application, there’s very rare times where you have to use data structures and algorithms to actually tackle the use case that you’re building. Right. And then the other side is that it gives you a sense of their problem solving skills and how their ability to approach problems from scratch and understand their way of thinking.
And to a lot of companies, that’s the most important thing versus knowledge based questions. Right. Where people say, what is the JVM?
They’re just based on your knowledge. And the reason why some companies hate that is like, well, you can always look those up. Right. That’s something that you can learn really quickly. What I want to really see is your ability to break down difficult problems like you would potentially at a company, even though it may not be data structures and algorithms focused.
Okay, yeah. Okay. We walk into a room, there’s a whiteboard.
What do you do there?
You always want to make sure you take the first at least 15 to 30 seconds, maybe more, to make sure the problem is. Well, scoped. Right. And this applies for any type of interview, especially for product management interviews, etc. For data science interviews, but software engineering as well. Right. So asking clarifying questions about the parameters that are coming in, sometimes the scale of the parameters like, can you load the entire array to memory?
There’s a question that I specifically asked that explicitly test for clarifying questions and your ability to scope things. And if you don’t ask it and you just start solving the problem, you’re going to get points knocked off. It’s going to be a negative signal that I’m going to know is like this person didn’t scope the question correctly. Right. Of course, sometimes it’s very hard for you to figure out what all those clarifying questions are. In the beginning. The problems are really hard. Right. You’re trying to figure out how to solve it. So you want to be able to state those assumptions as fast as you can. Once you start doing the problem, once you realize that it should be something that needs to be clarified, you want to state it immediately before you start coding.
Okay. Yeah. One of the things that’s hard for some people is talking while they’re coming up with a problem or coming up with a solution.
And something I wanted to bring up also is to even if you just got to practice with a friend or something, doing whiteboard interviews, be able to talk while you’re solving something.
Because that’s not something we normally do, at least I don’t normally do as an engineer. I’m usually in my head while I’m solving problems.
Yes, absolutely. That’s one of the weird things about interviews.
Yeah, definitely. And it’s a weird thing to do and it’s actually hard to think while you’re speaking. So you got to kind of practice to do that.
Yeah.
So we did communication.
Yeah.
So there’s three more problemsolving. Right. Problem solving. I think one of the tips there is when you talk about big O notation. Right. Big on a high level is like the speed of the algorithm in the worst case. So a lot of people, they go like, oh, it’s oven squared. They go like it’s O of N, but they don’t specify what n is. And like 80% to 90% of the time, it’s actually not clear what n is. N could be many things. It could be like if it’s a 2D array, it could be the length of the 2D array, or it could be like every single cell in the array. Right. So it’s very important to clearly define what N is like O of N, where N is the length of the first array in the inputs of these parameters. Right. So just small tip there is like specify what N is. Just be clear about it. So everyone’s on the same page.
I think another thing in this topic is in terms of hints, I think you actually want to listen to the key words in the hints. If you do need help, listen to the key words that the interviewer is saying. Usually they’re saying the hint in a way to give you some insight. So a common hint for search questions is like, oh, you’re linearly searching through the array. Can you do faster? So when you hear linearly and searching, you should be like, oh, okay, probably binary search, right. This is a search problem. I should talk about that. Right. So listen to the keywords that people are saying. Now, since I talked about asking for hints, let me briefly talk about that from when I interview people, they say like, oh, I’m kind of stuck. Can you help me? Or is it possible to get a hint?
And that’s an optimal for a couple of reasons. First is if you say it like that, I don’t really have the context of what is the most optimal hint to give you because maybe it’s too high level where I give you a hint that’s not really going to help you or something. You already know what’s the first thing. And the second thing is, it just makes you sound like you’re asking for help. Right.
A better way to do this is to first state your assumptions go like, okay, so I know the array is sorted, but I’m struggling with some topic. Like, I’m struggling with how to actually iterate through the array to solve the problem and talk about that a bit and then go like, am I going down the right direction or do you think, do you have any thoughts? So when you frame it like that, it’s like, oh, wow, it’s much more structured. I can see that why you got stuck in a certain way. So again, it’s not always about solving the problem. It’s also about your framework and the process you took to get there. So if you explain that to me, not only can I give you a more optimal hint and you’re framing it as more collaborative as you’re working with me, but it just makes you sound like more insightful and that you’re more systematic about solving the problem.
Yeah. Also asking a question that’s closed question, not an open ended question. Being able to say, like, how big is the array? Is it megabytes? Is it terabytes? Can I fit it in memory?
Yeah.
These are assumptions that you can ask those questions. You’re going to go down the right path. Not only is it about it’s not really about solving the problem, it’s about how well you’re going to ask questions when you’re on the team as well.
Yeah, exactly. Because in work, that’s what it is. Right. If you’re stuck, can you communicate how you’re stuck?
Right.
You go up to somebody and say, can you look at my code and tell me what’s wrong? No, I don’t have half a day to help you with this, but can you look at this line, this line, I expected to do this and it’s not it’s doing this other thing.
Exactly.
And, oh, yeah, I can help you with that in like five minutes. So I do want to reiterate that, at least with me, it isn’t about whether you can really solve the problem correctly. It’s about this whole process. Right, right.
What do you mean by coding and execution?
Yeah.
So coding and execution, this is actually implementing it. Right. So this is more technical at that point. It’s important that you talk through your code, but staying silent the entire time you’re coding, like if it’s more than three to four minutes is nonofftimal. Right.
Right.
Because a lot of times I’ve seen this interviewers are busy and they’re engineers, they want to code. So they’re going to go like code and write some emails while you’re coding. And that’s not good. Right. You want them to stay attentive and actually see the signal that you’re doing, but also they may be lost. So if you’re just coding and you’re going down the wrong direction, they can’t help you.
Right.
At a minimum, whenever you finish a logical piece of your code, usually around two to four minutes, you want to at least chime in and say, okay, this is what I did, or this is what I’m planning to do next.
At a minimum, some people are really good at coding and talking, and that actually helps them code. So that’s, like usually the most optimal. So it’s important to get into that habit. As you’re saying, if you’re practicing one of the recommendations, if you are doing it alone, still not too optimal. But sometimes that’s what you have. You should at least record yourself so you pretend like someone is listening to you. And every so often I should actually listen to yourself as well and analyze how you’re communicating.
Okay. Interesting.
Yeah, there’s a lot of other ones. I think what’s a little more technical is like helper functions are really great. Right.
I think in technical interviews, people tend to, like, write one big bucket of code in one method. Right. But if it makes sense to break up, like a logical piece, like if there’s a depth for search in a particular part and that’s only part of the algorithm, then you can put that in helper function so that you can focus on that later. And even if you run out of time, it still seems like your code is correct because you have the helper function. That makes it logically seem like it will work if you coded that helper function.
Yeah, that’s awesome.
While you’re talking about this, you can say, hey, this is one part of the algorithm. I think it’s going to break up the flow of the rest of it. So I’m going to pop that into a helper function. Maybe we’ll bring it back in line later.
But for right now, I’m going to put in the helper, and then also it could be a way if you really don’t know how to do something. Like, I actually don’t know how to do this sort of the sort thing. So I’m going to assume I can solve that later and I’m going to punt and put it in. But that’s actually how you write code anyway.
Oftentimes if you want to punt and it’s going to break up the flow to try to figure out part of the algorithm to get in a helper function. That’s a great idea. I’ve never seen anybody write a helper function with them during a coding interview.
I don’t think.
Yeah. I mean, it’s relatively less common because people don’t really think about it, but there is a subset that do for sure. But just one thing that I think should be more frequent but is not really done that much. Okay, technical interviewing. Yeah. And then the last verification, I feel like this one here is the one that people, at least unless you’re a testing engineer, and that’s like the forefront of your mind, especially younger engineers that are looking for their first roles, they tend to miss this one completely. They’ll go like, oh, I think it’s correct.
I think it’s right. And that’s like literally like 10 seconds after they finish the code. Right. And as you know, in technical interviewing, you’re solving a hard problem in the spot. There’s always going to be some error if it’s a reasonably difficult question, whether it’s a syntax error or a logical error. So it’s important to at least scan through your code at a high level and make sure that there’s no misspellings or syntax errors. Usually I recommend a talk through your code too, because it helps your interviewer kind of understand and sort of reabsorb what you’re doing as well as allows you to detect those logical errors and syntax errors as you go. But depending on your confidence of the code and how much you feel like the interviewer is trying to optimize for speed, you can change the level of verification. So it does depend on the interviewer.
Do you recommend people actually write down a handful of test cases and walk through what the algorithm does with test cases?
I think it depends on the interviewer and it depends on your confidence of the code as well. So this one is actually depends.
First of all, if there’s a testing position and they’re literally telling you I want to see the test cases, then obviously you want to write the test cases. But if you’re reasonably confident and you feel like the interviewer wants to go on to another question, but you can also literally ask the interviewer as well. Do you think it makes sense to write test cases? In my opinion, I think I’m relatively confident, so I can maybe just write a couple down and just go through them quickly.
Right.
So it’s okay to communicate to your interviewer on these more opinionated things.
So that’s one thing that I think Canada struggle with as well as they don’t do that enough. They don’t get enough syncing on what the interviewer wants.
Another just popping up on the top of the technical interview.
One of the things that is always common is like, should I continue exploring another solution when I’m problem solving, or should I code that solution?
So that’s always a key decision point you have to make. And that’s another thing you should ask your interviewer. It’s like if you come up with a naive solution problem, just don’t code that ask your interviewer. Should I think of something more optimal? Right? Or should I quote right? Okay, cool.
You’re given a coding interface, so this doesn’t have to do with whiteboard interviews. And there’s a run button. You don’t want to automatically just run it without the interviewers permission because there’s still some interviewers that don’t want you to do that. So it’s important to sync with your interviewer once you finish coding. And there’s like an ID where you can run to ask what the interviewer wants. Like, should I walk through it manually or is it okay if I run a test case through the interpreter just to verify if I’m correct?
And generally you do want to lean towards running it because if you run it in the IDE after you look through it at a high level, it’s much faster than having to manually look through every line and walk through every step. So you just pulled the option to your interview. And usually they’ll say like, yeah, you can run a couple of test cases to see where you’re off.
Should somebody come up with a handful of test input or test cases at the beginning when they’re asking clarifying questions?
Yeah, I’ve seen a couple of styles. I think both work. I think it depends on the candidate generally. I think spending too much time is not optimal if it’s a software engineering interview. I think coming up with a couple like saying, is the array going to be empty? Is the string going to be valid?
If it’s a dynamic language, things like that are good to ask. But I think writing like five to ten test cases in the beginning is not that optimal. It’s better to start solving the problem and then you’ll figure out the test cases from there.
Well, that’s actually quite a lot of information. We went through all four of those parts of the technical interview process through the communication, problem solving, coding and execution and verification.
All of that involves communication, though. You need to be talking the whole time and that’s something that people don’t normally do. So practice is going to be important. The things that we talked about over the technical interview tips, those apply to everybody. Right. I mean, it doesn’t matter if it’s a new College grad or somebody transitioning.
Yeah, absolutely.
It should be obvious, but it isn’t always to people. It’s to be able to speak about the things that you put on your resume, you need to be able to talk about them.
Oh, yeah, that’s a huge subject. Yeah, I can probably about 5 hours on that.
Well, I can’t believe how many people I’ve talked to where they list their skills. And I’m going to assume that your skills are in order of skill level. So you’re going to put like if you’ve got them in a list, the one at the top of the list or the left side is going to be the thing that you’re really good at or something. So if I ask you directly a question about tell me you listed Python and Ruby at the top of your two skills. Tell me the difference. What do you feel like the big differences are between Python and Ruby? And the answer comes back, well, I only took Ruby for half of a class and that was like five years ago, so I don’t remember much.
Don’t put it on your resume.
Yeah. Or if you’re going to put it, you should state like your level of proficiency, the language. Right. So that’s one of the things that we use to adjust in the resumes.
Am I proficient? Am I an expert. Am I intermediate?
Definitely. Yeah, that’s a good point. And if you just be honest about a beginner, I’m a beginner at these four things, that’s fine.
I might ask you about it, but it’s not going to be a surprise if you say yeah, I basically did a little toy project just to feel for it and then that’s it.
We could go there’s so many things we could talk about. We could talk about how to do better resumes, we could talk about transitions into your job. But I think we got a lot of great information today and I want to thank you for coming on and let’s wrap it up here. Now, if somebody wants to learn more about pathrize, how do we find that again?
Yeah. So if you want to learn more about PathWise and go to pathrise.com, always feel free to message me on LinkedIn as well.
Okay. Thanks.
Thanks again to Derek for coming on the show and sharing these awesome interview tips. Thanks to Patreon supporters. Join people like cliff Wildman and keep the show going.
Thank you to people who purchased Python testing with pytest links to the book and the Patreon page are at testandcode.com 74. That’s all for now. Now I’ve go out and test something.