Jan. 10, 2022

Backend Mock Technical Interview in 2022 | Python and Algorithms


I brought on a VP of Engineering to do a mock interview with an aspiring backend web developer. Kudos to Eric for having the confidence to do this on a public podcast episode. Remember, all backend interviews can look a little different, but hopefully, this gives you some insight into what an entry-level backend interview can look and feel like in 2022.

Don Hansen (host):
Linkedin - https://www.linkedin.com/in/donthedeveloper

Scott Ferguson (interviewer):
Linkedin - https://www.linkedin.com/in/scottferg

Eric Kim (interviewee)
Linkedin - https://www.linkedin.com/in/ericdwkim
Github - https://github.com/ericdwkim
Twitter - https://twitter.com/ericdwkim

---------------------------------------------------

🤝  Join our junior friendly developer community:
https://discord.gg/H69QqZ8MVJ

🔥  Want more personalized help from me? Here are the paid mentorship and review services I offer:
https://calendly.com/donthedeveloper

❤️  If you find my content helpful, please consider supporting me by becoming a channel member and get access to additional perks. Every little contribution helps and is actually used to pay my bills.
https://www.patreon.com/donthedeveloper

---------------------------------------------------

Disclosure: Some of the links below are affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.

📚  Web development books and other products I recommend:
https://www.amazon.com/shop/donthedeveloper

Dev Interrupted
Behind every successful tech company is an engineering org. We tell their story.

Listen on: Apple Podcasts   Spotify

The Asset Hero Property Management Podcast
Your one stop shop for property investment strategy and management.

Listen on: Apple Podcasts   Spotify

Three Thirty3
Hosting entrepreneurs from the web3 and NFT space to share industry insight and trends.

Listen on: Apple Podcasts   Spotify

Transcript
Don Hansen:

Hey everyone, if you wanna see what a backend interview is like, I just hosted a mock backend interview for the interviewer. I invited on Scott. He was my boss's boss. Um, I think CTO and then eventually became VP of engineering. He manages a pretty large team right now. Um, and he has hired hundreds of engineers. He's very kind, very kindhearted and very candid, which I appreciate both sides of that. But we invited on Eric, the brave soul, who is an aspiring developer, definitely with an interest and backend from what it sounds like. And he decided, um, he wanted to get a taste and a feel for what a backend interview is like. So I hope you like it. Enjoy.

Scott Ferguson:

All right. So, um, Eric, we got about an hour. Um, and what I like to do here is wanna think about no more than 10 minutes at the, the top of the hour here. Learn a little bit about you. What kind of motivates you? What's got you looking for a new role. What does good look like in your next role? Um, what does bad look like? Um, just get, understand a little more about you. Then we'll dive into a coding portion, some virtual white board just kinda dive into some problems and discuss things it's meant to take more than the, so if you run time that's, um, I just wanna give us an opportunity to get our hands dirty and dig in. And then at the bottom of the hour, any questions that you might have for me? Um, so we'll leave some time at the end for that sound good. Sounds good. Cool. Give me the 10,000 foot view. What are you doing right now? What's good. What's bad. What's got you.

Eric Kim:

Sure. So, uh, just a little bit about me. Uh, I actually was in a blockchain startup for a couple months and I quit that, uh, back in, uh, early September. Um, so I got my hands, a little dirty coming from no coding background or programming experience, and that got me interested in the full stack. So, you know, front end, backend, everything I wanted to learn at all. Um, I, I gained a little bit of experience from that, uh, but I wanted to gain a bit more hands on experience and kind of do, uh, my own thing and do production code. So I took the leap of faith and I decided to join a new camp bootcamp, uh, which was a coding bootcamp. And they offered a Python backend program, which I started in early October. And I've been learning and growing since then.

Scott Ferguson:

Great. Um, so with the blockchain startup, you didn't have any programming experience prior to that?

Eric Kim:

Uh, no, nothing prior to that, uh, that was pretty much my first, uh, my first, uh, language I learned wasn't actually Python and it was actually a smart contract development language called solidity. Um, and I did get a little bit, you know, dirty with that learned a little bit of this, you know, just in tax. But other than that, nothing really major.

Scott Ferguson:

Interesting. What did that look like? What was the learning path of that like for you? Was it. Self-driven did you have learning materials?

Eric Kim:

Oh, uh, so most of it was, uh, somewhat tutorial base, but I did play around with a production code base a little bit. So I got to, you know, gain a little, um, sense of the land. So, uh, played around with the smart contracts, see how the smart country development process goes, how these contracts interact with different contracts and how it communicates with the blockchain. Um, I, I honestly will say it was a very, uh, valuable experience for me. Um, uh, so solidity itself is, uh, very syntax, uh, similar to JavaScript. So, I mean, we all know how JavaScript can be symptomatically, so , it was definitely not the most friendliest, uh, first language to learn, uh, for sure. Uh, which is why I kind of thought, you know, maybe it's time for Python instead. Um, uh, but that's, that's where I'm at. Uh, I now am, would consider myself a Python maxi, but, uh, uh, I do appreciate both languages and frameworks now.

Scott Ferguson:

Have you ever seen that meme of the, uh, the JavaScript reference manual on the JavaScript? The good parts. And it's like this big,

Eric Kim:

right? I haven't seen that exact one, but I feel like I've seen

Scott Ferguson:

the derivatives of those. I, I have my copy of the good parts right over there. I could see it. It's it's it's like that. it's pretty valid. Um, okay. Very cool. So you left the, the blockchain gig. Um, yes. What prompted you to leave that and what have you been

Eric Kim:

doing since. Sure. So, um, as typical startups happen, um, uh, difficulty generating revenue, um, definitely difficulty with, uh, getting the right guidance and, um, help that I needed at the moment. Um, you, we wear a lot of hats. That's the cliche that we all hear, you know, and I think in the moment I was looking for a bit more guidance, a bit more hands on, um, a bit more, you know, I want to be able to do my own code. I wanna actually hands on the keyboard as opposed to, oh, learn this tutorial, learn that tutorial. And you can play around with this code base, but nothing will be pushed to production that you touch . So it felt like, oh, uh, what am I really doing? You know, what am I actually learning? Um, so now I'm like, I'm really glad I did went to the, uh, bootcamp route instead.

Scott Ferguson:

And what have you done since the bootcamp? Are you on the first gig or.

Eric Kim:

So, uh, so I stopped the, I quit the, uh, startup in September and then I took a few weeks off and then I, uh, joined the bootcamp, uh, early October and went through the, going through the bootcamp now. Um, right now my biggest, uh, pro side project that I'm working on is a Spotify clone. So it's a, is a CRO app, but, um, it's something that I've really been enjoying the process of learning. So I've been spending more of my time doing that. And on another side project that I'm working on is also playing around with smart country development. Uh, but not with solidity. It's a different, uh, it's more of a Python, um, language called Viper. And, uh, hopefully I'll be able to, uh, make my own smart contract code base. Very cool. I'm

Scott Ferguson:

Googling smart contract. Oh, sure. Um, what's in terms of the work that you're doing, uh, getting into the application development side of things. Mm-hmm what's what are you enjoying?

Eric Kim:

Oh, uh, this may sound very cliche, but, uh, during those bouts of frustration and those aha moments, and, and I know that we all know those are the moments where in the MI in the, in the midst of it, you wanna bash your head against the keyboard and you wonder why you got into this mess. But, uh, after that, that, that light bulb goes off. You, you begin to realize, ah, this is why. And, and then, you know, those, uh, that, you know, light bulb goes off and you realize, oh, this is why. And it makes perfect sense logically, uh, ally. But then up until that moment, you know, it's very frustrating, but it's nothing, nothing like it. It's very cathartic. Um, I, I can't imagine doing anything else. It's such a intellectually stimulating, um, rationalizing. It's really a different way to look at the world. Um, I would say, and I honestly couldn't have chosen a better, uh, career path,

Scott Ferguson:

Marvel. Yeah, no, I totally get that. Um, the, uh, Point that I always go back to with folks even late career is performance is kind of the thing that I've always enjoyed. Um, and mainly because when it comes to performance, generally speaking, it's never what you think it is. It always requires you go digging. It always results in the aha moment. Like you constantly get that dopamine hit no matter how experienced you are when, when you're, uh, investigating that, um, that holds true, uh, for a long time. Cause that definitely can be a lot of fun. Mm-hmm what's uh, what don't you enjoy doing?

Eric Kim:

Uh, definitely the feeling that I will always be three steps. Short or, you know, one step short or something. I'm always, it's always my fault. It's never, it's never the piece of technology. Well, I mean, sometimes, you know, but, um, 99% of the time, it's something that I did wrong, something that I ever looked. Um, and as a perfectionist, you know, it's definitely difficult to let that ego go and, you know, just keep digging in, keep researching and keep asking for help and kind of building that kind of sense of, uh it's okay. You know, you'll learn and grow from this experience, uh, whether whatever, how big the problem can be. But I think that's the jet. Uh, honestly the, the most, uh, difficult challenge is, you know, letting the ego go and understanding that it's all part of the journey, um, of learning and growing there's you will never ha find someone that mastered a language or mastered a framework everyone's learning and growing, and it just comes with experience and time.

Scott Ferguson:

Yeah. And Don and I have definitely talked about this before that confidence is the hardest thing to, to build. Um, and my coaching to junior level engineers is I can only say that's the ones that don't work for me, cuz I can't tell you to work outside of your work hours, but to just always have a project, always be working, something always have something that you're on the side, cuz it helps to get a lot of that outta your system fast. Um, and uh,

Eric Kim:

can't disagree with you on that point. Mm-hmm

Scott Ferguson:

cool. Um, so like I said, I wanna spend about 10 minutes just kinda diving to you. Thank you for that super level lot. Appreciate doing that deep dive. Um, but we'll do now is we'll switch over to a virtual whiteboard and I will shoot a note into the chat with the link. Um, and then I will share my screen on the screen. And then question for you. I think I know the answer, but there is no wrong answer for this. What language would you like to use Python please? Python two or Python three,

Eric Kim:

uh, Python, uh, Python three. Okay.

Scott Ferguson:

Um, so what we'll be doing is what we'll be building out secret Santa, um, or, uh, I think white elephant as the other term as goes by, um, and it's just programming the rules of the game. So secret Santa has three basic rules. You put names into a hat, you pull the names out. That's the person you're gonna give a gift to in order to write the game out, we need to follow three rules, each player. And I gave a list of players here. It's just an example. Barney, Wilma, Fred pebbles, and bam, bam. Each player will pull a name and they can only give a gift one time. The each person can only receive a gift from another player. One time you can only give or receive, you cannot give or received yourself. And then fourth point here, sorry, is that this should happen at random. So every time we run this, we actually wanted to come up with a different result. So no real roles on what the input looks like, or the output looks like just that we are capable of pairing things up. So whatever you're comfortable with there, but what I've done here is put together a quick Python example where we have this simple function called go, and it just returns obviously a static result right now, but it's showing the relationship in terms of pairs of strings. And so, um, you know, for the input, Fred will Barney pebbles and bam, bam, you get out as results. We can run the code where Barney gives to Wilma Fred gives to Betty, et cetera. Cetera. Does that make sense? Yep. Okay. Um, you know, I tend to do these things, however, you're comfortable, right? So these are obviously. Be a little bit nervewracking experiences having to do some virtual whiteboarding. If you need to Google anything, feel free to Google it. If you wanna talk through anything, feel to talk through it, otherwise I'll let you just kinda get started and let me know, you know

Eric Kim:

what you need. Sure. Okay. I'm just gonna go through and read it to myself. Given a list of players, pair up players so that each player gives a gift once. Okay. So one, each player receives a gift once. Okay. So no repeating players cannot give or receive to themselves. Makes sense. Select. Okay. Okay. So let's think. Okay. So we're putting in this list and we need to be able to get back, uh, an array of array. Okay. So this ones, it can't be duplicates and it can't be repeating. Hmm. Okay. So my first thought is to begin with a, uh, some sort of, um, to iterate through this list of players and to, um, Hm. So I wanna be able to somehow, uh, first categorize these players. Um, initially I was thinking about whoops, uh, doing a, um, some sort of for loop, so that way I can iterate through and assign each player to a different player. So, uh, you know, uh, Fred with Wilma or Barney with peppers, uh, my second thought is I could do that or I could do first assign this list and put it into an ND dictionary. So I could do, uh, Fred, uh, Fred, uh, With someone and then Wilma with someone. Um, my thought process right now is going towards the, uh, ladder option, uh, as that could potentially help me prevent, uh, these conditionals where I can then somehow have a, uh, statement that will allow me to use that dictionary and say, oh, if within the dictionary, if Fred has already given a gift, um, then they cannot give, uh, again, to another person. Um, Hmm. So, so. That we just need to pair it up with another one. So think we have this list. Hmm. So let's try that. So let's have some sort of, um, uh, MD dictionary. We'll just call it temp. And so, and in this MD dictionary, I want to add all of the players and assign them to a add to the dictionary. So, um, let's well, I guess instead, and, uh, given players and turn so, so I'm thinking if we can add them into the dictionary. Uh, so we're inputting a list and we want to return, um, a list of couples actually. So then we want to package them up into couples. Um, what would be the best way to do that? Uh, let's see, to go from a list to packaging them up. Mm. Hmm. Let's so we have a list and you can just cast it as a couple. Um, but how would, um, I guess that's worth the shot. So instead of going with the dictionary, we can take the, uh, the list. So whatever the list is, and then just package it up as a couple. So what you call it? My, and we'll cast it as a, and, uh, once it's casted as a couple, then we can, um, Hmm, iterate through. Um, let's see. So

Scott Ferguson:

let me ask you this. Does it matter at this point, if it's a couple or not, or even in the output couple? My, my example's actually just a list of two . Eric Kim: Mm. Um, mm let's see. So, so you're saying, uh, it shouldn't, well, you're asking if it does matter or not. Yeah. I mean, um, or spending, you know, details on, on how we're gonna iterate over the list. Mm-hmm , um, it's Python. We can cheat, uh, we're not doing the type safe version of Python, at least I didn't hear, um, this is Python three. This is and pasted from, I know. Um, but, uh, you know, it. Do we need to worry about, uh, switching it to a, before we go through any iteration or anything like that, or so we

Eric Kim:

get the list of players and we want to randomly, so think

Scott Ferguson:

about this in terms of the context of the real game, right? Mm-hmm um, obviously this is software, so we can cheat a little bit here. Um, mm-hmm at certain points, but this was an actual game. We've got a whole bunch of names in a hat. Right. Mm-hmm theoretically, we have that here too. It's within the players, Ray. Right. Um, and then the actual game is you got Barney, Wilma red pebbles and bam, bam standing around in a circle. Mm-hmm , it's just for the sake of keeping it simple, say that, um, I'm using the example input in the comment up top. Barney's the first person in the circle. Barney picks a name, Wilma picks a name, Brad picks a name. Maybe we just start by emulating that experience

Eric Kim:

starting off with so who like an order of, uh, players picking names out of a hat?

Scott Ferguson:

Yeah. The order is superfluous. Like I said, where you can cheat this isn't a real game. Um, and it's, it's just software. So, I mean, we have a list of players. They're in and order the order just happens to be the order that I typed them in here. Yeah. Um, but can we, can we replicate the process of each person and ITing over this and you touched on this earlier, right. Just a simple four loop of right. Going through each player and pairing them up with somebody else would be the active, pulling the name out of the hat. Right. Right. But the first step there is kinda going around in that circle. Right.

Eric Kim:

So we still want to be able to iterate through the list of players. Right. So for every player in, for every player in the list of players, um, you want to be able to choose one of them. So let's say we, so we're, ITing through the list of players. Um, and we want to, I guess, uh, assign. Each player with another player. So, um, oh, let's see. So if we

Scott Ferguson:

just toss quick line here right now in terms of what we have at this point, right. Is we're effectively tossing the hat in circle mm-hmm so the next thing we need to do then is how can we represent the hat with a randomized seemingly randomized? Right. Um, how can we represent the hat in a way where we can a name out and get something random?

Eric Kim:

Um, we could, we could choose, we could just, uh, have it somehow. We could use, uh, like a random function, like that would select out of the list, just a random number within that list. So somehow like somehow make it so that it will pick, uh, the first one in the list or the third one in the list. Mm-hmm, , that's an option.

Scott Ferguson:

I do not remember those off the top of my head, so I assume to look that's

Eric Kim:

so, um, I guess kind of going back to my original idea of, uh, maybe we could assign each, uh, player to a dictionary that will, uh, give it, give us a number and then we could use the, um, the Rand, uh, random. Module the random integer and then select the random number, which will be assigned to a different random player within the list.

Scott Ferguson:

So, uh, if I'm visualizing this correctly, um, we have five keys in this example, Fred will Barneys, bam. Yep. Fred gets a four Wilma gets a one Barney, zero, um, just kinda random indices within that list. Mm-hmm

Eric Kim:

and then, um, so now implementing it. So, um, um, yeah, work. Okay. So, uh, Uh, so from the first to, so we first wanna get the, uh, dictionary and then we also want to append, um, everything in the player's list to dictionaries. So, um, just do, uh, And once we've done that, um, we can assume, um, it'll be 0 1, 2, 3, 4. And so from 0 2, 4, it'll give us a random number and we can store that into, uh, what we call, uh, random choice. And, uh, with that random choice will be the selected, um, individual now to have that randomly selected individual be assigned to a specific player. Let's see. So we have we're ITing through the list and we've appended the list to a dictionary so that we've are able to randomly choose a player based off their number. Now we just need to assign the randomly chosen player to a list. So, mm. But we also wanted to be, so we should only choose this if the. We want to be able to, so 0 1, 2, 3, 4, let's say. And then, so we'll say, and then I guess we could do, uh, so we have so we have them as a dictionary and we are looping through that. We've depended it to a dictionary and now we just need to assign the player to a number. So I guess we could, um, so, Hmm. Can we do something like where we, so within we could do something like this, where. The, uh, specific index from the, from the dictionary gets assigned to. Hmm.

Scott Ferguson:

Well, I think, um, follow where you're going here. I mean, we we're assigning numbers year through four, right? Those numbers tightly align with the indices of the input list. Right. Mm-hmm so if I'm following it correctly, it sounds like as long as we can uniquely assign those numeric values to the keys with an dictionary, then we know which index in the input list is the pair. Right. Mm-hmm I agree with that approach, uh, that certainly solves the problem. I think that the challenge that I see initially, uh, we probably should think through next is how do we ensure uniqueness? Because if I you're kind of like whiteboarding here, so I'm just gonna restructure this just a little bit, just so we're looking at us in the same way here. Sure. But if we're doing this here in a, in a loop like that, so we initialize the dictionary and then for each player we're gonna, um, append. This would be I right. There we go. Oh, yes. Right. So we're depending I, and then, um, into that dictionary. So now you have this empty key there. Um, and then you're gonna assign that value, but what happens if Rand choice on loop over the first one we get Fred Fred gets assigned, ran choice, which is a random manager from zero to four and picks one. Sure. And then Wilma and ran choice. Being a random manager from zero to four also gets one mm-hmm . Now we've broken rule number. One and two mm-hmm I used to. Yeah. Um, so we, we, we eliminate that uniqueness. So how can we follow the solution that you're, you're going with? What are ways that we can start to ensure the uniqueness of the values that are picked at brand?

Eric Kim:

Sure. Um, so we would have to have some sort of way to ensure that, uh, each once a, once a number has been chosen, then it does not get chosen again. So we could, uh, have, uh, if clause where it'll take. Um, so let's say Fred gets, uh, one, so he gives it to Wilma. So, and then Wilma gets one again. So we would have to prevent that from happening. So, uh, if Rand's choice, um, Hmm. I guess, uh, maybe something. We, we would somehow have to. Okay. So from the dictionary. Okay. So Fred gets so, so we iterate through and they get assigned numbers and, uh, we want to make sure that they are not giving it to themselves nor to someone that's already has someone else. So

Scott Ferguson:

we need to, and actually that reminds me now there's actually the two constraints we to be worried about. Right. Mm-hmm um, if Wilma gets one, that's a random choice it's actually giving to herself. So there's also that concern.

Eric Kim:

Right? Right. So we pretty much have to ensure uniqueness throughout. So mm-hmm, um, I guess. So in the first iteration, um, Penn and choose random number. And if so, if a random choice has been already selected. So if a certain number from zero to four has already been chosen, it should not be chosen again. That's kind of what it boils down to. So if zero has already been chosen, um, has been already assigned, then it should not be chosen again by not only the same person, but other people as well. So, um, if brand choice, um, mm. I guess how do I now define whether it was chosen? Uh, so I guess the question then becomes. What the, um, I guess how have to use the dictionary, uh, from the dictionary, if by the way,

Scott Ferguson:

if it's easier to pseudo code, that's totally fine. Sure. Cause as I'm, as I'm thinking through this, I'm thinking of like a zillion APIs that I do not know off the top of my head, this not the same to any higher standard than that. So,

Eric Kim:

so let's see, uh, right. Uh, let's see. So I just need to be able to have some way to determine so, Hmm. So. Uh, so ran, so ran choice pretty much has to be unique. Um, after the random number is chosen,

Scott Ferguson:

what's a way that we can, you know, as we're iterating through the list, mm-hmm of players, we got two problems to solve. Uh, but let's look at the first or actually problem, number three, really, you can't give or receive to yourself. Mm-hmm um, how can we solve for that one? Or is there an easy way that we could solve for that one? Just by virtue of iterating through the list and knowing what position we're,

Eric Kim:

uh, so's see, players cannot give receipt to yourself. So, uh, once we go through the first iteration of the loop, um, oh, um, maybe something like, uh, if the, if the random choice, um, Has already is, oh, maybe something like, uh, if brand choice is equal to zero, then, um, it should take that out of the available choices.

Scott Ferguson:

So part of it, uh, that would be zero has been given a gift now, right? We're ensuring the uniqueness of point number one by iterating through the list. Um, one by one. And so we're only gonna iterate at once. And so everybody gives a gift once, um, in terms of zero and again, I'm pseudo coding here. I don't believe this is valid Python. We, the name itself.

Eric Kim:

Um, right. So

Scott Ferguson:

if that being self aware of where we are in the, in the source

Eric Kim:

list. Sure. So, um, then that would give us the, not only the actual value in the list, but also the index. So then we would need to do something like this, I believe, um, where we then can get both values. And, and then if we do that, then we can access the, uh, player's, uh, index. So if the brand choice is equal to the same index of the players. So, um, so for example, if in the first iteration, zero was chosen, then that means Fred is already taken. He's already giving a gift to someone. And it'll, it should hit this where if zero is equal to so in the players and it is equal to the first, uh, iteration. So Fred's, which is at zero, then we would, uh, now, uh, we should somehow now have logic. That'll skip over Fred for the next iteration.

Scott Ferguson:

Well, in this, in this first pass, right? First execution of the loop, only one iteration happening here. The first value is Fred. The index is zero. Fred reaches into a hat. He pulls out zero or in other words, he pulls out Fred mm-hmm right? Because index zero is Fred. Fred can't give or receive to himself. So if it was a real game, a secret Santa, what would we do?

Eric Kim:

We just put it back in and have him re-pick. So if, if the choice is equal to the actual player's index, AK, if it's their own name, then we simply just go through the, have them re-pick, which is just go to the, go through the loop again. So, um, return, um, I'm not sure if, uh, that's the right. Hmm.

Scott Ferguson:

It's the right approach. I think, um, remember, you know, we're doing one, one loop over those. I wouldn't have picked that out. I'm glad, you know, you're, those APIs better than I do. Um, but again, like we're, ITing over the list just as a one time, right? Just that simple iteration over the, the input is our passing around the circle. Right? Right. So if we're passing around the circle, then really each person gets one turn. Uh, if you will, and using Fred as an example, Fred pull zero, Fred pulled his own name. Fred needs to pick again mm-hmm so in theory, we need to. Just run the body of the loop again. Um, what would be a way that we could do that?

Eric Kim:

Mm, well, the root force way to do it would be to just type the body of the loop again, but, um, a, uh, more simpler approach could be to, um, I guess now that think about it, that isn't, that bad of an idea is to just have him go through it again. Um, so we just have him choose again. Um, so where, but then this time we could do it, uh, without, uh, that choice. So, um, so if who's name, then we want him to pick it out again and doing that is essentially here. Right? So. Uh, but then starting, maybe something like, Hmm, something like this, uh, second and. So then we have him pick out again, but this time, um, we are choosing now without his own name in it, which would be ran choice. And then from that to four. So that, that would ensure that, uh, it, his name is not included in the expense. Oh,

Scott Ferguson:

for that use case. But let's think about another use case now. Sure. And then you're on the right path here, but I think we just need to kind of restructure the, the control flow here. Okay. Um, Fred pulling his name on the first try. It's a possibility it's gonna happen. Yeah. It's the first index in that, that loop. If we just remove that from, um, from brand choice, then, uh, it's no longer an issue, but what if it happens on Wilma and Fred hasn't received a gift yet? So the index of zero still needs to be valid in there. I see. I see. Right. So we couldn't just go from Wilma plus one to the end. In that case, we would have to, um, Still be inclusive of any names that haven't received a gift. Right.

Eric Kim:

So

Scott Ferguson:

throwing performance to the window out the window, like, and it's not their requirement here. Right? Mm-hmm um, what's a way that we could just run those two lines of code again.

Eric Kim:

Um, belief believe could be just, uh,

Scott Ferguson:

that would that's.

Eric Kim:

Uh, could be use another loop maybe. Oh, that's true. So. We could, we would, would we have the same logic within the, the nested for loop? Does that makes sense? Um,

Scott Ferguson:

so it's kinda the brute force method, but it's kind of like a, a do while loop, right? Where do while the ran choice is not equal or sorry is equal to, um, the player's index. So as long as you keep pulling the player's index, try again,

Eric Kim:

could do the same, um, where we're, um, let's see. So if it goes to the first, then it will add. Right. And then that, so, so in the first iteration, it'll take Fred added to the dictionary and assign it a value. And let's say zero gets picked if zero. So if Fred is equal to Fred, if Fred picks Fred, then just goes to the loop again. Um, um, Um, yeah, I'm a little lost. How it, it, it could still pick Fred again, potentially.

Scott Ferguson:

So what I would change here would be just simply this. Oh. So while that's the case, cause we don't wanna iterate over the list of players. Again, that's not really necessary in this case. Um, but we're gonna pick the random choice while they're equal. Right? We're gonna continue to keep picking. I see. And then once you've gotten something that is not Fred, it's not, you know, the player who's picking the name. Um, now we have a name. Who's not me now I've satisfied points. Number one, because we're entering over the list once and going around the circle points, number three, because definitely not giving or receiving to yourself, which means now we have the, the second bullet that has to. Um, also be accounted for here, right? I think implicitly we're accounting for the fourth. Uh, this is happening at random. The second bullet now is how do we ensure the uniqueness of the recipient? So each person only receiving and, um, uh, only receiving it one time.

Eric Kim:

Mm-hmm so just to understand, uh, you correctly. So the reason why we're doing this is so that, um, this will, if this condition is, is, so if Fred picks the same one, then it'll just stay within this, uh, loop. And then until that condition is, um, exited, then it will still be within the flow. That makes perfect sense. So then we now want to be able to, uh, let's see, only once. So now we have to somehow prevent. The player from giving, receiving, um, a gift more than once. So we just change this here so that the logic is the same. And, um, so if we are exiting here, so let's say Fred choose, uh, whoop. So Fred chooses Fred and keep choosing again. And then once he has chosen someone that's not Fred, um, then, uh, Fred will have chosen, let's say one. And so now he will exit and and he will. Mm. Now how do we determine that he, the player will receive one gift only. So.

Scott Ferguson:

I think you touched on the, the basis for this, um, earlier, right? If we have this dictionary that we can iterate over the keys in the dictionary, we're gonna get a name and the value of each one of those keys is going to be an index mm-hmm . How can we ensure as we pick a new name or a new index to assign to a name, how can we ensure that that name has, or that index has never been pulled before?

Eric Kim:

Um, so you can check, uh, see if it hasn't been, uh, well, so this assuming will be the, the index or the, yeah, the index of the poll, the first iterated polled, um, player. So if maybe we could do something like if choice has, has been pulled already, then, um, we have to take that. Number out of the list or, uh,

Scott Ferguson:

almost like a second condition where like the wild loop, uh, and maybe even, you know, and, and for the second time we don't have to this, but you could probably move the, to the top of the loop body. Right. And restructure things a little bit, so that everything's running under that, that condition. But the wild loop conditions should be, I didn't pick myself or sorry, the wild continue working while I'm picking myself or I'm picking somebody who's already been picked before. Mm-hmm right. And that's that if statement that you're typing out there, how do we determine that somebody has been picked before?

Eric Kim:

Um, oh, oh, if, uh, so just to talk out loud, uh, if there, um, if the chose, the randomly chosen number, um, has, uh, is equal to the, um, the value, like the. Key value in the dictionary, then that means it has been

Scott Ferguson:

chosen. Yeah. So just iterate over the dictionary and look to see, have we seen the value before? If yes. Keep going, keep trying again, right. If not, um, it it's valid, if not, and it's also not your own, uh, index, then it's a valid choice.

Eric Kim:

Mm-hmm so in, in this dictionary, if, oh, so maybe something like this. Um, so in the dictionary, if, uh, we're gonna look for that index and if, if this has been chosen, so if this is equal to, um, the player index, then, um, So essentially what this is saying is, uh, the readily chosen player's index within the dictionary. If it has been, if that is equal to a certain player, then, then that's been chosen. And, but do we remove, we don't want to remove them from the list. We simply just want to say that they can't receive another gift so that we, they can't be chosen again. Um,

Scott Ferguson:

yeah. So if they're, if they're present in that dictionary, because we have selected before as a valid selection, then that, that should effectively rule it out. Right. So, uh, using an example, let's say that Fred gives to Wilma mm-hmm um, I'm sorry. Fred goes, gives the bar. So two is assigned to Fred Wilma goes and she draws. And we know that if Wilma continues to draw one, that she'll continue to redraw because she can't draw herself. So we already got covered. Right. All right. So Wilma draws a two. Now it's not her, so we can check the dictionary. But then when we loop through the dictionary, we can look at Fred Fred's giving to two there's our condition. Right. We don't have to, um, that we can't give to, to Barney again, uh, because that index has already been used up mm-hmm that does solve the problem and it solves it actually completely. Um, I think the, and again, just in the interest of that, we can talk through it. Um, it's perfectly fine. Um, I'm not picking on the code pieces specifics. Um, there is one bug though that kinda gets left over. We can spend a couple minutes talking through, um, you got the problem where the problem solved, where. We're iterating over the list of players one time. Okay. So everybody's giving a gift one time. We're selecting it random. And based on these two constraints that I didn't pick myself and I didn't pick somebody who's already picked before that. Um, we're satisfying the, the other two constraints of the game. Like I said, happening at random. What would happen though, if the last name in the list in this case? Bam, bam, bam, bam has not given a gift yet, but also BA bam, hasn't received a gift yet. So the only name left in the list list is bam. Bam. What's gonna happen to this program when you hit that case.

Eric Kim:

Let's see, uh, So, so your question was, uh, what would happen, uh, if that were the case? Um, so,

Scott Ferguson:

so bam, bam. So the hat gets to bam, bam, and bam, bam pulls the name of the hat and the only name left in the hat. Cause he's the last one to go. And the only left the hats BA bam.

Eric Kim:

Mm I see. So then we, I guess, uh, we, we, we should probably put logic in, so, so that, um, it's removed from the list, but I feel like that's not the, that's such a brute force way to prevent that from happening.

Scott Ferguson:

Um, think BR force is the way to go, but, uh, I wouldn't, wouldn't remove from the list cause bam, bam still needs to receive a gift. Right, right. Um, and it's, this is one of those cases where it's not an even a odd thing. Like it's always gonna happen. It's always a possibility that could happen. Mm-hmm um, that the last person is the only person who hasn't been picked yet. Um, In a real game of secret Santa, this would be problematic, right. Because, you know, uh, you're visibly seeing, um, people pull the names. Um, how could you solve for the case and again, just talking through it and how could you solve for that case? Sure. When the last name and the list is the hold, my name left in the

Eric Kim:

hat. Uh, so kind of thinking it in like a real world way, um, uh, you could have potentially, uh, two additional people, so a pair, uh, you could have them throw their, you know, cards back into the hat and then starting from bam, bam, go through the list again. Um, so having, just try it again and just try again. So with additional, um, that way it kind of ensures that bam, bam will likely be able to have picked someone that, you know, he can receive a gift and give a gift to. Um, and the other two, um, can keep going until they're able to get someone that's, um, That way Bamba is included as well. That would be my thought

Scott Ferguson:

process BR force. And like I said, performers, doesn't matter here. That's not the question. right. The questions satisfying the rules. Um, yeah, I think the other way too. Um, uh, and this is where the difference of software versus, uh, real world comes into play. You can really just cheat and just swap bam, bam with somebody else. Right. cause nobody has to know cause there's no real people, uh, playing the game here. Right. Um, cool. We're exactly at time. Um, thank you for running through that. I know those aren't easy. Um, what questions can I answer for you?

Eric Kim:

Uh, I would definitely say, um, points of areas of improvement, um, uh, kind of, uh, my, my thought process, uh, What would be a, uh, better way to approach, uh, just general questions such as these? Um, I feel like, uh, uh, it's difficult to under, uh, to first, uh, comprehend the, the full, uh, problem at hand with the constraints, um, into account, uh, without, uh, fumbling and, you know, running into edge cases. I mean, that's the whole point, but, uh, just kind of getting the full picture and statement, stepping back, which, uh, seems to come so naturally, uh, versus just, uh, more of like a brute force method, which is like the better way to approach that.

Scott Ferguson:

Yeah. And, and I'll say I I've, this is one that I've retired several years ago. Um, purely outta boredom, cuz I did it for like 10 years straight. Um, but having seen, you know, hundreds of can deserve this, like people are all over the map in terms of how they approach the problem and it's a hard problem. Right? And, and the reason I've always liked this problem is that, uh, on the scale of folks who are very new to, um, getting into programming versus folks who are, uh, very mature on a very senior level, uh, they solve it at very different ways. And, and me as an interview, it gives me a lot of, um, insights that I can calibrate against, uh, you know, for, um, how different folks approach it. But I think in general, in terms of the feedback, um, there's, I think definitely confidence in data structures is an area that I would focus, I think. And this is where I kind of interjected early on is, is, um, a bit thinking about, uh, the data structure to use, to track who's getting what. um, spending a heavy amount of time on that, which is really kind of just stems from that lack of confidence, in lack of a better term, some tactical tools, right. Stopping to think about, well, I'm gonna use a for loop here. I'm gonna use a dictionary here. Um, those kinds of things become instinctual over time and practice just makes perfect and the way to get better at a problem like this, and to be able to dive into a problem like this just boils down to that. My earlier comment about, um, uh, having side projects, uh, you know, it, it can help there, um, where I see a lot of folks really strive in this type of an environment when you're doing algorithm type challenges. Um, You know, there's a million of these options online where you can go through and, and, uh, take practice coding tests. Those are a good option for, um, for just getting better at this mm-hmm it does start to become second nature and you start to see a lot of the caveats. Um, very quickly. I see the reason I bring up the band BA scenario here at the end mm-hmm is because with exception of maybe two candidates that I've ever given this question to over the years, mm-hmm, everybody falls on that part. Right. And that's part of why I like the questions. It gives us an opportunity in every case where you can debug a problem. Sure. Um, but everybody stumbles across that part, except for two candidates who are extremely qualified and, and, you know, very, very senior in their mm-hmm careers. Um, and so you should also remember that, but there there's, there's things here where I, as the interviewer, want to see, I write bugs, everybody writes bugs um, like we're all human. Like I said, I'm, I'm throwing syntax in here that I don't think it's valid. Um, But, uh, you know, we're gonna make mistakes, but how do we think through those mistakes? Right. Mm-hmm and, and just getting more comfortable with how you navigate through those types of problems, I think is, is just where practice makes perfect. Sure. Nothing here stands out to me as, as particularly off or wrong or anything like that. Pretty standard, uh, approach to the problem because force again, and I mentioned this as you through, I didn't ask for performance or quickly to execute.

Eric Kim:

I think, uh, for, for myself, uh, just the small comment is, um, so focused on, uh, the, the end goal, as opposed to the, uh, the journey with problems like this. Uh, I think that's really kind of the, the challenge is kind of, um, uh, really focusing on, um, not more of the syntax or the toolings, cuz I mean like the different data structures, um, and algorithms, uh, like they're just, you know, means to an end. Right. And they're not the actual end all be all like you were saying. So I think, um, that's great feedback. So thank

Scott Ferguson:

you. Absolutely. Absolutely. Anything that, any feedback

Eric Kim:

for me? Uh, honestly it was, um, very helpful and uh, very, uh, it was definitely a lot of fun for sure. Um, a lot it kept me at ease throughout, uh, Definitely, uh, pushing me in the right direction. And, um, definitely showing me, uh, the logic in, uh, a more, uh, friendlier way than, than, um, than necessary. Uh, sometimes, um, it seemed like, uh, I was simply told, uh, the answer, which, you know, not faulting you or anything, but, um, it seemed like, uh, it was kind of, uh, being given instead of like, uh, uh, being kind of like guided towards, which is, you know, definitely helpful. But I guess in hindsight, I would say it would definitely, uh, be okay to kind of have myself or whoever, whomever to struggle a bit more, I guess, uh, just to kind of go through that. You know, phase of frustration to get those aha moments. That's just be my only 2 cents.

Scott Ferguson:

It's a interesting point. And, and one where I'm kind of undecided on because you know, the reason I've developed that habit over the years of just sort of nudging people in the right direction is, um, for me it's candidate experience, right? You want don't want somebody to come away and say like, yeah, the company sucked to interview , um, at the same time, like as the interviewer you need something that's gonna be challenging and you're gonna find the right talent. That's, that's, that's the line that you have to balance and, right, right. Um, I am not in the popular crowd of, of technical interviewers who prefer the, um, uh, the whiteboard. I know a lot of people shy away from it, but mm-hmm, in what would your preference be? Would it be towards being coached into the end solution and to get through a successful, um, point of completion, whether hypothetical or not, or would you prefer that. If we had ended at a point where like it had only solved two or three of the bullets, we didn't solve everything.

Eric Kim:

Right. Um, I, I would definitely say the latter, I think, um, even though I, cuz I think, uh, through those moments of frustration, even if you're not completing, I think I would say having gone through it, it seems like the end goal, isn't the, you know, isn't the, shouldn't be the main focus or the main priority. Um, I, none of this code will be, you know, for prod, right. So it's not like we're gonna, you know, we're trying to make like the Mo most clever algorithm on the spot. It's I guess kind of trying to determine, you know, the thought process and, um, the, the bigger picture overall. So I would say my, my, my opinion would be that, um, even having a more challenging question, uh, that forces the interviewer, uh, or the interviewer, sorry, uh, to struggle and to go through those moments of frustration. Be more insightful ultimately for the interviewer.

Scott Ferguson:

Okay. That's that's valuable. Thank you. Uh, I will say, and just another point of feedback for you, uh, very positive aspect that, you know, one of the things I'm always looking at, um, and a lot of candidates come down to this point is you ask questions or you nudge in certain ways and give feedback in certain ways to see how somebody receives that feedback. Mm-hmm um, and my nudging and prodding in here was, was a bit touching on that. And you were very welcome to that, which for anybody, no matter how senior you are in your career, that's exactly what you want to see in that potential coworker is somebody who, yeah, we can have a conversation and , they're not gonna get, uh, angry at you or something like that. When you, you, you suggest one thing or the other, even if wrong, very receptive to feedback. It's very, mm-hmm. cool. We are about at time one. And so thank you.

Eric Kim:

Thank you so much, Scott

Scott Ferguson:

pleasure getting to meet you.

Don Hansen:

Hey everyone. That was the interview. And I thought it went really well. Um, remember this, I have to cite most people aren't willing to, they're already scared of going to an interview and they're definitely not willing to hop on camera. So seriously, kudos to Eric for doing this. This was phenomenal. And, um, you know, I feel like. I feel like it could almost empathize with Eric. I, I am someone that still gets nervous in interviews, and I think a lot of you can empathize as well, but, you know, I think he did a great job working through those problems. And, you know, this was his first interview. It was really cool to see him grow from this. And we even got to have a conversation, uh, privately afterwards, but I think Eric's gonna do very well with his career, but let me know in the comments below, if you're watching this on video, definitely let me know in the comments. If you're watching it on audio, there's gonna be a link to our discord server. You could just hop in and let me know there or hop to the video, but either way I wanna know what you thought of this. I'm super curious.