JavaScript Interview with a FAANG engineer

Watch someone solve the confusable number problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Confusable number

Interview question

Consider an auction: there are BIDDERS in the audience. Each BIDDER is given a paddle with a unique number (e.g.: 57). At the front, there is an ORGANIZER. When a BIDDER raises their paddle, the ORGANIZER sees it and recognizes the number. For instance, a BIDDER might raise paddle #78, and the ORGANIZER recognizes the number 78. Sometimes, however, a BIDDER accidentally holds the paddle upside down. For instance, a BIDDER with the number 68 holds it upside down, showing the number 89. The ORGANIZER assumes it's 89, which is a mistake. We'll call any number that--when turned upside down--is a different, valid number, a CONFUSABLE number. Write a function that, given a room with 800 BIDDERS, identifies all the confusable numbers.

Interview Feedback

Feedback about Fresh Bear (the interviewee)

Advance this person to the next round?

How were their technical skills?

3/4

How was their problem solving ability?

3/4

What about their communication ability?

3/4

Pros: + Good job making an assumption that the bidders go from 1 to 800 + Good job talking through the problem statement + Good job deciding that 1 is reversible + Good job focusing on digits up front + Good job thinking out loud + Good job clarifying about input/output parameters + Good job identifying leading zero edge case + Good job thinking through more use cases after we clarified about the definition of confusable number + Good job using examples to help understand the problem space + Good job asking about whether we should pursue a more performant solution Things to think about: ~ Missed digit '0', but you did remember to add it later ~ If your question is "this seems simple; am I missing something?", the answer is *probably* "yes" ~ Write down your assumptions (e.g.: number-with-2345-inverted-is-by-definition-not-confusable) ~ When listing confusables between 1 - 20, you missed 18. I wonder if there's an opportunity to improve thoroughness? Things to improve: - Missed the part of the confusable number definition (must be different number) - Initial implementation of isCharsConfusable is incorrect (includes 9?). - Missed the upside-down-is-same-case Verdict: Strong no hire. Didn't think through test cases thoroughly, and the solution is incomplete. Recommendations: * Understand the stages: requirements refinement, algorithm definition, algorithm implementation * Improve requirements refinement: identify MORE test cases

Feedback about Sly Chinchilla (the interviewer)

Would you want to work with this person?

How excited would you be to work with them?

4/4

How good were the questions?

4/4

How helpful was your interviewer in guiding you to the solution(s)?

4/4

Honestly really helpful interview experience. I think they provided a lot of insight on how to do well during the interview process. The feedback about my process was what I was expecting.

Interview Transcript

Sly Chinchilla: Hello, hello, hello.

Fresh Bear: Hey, how are you doing?

Sly Chinchilla: I'm great. Can you hear me okay?

Fresh Bear: Yeah, can you hear me okay?

Sly Chinchilla: Absolutely. This is, um, this is a rare event that both of us have a working AV setup right out of the gate. Wow, that's awesome.

Fresh Bear: Yeah, they don't have like a setup mode. So that's kind of like probably why people mess up but

Sly Chinchilla: Oh yeah yeah, just like I do these, I do a lot of these interviews. And just most of the time something goes wrong, microphone doesn't work, speakers don't work so I'm just like this is great. So um, all right, we've got an hour, I want to make sure your time is well used. This is normally where I would introduce myself. But we're staying anonymous. So I am fine chinchilla for you. And you have been allocated the name fresh bear. So good to meet you fresh bear. Um yeah alright great. So within the hour here's how I like to structure our time, we'll spend a couple minutes learning a little bit about your background to understand your goals. We'll spend about 40 minutes doing a programming interview. And we'll spend about 20 minutes doing a debrief and what we so during the interview, I'll take a lot of notes. And for the debrief, what I'll do is I'll I'll run through my notes as fast as I can. The idea of being that that will give you lots of time to explore which whichever topics you want to in more detail okay?

Fresh Bear: Perfect.

Sly Chinchilla: Okay, cool. And the other thing, you know, just to, you know, big, big picture thing here is I want to make sure you think about in the next hour of your life. That the goal here is for you to get some you know, to have fun, learn a little bit, get some benefit out of it, you know, interviewing, real life interviewing is stressful, you know, you're being judged, you want to get a job and all that I can totally understand. I've been a candidate too. But you know, for the moment, you can sort of put that stress aside, just have fun for next hour okay?

Fresh Bear: Cool. Yeah.

Sly Chinchilla: Cool. All right. So let's learn a little bit about you. Can you help me understand your background? Like, are you a recent grad, you're in school, you're 20 years experience industry, that sort of thing?

Fresh Bear: Um so, I am currently employed at a company. I don't know if it's okay to say which one, but I'm employed at a large enterprise company. And basically, I currently work on the tooling for front end development. So how that started was basically, I started at this company for about, like, about three years ago. And then I was working as like a, basically like a product on the product as a front end developer, kind of using the tools that I'm developing now. So these tools include, like a CLI programme, that is used to basically build front end assets, such as these assets are usually React, and these kinds of plugins to this micro front end architecture that our company has. So So yeah, so basically, right now, I'm focused on front end tooling. And I also, and that includes basically like a CLI that like over, you know, a couple 1000 developers use, and then a CI CD for all of the frontend assets at our company.

Sly Chinchilla: Cool stuff and from a programming from an interviewing perspective. So you've got or just, how long have you been working in the field?

Fresh Bear: Let's say, five years, about five to six.

Sly Chinchilla: And are you in terms of interview practice? Is this like the 10th practice interview you've done? Or the first or what?

Fresh Bear: You're actually my first one, and I haven't interviewed in three years. And the last time I had a coding interview, it went pretty bad, I would say, but it was also because I had like, a week that I realised that I needed to study data structures and algorithms. And I am, so I have a degree in electrical engineering. And I took like, maybe one class in C. And then I was a self taught like PHP developer, web developer. But um, but yeah, I went to school for something completely different. Sure, it was electrical engineering, civil engineering field. So it was helpful. But I basically became a self taught developer after that. And when I graduated, I started working in software. So basically, I didn't ever study data structures and algorithms. And once I realised that's what you needed to do when you're interviewing for these top tier companies. It was a little bit too late and so the interview went poorly. But now, you know, I've studied the last couple, like I mean, I've studied a good amount. Now on these data structures, algorithms, Um, I'll probably I'll probably do a system design interview in the future, too, because I'm interviewing for Google in about a couple of weeks. So they're probably going to ask me system design questions. Because of my experience. Yeah, basically, I'm just trying to prepare for that interview, and also trying to you know, just practice my interviewing, and kind of get used to the interview process. And yeah, you know, I'm trying to land a job at Google.

Sly Chinchilla: Absolutely, no, that's what i'm saying, you know, just you know, so, um, my background, I also do not have a degree in computer science. And I did successfully study and and pass the Google interviews. Okay, you should know it can be done. And there are plenty people who work in Google who do not have computer science degrees, and they were able to learn this stuff. So have hope you know, it's been done. Other people have pulled this off, so you can probably do it. Great. Well, let's, um, let's switch to this interview. So let's first of all, make sure the editor works. Can you see me typing?

Fresh Bear: Yes, I can.

Sly Chinchilla: Cool. Do you want to type something in this to make sure I can see you. Alright, cool. We can see it. Great. Do you have a preferred programming language?

Fresh Bear: JavaScript? It's interest they don't tell us that. But yeah, JavaScript is my preferred programming language.

Sly Chinchilla: Yeah, sure that you see, there's a drop down top right, you can pick JavaScript.

Fresh Bear: Okay, cool. Let's see, ooh, well, I probably won't do TypeScript because that'll just take longer.

Sly Chinchilla: But honestly, it's whatever you're comfortable with really. Cool. Okay, so we've got the editor, and I just want to point out a couple of things. So this editor will let you run your code. Okay, now, and actually, let me just, I'm just hitting the run button right now proving myself because I actually haven't used the JavaScript. Okay, so the javascript interpreter does work. And, you know, so you're preparing to interview Google, I believe Google does not use a live interpreter. So

Fresh Bear: So I don't know if it's better to just use a text editor then.

Sly Chinchilla: Yeah, well, I mean, I don't know let's let's use the JavaScript editor just to get nice syntax highlighting. Let's be easier for you to read it. But it is true that Google the Google situation wouldn't actually have you running your code. So if you want to focus this practice interview, to like, faithfully replicate Google then let's not use that magic Run button. Okay.

Fresh Bear: Maybe Okay, yeah, we won't use the magic Run button. I'll kind of just go through the code in line by line. And yeah,

Sly Chinchilla: This is, this is I will say, unfortunately, gonna force us into doing that line by line mental evaluation. And personally, I love the live editor. I think it's awesome. And I think it's kind of silly. But you know, I think there's a fair point here about replicating the Google interview. So with that said, I am going to copy paste in a question for you. And let's do this thing, okay. And I'll keep an eye on time, so I'll call time. So I'm gonna read this out loud to you. And then we'll take it from there. And I'm reading it out loud because that you know, in a real interview, the interviewer would actually say it out loud. So, consider an auction. There are bidders in the audience. Each bidder is given a paddle and a unique number for instance, 57. At the front, there's an organiser. When a bidder raises their paddles, the organiser sees it and recognises the number for instance, a bidder right mate might raise title 78, and the organiser recognises the number 78. Sometimes a bidder accidentally holds the paddle upside up. For instance, in bidder with the number 68, hold it upside down, showing the number 89. The organiser says it's an 89, which is a mistake, we'll call any number that when turned upside down is a different valid number, a confusable number. Can you write a function given a room with 800 bidders identifies all the confusable numbers.

Fresh Bear: Okay, so that is very interesting problem. So I guess we could start off by let me let me see. So basically, we're gonna say that there's a room with 800 bidders, and these bidders are from it starting from one?

Sly Chinchilla: Sure we can start with one that sounds reasonable.

Fresh Bear: Okay, so they start from one to 800. Right? So one to 800. And then and so basically, when you have a number that's turned upside down, so might raise paddle 78. So for instance, a bidder might raise paddle 78 and organiser recognise a number 78. Okay, so that's the normal case. But in on the opposite side, basically, they flipped a number. Okay, so I see it's actually literally like a mirror. It's not like If for some reason when I first saw it was, I thought that maybe they just reversed it. But so there's actually so there's only a few numbers that are completely mirrored, right? So is it safe to assume that we can basically kind of look at 23456789? Right, and let's see if the number can be mirrored. So one is, I'm gonna assume, is it it's just gonna be a straight line, right?

Sly Chinchilla: Uh Sure.

Fresh Bear: So that one can be that one can be reversible, right?

Sly Chinchilla: Agreed yes.

Fresh Bear: Okay, one can be reversible. And then two, I don't think if you flip two you can't really confuse it, right?

Sly Chinchilla: Yes, I agree with you that two upside down is not a valid number.

Fresh Bear: Okay, so two is not valid number three. If you flip upside down, I think you can reverse that right?

Sly Chinchilla: Well, what if you got paper in front of you write down a three turn upside down? Tell me what you think.

Fresh Bear: Let me see. Point. Three, upside down. It is not, I don't think it's a confusable number.

Sly Chinchilla: I agree.

Fresh Bear: Four, I also don't think is a computable number. But I could just double check on my end. Because it looks like an H. So I don't think same with five. Yeah, I would say five is not confusable. Six, could be a nine we saw that in the example. Can seventh be like a one. Or no?

Sly Chinchilla: Oh, I think let's let's say for this example, the seven cannot be turned into it, I can sort of see how you might think that. But let's agree that seven is not a valid number upside down.

Fresh Bear: Okay, and then we have that nine could be six as well. All right, so. So these are all the numbers that you can kind of see that are possibly confusable. So then I guess, like, just so given a room with 800 bidders, right, identify all confusable numbers? I mean, I would say that this is a like, it's a pretty clear, pretty clear question, right? Like, the I'm trying to think of something that I could be missing. But do you think there's anything that I'm missing?

Sly Chinchilla: Well, why don't we explore the space a little bit? You know, what, what are your initial thoughts and how you might solve this problem?

Fresh Bear: I would say that we could, basically so that the simplest, well, my first intuition says, like, let's list out all the numbers, right, from one to 800. So, and then we basically see which ones are which one contain these characters? And if any of the numbers that contain those characters have a have a number in it, that is confusable, then or no, if it has any number that's not confusable in it, then it could, it's not gonna be confusable, because then the bidder would know that it's confusable. So is it safe to assume that if any of the numbers like 2345 that are not confusable? Is it safe to assume that the bidder if he sees those numbers flipped upside down? He'll be like he'll say, Sir, your things upside down?

Sly Chinchilla: Yes, I agree with you.

Fresh Bear: Okay. Okay. So, yeah, so I would say, you know, we can kind of start kind of going through, maybe we can kind of work through an example of like, a smaller subset of numbers. So we can kind of go like, let's say, one, two. Okay. I mean, one to 10. Oh, and then we also forgotten zero. Actually, zero flipped upside down would also be zero. So that one would be. So let's say, if we get yeah, what would be the inputs of this with it with the number just be that N. Times by the number of bidders.

Sly Chinchilla: I think that's up to you, you know, you could design this a bunch of different ways. The problem doesn't the way the problem is specified doesn't really doesn't require any particular implementation for how you want to specify that input.

Fresh Bear: Okay, so I would say let's, let's say that the function takes in one argument, N which is the number of bidders. I'm wondering, do you see this syntax highlighting or no or sorry, not syntax, but when I highlighted a number?

Sly Chinchilla: Highlight a number and I'll tell you if I could see it.

Fresh Bear: I'm highlighting something right now.

Sly Chinchilla: I do not see any highlighted unfortunately.

Fresh Bear: Oh okay. Nah that's okay, I guess. But do you see my you don't see my cursor either huh?

Sly Chinchilla: You know, I guess it's annoying, too bad I don't like here type something and then we'll I mean, I think I'll be able to see when you type. But yeah, yeah, when you type it shows up but like, I can't see the blinking cursor unfortunately.

Fresh Bear: Okay, so so yeah, unfortunately Yeah, I was like highlighting stuff but that's good to know. So let's say that let's say that basically we're basically writing a function and the function takes in one number N so like, basically the function will be like, identifies all confusable numbers. So let's say you want to like return the numbers in in an array, or should we

Sly Chinchilla: I'd say that's fine honestly, you can interpret identify as you want, return them, print them out, that's all fine.

Fresh Bear: Okay, so let's just for the sake of simplicity, let's just do it in an array. Or yeah, let's do it in an array, we could easily switch that, I think. So then we'll say, you know, const, all can confusable numbers, right. And that takes n, which is the number of bidders. So we could do num bidders. And I'm gonna assume that, you know, that number is not going to change, like, once you get the number of bidders, everybody's gonna stay in that room.

Sly Chinchilla: That's a very reasonable assumption.

Fresh Bear: Okay, so that's, that's kind of like what I think the function outline will look like. But maybe let's kind of go through like an example. So let's say that the input would be 10. Right? Then in the array, the output would be one is, so one is confusable. Right? 234567, 5 wouldn't be six would be. And then seven, seven would be and then eight, and nine, and 10. If you flip, if you flip 10, what happens? So then you get 01? So in this case, with 10, would that be considered a confusable number?

Sly Chinchilla: So I think we can agree that if a number starts with the leading zero, it is invalid, and thus 10 is not a confusable number.

Fresh Bear: Okay, so if it starts with a leading zero, then it's not. So basically, if it starts with a leading zero, then it's not a confusable number. And would we agree that this list right here would be for the input equals 10? Or N equals 10? Whatever?

Sly Chinchilla: Sure, well, we can explore that in a little more detail. Why don't you walk through each one of those, and let's make sure that makes sense.

Fresh Bear: Okay, so one, if you flip upside down, it could be confused as one, six if it flips upside down.

Sly Chinchilla: Can you do me a favor? Can you look at the definition of confusable again?

Fresh Bear: Yeah, let's see, where's confusable? When Oh, turned upside down is a different number. Okay. So one actually wouldn't be a confusable number, because if you flip it, it's going to be the same thing. And then the same thing with eight actually. But the thing is, is that if one is in a different place though, then because you know, like, let's say we have one, two, so 111 would not be confusable. But one to one. Yeah, so that wouldn't be confusable. But what about 181? That wouldn't be confusable. Because when you flip it, it is it's the same number. But let's say you have 118 or 1181. Now, when you flip that, you're actually gonna get 1811. So, I think this would be technically a confusable number, right? 1101.

Sly Chinchilla: Yes agreed.

Fresh Bear: So the only time that it cannot be confusable is if a number is flipped, like if you flip it into the same thing. And if it's right in the middle, like so basically, has to be right in the middle. Or there's a number like this, where if you flip it, there's basically if it's all of these numbers, then it's like a, it's a kind of like a palindrome. Okay, so in this case, eight wouldn't be, eight wouldn't be confusable. So it's only going to be six and nine. Great. Okay, so for the input 10. So let's go for an input. Let's see, do you think 20 would be a good one? So in this case, I think it would be everything from 10. Right? So we could probably just do six and nine. And then 10 is also is not going to be confusable. Because when you have a leading zero, 11 is not confusable because it's the same thing. 12 is not confusable. I'm just gonna start writing these out 12 to 14 is not 14 is not 15 is not 16, 16 upside down, would be 91. So I would say 16 is one of them so 16. What about 17? is not 18 is not 19 is going to be 61. And then what about 20? 20 is not. Okay. Okay, so not gonna lie, that seems like a hard problem.

Sly Chinchilla: Okay great so lying would be bad. So yeah, that's cool. Cool. Cool.

Fresh Bear: Okay, so for now, so we know, okay, one thing that we kind of can figure out is that, you know, if, uh, you know, it's gonna be inclusive. So 20 is going to include everything from 10 right? Okay, let's maybe I'll extend it one more time to 30. And then let me just see, so we know it's gonna be all of these, right? And then we're gonna see 20 is not confusable. 21 is not confusable with 22 is not confusabl, 23 is not confusable. 24, 25, 26, 27. So actually, as long as there's one, as long as there's one number. So all the way to 30, there's gonna be no more because if there is one non computable number, like so, if a two is in there, because so one is, is confusable. Right? So, that means that since one is confusable, that if if all numbers are possibly so basically, if it's one not, or 1689 or zero, then we know that it's possible that for for it to be confusable. So but but since 20, since input is 20 right? All the numbers between 20 and 30. All the numbers between 20 and 30 are not going to have anything and same with 40 and 50 and 60. No, then once we get to 60, right. So this is actually inputs 30, 20 to I would say 60. Right? Yeah. Up to 60 inputs 20 to 60 is going to be this answer.

Sly Chinchilla: Yep.

Fresh Bear: So then input between six so lets just say input 60. Let's just say input 70 because then we'll get all those in there to the output will start to be so it'll be everything from the previous one. Then we'll get you know 60, 61 could be 19. So 61, 62 no 63 64 65, 66 can be 99. So 66. 66 67 68 could be 89. So it'd be 68. And then 69. So how many did we get? We got 1234 here. Right? Alright. 70 onwards, we wouldn't get any. So let's just say 100. I'm still not quite seeing I mean, I'm sort of seeing a pattern. So we have, we need to know. So okay, one thing we can do is, one thing we can try is, let's say we take all the numbers, if the number, we can kind of turn it into a string. And if so, let's say here, let me just write this out. Because I know you can't see what I'm highlighting. So we can basically go from 22. Right? We know that each one of these digits 22, could be you know, it's going to be two is not, two is not confusable. confusable. So we just skip so we move on. But anytime that all the characters all the characters are confusable. Anytime all the characters are confusable, then it a confusable number, right? But, yeah, so I would say, okay, that'll probably get us most of it use cases. Right? Because, you know, like, we, like, I unintentionally got zero or 10 earlier. So, but we know that 10 is not confusable? Because you would have a leading zero. So yeah, let's see, let's see if that this kind of algorithm will work for this. So like, for all characters are confusable, let's say our input a 70. Right, and then our input is 70. So basically, let's take a you know, so. One, you know, we have our base cases of like, one to one to 10, you know, those ones are gonna be those ones are going to be basically like our sort of like base case, because one alone is, is not confusable. And eight alone is not confusable. But the rest of them are so like 1, 6, 9 and zero, or no one, six, and nine. I guess this is kind of like my naive solution of saying like, all characters are confusable. If we basically we break down each we break down each number into its like characters. And if the characters if any of them are included as confusable numbers, then we we do not print that number. Or if they are all confusable numbers, then we basically print that number, right? And so something like that would, you know, so we basically have to iterate you know, n is going to be 100. Right? So we have to iterate over 100 numbers. So that's going to be at least big O of n. And we wouldn't use any extra space there but then we would have those, it's going to be kind of complex, it might be a little bit complicated to get all those edge cases. So like, like 10 would be an edge case you know, so I don't know maybe it's maybe we got to break it down just a little bit further and say is a specific number confusable right? So like does, you know if you know we basically take you know a number right? So is it is number confusable right? And then we gonna do like 100. Is that is this gonna be this is going to be true. No, sorry, false, because it's going to be 001.

Sly Chinchilla: I agree.

Fresh Bear: Okay. So I'm wondering, do you think we could do better than an O of n solution? And it's not only just O of N, we also have to iterate through each one of the characters? So it's a little bit more than O of N. But yeah, I would say it's, I would still, like justify that as O of n, because we're, we're just iterating through each one of these. But then, unless we get like, if we get a really large number, like an input of like, 100,000. You know, it doesn't grow linearly with the N. Sorry, it does grow linearly with n. But the number of characters doesn't grow linearly with N. Is it kind of safe to assume that, you know, parsing, each one of these characters is kind of negligible compared to parsing throughout the whole array?

Sly Chinchilla: That's a reasonable assumption.

Fresh Bear: Okay. So yeah, I would say that that is a kind of an O of Nsolution. I'm wondering if you think we could do better than that.

Sly Chinchilla: There is actually, I don't mean, I don't mean to be coy about this, there is there is a solution that's more performance O of N. But I think for the sake of time, I think the more interesting to explore the current solution that you put together.

Fresh Bear: Okay. Okay, so let's go ahead, and we'll go ahead and kind of implement this. So we can say that, we'll go ahead and create this, all confusable numbers, and we're going to basically return an array. So let's just call it the result. Right?and then let's, let's create like a little helper class, called like, is number confusable. Or not helper class, but a helper function is number confusable. Right. And that's just going to be a function that, it's gonna be a function that doesn't have the auto. So it's gonna be a function that basically takes in a number. No we don't want to use, we'll just use a random number. Or N because number is actually the, it's already taken. So and then in here, we're basically what we're going to do is we're going to basically break down we're going to take this and turn this number to a string. So we'll, we're going to assume that and this is just going to be like a string, or sorry, a number an integer. So then, we'll say that this is going to be a integer coming in, and the first thing we want to do is we're going to want to iterate we're going to basically turn it into a string, so we want to go ahead and say number string, and then we'll just do n to string all right.

Sly Chinchilla: Okay.

Fresh Bear: And then we're basically going to say for each one of these during dot length, i plus plus. Okay, so we're gonna iterate through each one of these guys and we're basically going to say, we're gonna look is we're going to basically see if we're going to basically see if the, if any of the characters are one of our one of the confusable numbers. So like, if if we can also make a little helper function like we could be like, you know, if is char confusable. Right we could do that. You know, and then we'll just basically do number string of I. Did I not close that? Okay. So, you know, basically and if it is, is character confusable then then basically, you know, we're going to go ahead and return true because we're basically saying, you know, is the number confusable because if any of the characters are confusable then if there is not confusable it's actually if care is not confusable because then we're going to say that the number is confusable. Sorry, what is it? What is this is char confusable, it's basically any number it's it's 2, 3, 4, 5, 7 or 8 or 0. So let's just go ahead and go ahead and put this over here const is char confusable and it's just going to be called character. Shit keep messing that up and then we're gonna do c. Lets just make a const array of you know, it's going to be chars. We could probably just do a set actually but because then we won't have to have that lookup time but let's go ahead and the char is that the non confusable char are two three if I just do 2, 3, 4, 5, 6 no six is 5, 6, 7. 7 and 9 okay. And then if any of these so basically if c or if chars dot includes c. We're going to go ahead and return it's going to return so this is char confusable so it's actually this should be the opposite this should be it should be the is care not confusable because so we want to do one but we were saying that one if you flip it it's fine, but there's some weird use cases there. 1, 2, 3, 4, 5. One 6, 7. Okay we have 1, 6 and 9. Actually, the only two are six and nine. So if it is then we can return true here. Number string okay. So if the char is confusable then we can go ahead and return true because if we find oh shoot, so no we didn't otherwise return false. So good. So we're gonna go ahead and say is number confusable. If any of the numbers in here are confusable then we're gonna go ahead and, or if they're not confusable, then we're basically going to say that so this is confusable. So sorry, I'm getting a little bit confused, because we're talking about confusable. But, uh, but yeah, so basically is the number confusable. If it is, it is when you have when all of the characters are going to be when all the characters are confusable. Or, but actually it needs to be. So the thing is, it's the opposite of what you wanted. Like, we want to basically check if it has any of the regular numbers in there. So 2, 3, 4, 5 or 7. So is not mirrored or is not confusable. So let's say 2,3,4,5,7. 7,8,9 right? And then if the char includes not, then we're gonna do that. So then is not confusable. So basically, if any of them are not confusable, then we're going to return false. Otherwise, we want to return true. Because Because yeah, so yeah, cuz we want to basically, because we know if any of these numbers that go through it are. If any of these numbers are normal numbers like that are not mirrorable, then we know that the the bidder won't be confused. And yeah, and then so let's say like, right now, I know that this is not accounting for the edge cases right now. But I'm gonna, I'm gonna just go ahead and go to the next part, just because

Sly Chinchilla: Well lets umm let's, let's what we wanna do, we're kind of at time, I want to ask you about one possible value, and then I think we shift into debrief if that's okay?

Fresh Bear: Okay.

Sly Chinchilla: I'll just read the number of above here. Okay. So, tell me about the number 69. Is 69 a confusable number?

Fresh Bear: By the definition 96.

Sly Chinchilla: Is that right?

Fresh Bear: No, I would say because you flip it, and you would flip it, and it would be the same number, so it wouldn't be confusable.

Sly Chinchilla: Agreed and looking at your implementation. What would your implementation return if we asked you to tell us if 69 is confusable?

Fresh Bear: Right now, it would say that right now, it would basically say that. Yeah, 69 is a confusable number, because it doesn't contain any, it doesn't contain any numbers that aren't, like, confusable.

Sly Chinchilla: Right, right. So okay, cool. Let's let me write one more thing down here. It's just my own notes. Alright great so let's, let's shift to we got about 17 minutes, let's use that to do a debrief okay. So okay, so first of all, thank you very much. I know this is like, we were going crazy and fun and stressful and all that. And it's, it's taxing to go through this. So I appreciate you giving a shot. Okay, so what I'm going to do is I'm going to read through my notes kind of rapid fire, and then we can dig into whichever ones you think are more interesting, okay? And I want to make sure we focus on like concrete stuff, like do you understand what you're doing well? Do you understand what things you should work on in the future okay?.

Fresh Bear: Yeah.

Sly Chinchilla: Okay. So let me run through this. Alright. First of all, upfront. You did a good job, clarifying an assumption about whether or not we're looking at like, like, what the numbers of bidders were. And so clarifying that we're going from one to 800. I appreciate you bringing that up. That's good. That this question is deliberately ambiguously specified. So it's helpful to clarify that. I appreciate you talking through the problem statement. It's a really good technique to sort of restate the problem, in your own words to make sure you've understood it. I appreciate your conversation about your discussion of whether or not the digit one is reversible. There's some subtleties to that. Basically, a lot of candidates will sort of observe that depending on how you write one, it may or may not be reversible. So I appreciate you bringing that up. And similarly, the job focusing on digits upfront. Digits are really the sort of core aspect of this question. And it's great that you went right to that, so well done. You did when you're originally going through the list of digits, you sort of forgot about zero? You did you realise it later, and you added it back in. Normally, I wouldn't care that there is a bit there's a bit of a pattern here and I pointed out that that plays into though, there's a certain point in your implantation, where you said, Hey, this seems pretty simple. Am I missing something? If you ever have to ask, this seems simple. Am I missing something? The answer is probably gonna be yes. It's very rare that a question is deliberately simple. I mean, it's happened, it has happened, right? So I don't want to be like totally, you know, 100% on this, but like, yeah, no interview question is fundamentally a simple one. Mainly those aren't fun. They're like, they're not I don't think they're very interesting as an interviewer because you don't really get to explore things. And I also as a candidate I don't think they're fun either. So just so you know, if you're like, oh, that seems simple. I got it. Like, take a breath. Take a fresh look. Yeah, there's something more complex. Like, don't get me wrong, like if a candidate said that. And then we're like, huh, that seems simple. I'm sure I'm missing something I'm not gonna knock, it wouldn't be a point against them, like, I get that, okay. Um, the one thing you started doing, and I encourage you to do more is write down your assumptions. So as you're talking with me, clarifying your understanding the problem, you got an editor right in front of you write down your assumptions, you did that for some things, but you didn't do it rigorously. So it's good since I know you can do it. So I'm just encouraging you to do it more. I think you did a great job thinking out loud. There, I don't think there was even a single moment where I had to say, hey, like one of those awkward silences where I wonder what is the candidate? You are really good, good pacing, good enunciation? I really appreciate it. I appreciate that. You asked about input output parameters. That's really great. You know, you said a certain point like, hey, it was getting the input. Like, we return an array. Is that cool? Yeah, that's great. It's nice you brought that up. You know, the failure mode with that is candidates who not only don't bring it up, but then like, when they actually get to writing their code, they just haven't thought it through, you know? And then they're like, oh, man, like, Oh, right. I gotta return something. Oh, crap. I didn't, you know, I forgot to account for that, anyways you did it that's great. You also identified one of the major edge cases, which is numbers that invert and end up with leading zeros. This question is full of edge cases. No candidate has gotten all of them. Some candidates get some of them. And I appreciate that you notice that by the way so well done. You, you kind of missed the definition of the confusable number, right? You missed that bit about it being didn't remember when I asked you about like, is 69 confusable? Or I even I asked you like is 11 confusable. And you're like, oh, and you know, so there's like that that's subtle, but it's important, like the definition of confusable? It's, you know, it's, it's written in the question very deliberately. You know, like, each one of the sections is a different valid number, right, so it's important to get those. Let's see if there's actually a related note, one time when you're walking through test cases, you listed out the numbers from like, one to 20.

Fresh Bear: Yeah

Sly Chinchilla: I know again, this seems little but you actually you missed one, which is 18. The reason I mentioned this is I noticed a certain lack of thoroughness on in some cases. Now fairness in any given one, in one instance, there's only one I wouldn't care and whatever people say all the times, I feel like there were enough instances where you were like listing things out. Where you were you like miss examples. That suggests to me that you could, you could probably spend more time on that, like developing more self discipline for like when you so like, if you're anytime you're enumerating a thing, like, that's definitely the time to like, really be thorough about it. And again, like each individual instance, I don't really care, but it's the aggregate number of them that ends up being like a bit of a red flag for candidates. Furthermore, I was really pleased you, you did get to a certain point where you wanted to use examples to think it through and you think you're like, Okay, let me look at the ones one to 10 one to 20, 1 to 50. That was really cool. Like it was it was nice to witness. You were thinking things through. I think it's a really nice technique. I appreciate it. I really appreciate a certain point in your solution where like you had an idea of a solution and you stopped you asked me like okay. Should I, the candidate keep going with this? Or if you want to more performance? I think it's great that you ask that question. I love it. I love that you gave me the opportunity to say, yes, there's one more performant one. But no, let's, let's continue this current one. Like, that's awesome. Like, it's great that you signalled with like an awareness of performance as an issue. But you also didn't like you gave me the interviewer an opportunity to kind of set the direction on where to go. And I think that's great. And actually, very few candidates do that. So I think it's wonderful. I'm the only one here laughing because we just talked about this, but the I think it was that was that case about six nine, like sort of misunderstanding what what, what, what turning something upside down looks like. We already talked about it. So this gets us to the end. So I'm in a Google interview, you know, the the interviewer is going to give you a score between strong no hire and strong hire, right, so the ratings are strong hire a weak no hire weak, higher and strong, right? If I were giving a rating, I would probably give you a strong no hire. Let me explain why I want to make sure that you you leave this interview with your self esteem intact you know okay, but you should still get a pretty

Fresh Bear: Yeah no this is why I'm doing this because yeah, I knew I'm gonna fail.

Sly Chinchilla: Yeah. Ah you know, failure is just an opportunity to get better the next time, right? But here's why. Right, ultimately, ultimately, you didn't finish the solution. That's really why right. And there's a bunch of reasons why that happened. That didn't happen. And that's what you and I are working on together today. You know, it's a basic precondition. Right? Now, there's there is like a slight exception to that which is if I have a candidate who just clearly has a very robust solution in their head. And like, it's not the code isn't finished, but like it's close to finish. And it's like very, very clear to me that like, yeah, 30 more seconds of this would have been done, that I might still still go the hire recommendation. But most of the time. The candidate doesn't have a working solution. By the end, like, no it's just gonna be a strong no hire. There's almost no exception to that. So let me stop myself there. Because I want to make sure you get some real actual feedback here. We got about 10 minutes. What aspects would you like to talk more about?

Fresh Bear: Um, I don't know, I just honestly want to figure out what I could do better. Which, like, where was I inefficient, I understand the need to be more thorough, which I can work on. How can I practice? So I mean, yeah, I'll probably sign up for another interview. Like or two

Sly Chinchilla: Yeah by all means, I mean, I'm sure interviewing.io will be happy to take your money. But sure let's, let's give you some concrete suggestions. Okay. All right. First of all, I actually think that there's a lot to be very optimistic about. You're a great communicator, you clearly are comfortable in JavaScript. And I don't think and clearly these kinds of problems is algorithmic problems, you seem to be sort of intellectually comfortable with them, I didn't see you fundamentally wrestling with like, with them seeming for it. So these are really great, this is how they should be offered. So let me give you some concrete suggestions here, okay. One is I want you to think of the interview. In a more structured fashion. Think of it as couple first stages interviewer presents question. Next stage is candidate refines their understanding of the requirements, we'll talk about what the next stage is candidate comes up with a design algorithm for the solution. And then the last stages can implements that. So the more you think about it as a structured sequence of stages, the more you'll focus in on each one of those stages and get better at them. What I have observed with you and with other candidates who tend to underperform is the stages kind of overlap each other too much they bleed into each other. And as a result on if you're new, the way you use your own time becomes less efficient. So one thing I want you to do is really start thinking about this as the as the structure seconds, where you can, where you can control is refined requirements, present and figure out an algorithm that will work then implement it. The more you can do those 3 things in a structured way. Now let's talk in more detail, refining requirements. The number one thing you can do to improve your understanding is enumerate test cases.

Fresh Bear: Okay so one was interview presents questions two is refined, refined understanding. Okay.

Sly Chinchilla: I'm gunna provide notes for those two here so I'm writing

Fresh Bear: Oh okay okay.

Sly Chinchilla: You will get a very thorough notes from me, don't you worry.

Fresh Bear: Okay, cool.

Sly Chinchilla: Algorithm definition. So let's talk about requirements requirements. Now one thing you need to do is go through more test cases, enumerate them, read them out, talk them through and understand them. So for instance, you actually did this a little bit in a way that other candidates have not actually really pleased. You initially wrote out numbers, you remember you did like zeros, like one to 10. And you wrote out like, you know, it was like 168, or nine. And I actually put you push back on this will tell me more about 1. Then you said ohh Actually yeah it's not one so it's actually and that thats and actually very few candidates do that. And that was that those are cool. And that was overdue for me as an interviewer to see that you had a numerator case. And that was our opportunity for us to think it through it in a little more detail. So my recommendation is to do more of that. Right. I think, if you give a couple more minutes, you know kind of challenging yourself this list a bunch of numbers, if I mean, it's not too hard to say, okay, one 800? What are some numbers that are interesting? Well, you could, you could start throwing them out, just like do it a little bit more, and force yourself to do it and that will absolutely help you gain more clarity about your solution. Okay, next thing is the algorithm definition, I think that, um, I see this in a lot of candidates, you had an idea in your head, roughly, you're like in the loop from 800, I'm gonna look at each one and kind of figure out if each one is, you know, confusable. But I think if you apply a little bit more rigour at this stage, in this case, like write it out on the pseudocode form, or comments or something, like write out the algorithm that you plan, you're gonna help yourself a lot, you know, so help yourself think it through, you're gonna help me the interviewer understand your thinking and give both of us a roadmap for what implementation is going to look like and you're not immediately seeing more edge cases, as soon as you put together that algorithm and look at it, the edge cases will present themselves to you much more rapidly. Now comes to implementation. But think your javascript, you write reasonably quickly, you're clearly comfortable in the language. I think you've tripped yourself up a little bit on like some of those like, you know, not to not, not to the not to the not to the sort of not the practices the, the logic behind this solution always ends up being a little bit thorny. But I think that was one of the things if you write out your algorithm in pseudocode comments, then you sort of copy paste that and turn that into real code. And if your work is you're working off a template of your comments, you will write code more efficiently. Right, if you do those things, you are likely to overall perform more efficiently and end up with working solutions by the time time runs out.

Fresh Bear: Okay. Sweet, okay. That's, that's really helpful. I think this is honestly a really good, I'm really happy I did this actually.

Sly Chinchilla: Cool makes me happy too, I want to make sure you get some value out of this thing.

Fresh Bear: Yeah, it's a little demoralising. That, you know, I did so bad. But I mean, in my opinion, I did pretty like

Sly Chinchilla: Right I mean we can explore this a little bit because I don't you know, I don't want you to come out of this. And like, you get home end of the day. And you're like, ah, that's sucked you know like, okay. First of all don't beat yourself up.

Fresh Bear: I got exactly what I wanted so

Sly Chinchilla: Yeah, yeah. You're you don't have a CS degree but I don't have a CS degree either. Right. That's what you practice for you done things well. And you have all the aptitude. So this is really mostly about practice and self discipline, more than than the inner belt, like, there's just some fundamental CS a skill that I don't have. But that's not what I saw here. What I saw is all you have to do there, you just have to practice. And I think you're gonna be really good.

Fresh Bear: Yeah, so I have been practising on leetcode. But and I've been kind of going on the, like, blind for 75 or something. And then, yeah, I mean, but I definitely probably need more rigour on like, the actual process.

Sly Chinchilla: Yeah, well, I'd definitely code on HackerRank too. And I do think they're good practice, but um, they are not the same as practising an interview with a real interviewer. They just they really aren't, that don't have the same quality, the same kind of communication patterns. I also think that the examples on leetcode and hacker rank, are almost too perfect. You know, they're not like, I try to make these, I ask these interview questions are a little bit messy with a bunch of weird edge cases to them. And I found that the questions on leetcode and hacker rank are all too clean they're like these beautiful textbook questions and they're actually not quite what you get asked in a real interview.

Fresh Bear: Is this more of like a phone screening question, or would this be or like interview or would this kind of just be representative of like the onsite interview?

Sly Chinchilla: So this is definitely onsite interview. This is way too complicated for a phone screen question way, way, way too complicated. Phone screen questions are gonna be a hell of a lot easier.

Fresh Bear: I know we have like 15 second flap that's like, cut you off. I wonder. Yeah, like I have basically like three more weeks. Does it end right at 5?

Sly Chinchilla: You know what, I'm happy to run over for you, it's no problem, buddy.

Fresh Bear: Okay. Thank you so much.

Sly Chinchilla: Of course.

Fresh Bear: Um, Yeah, so I'm wondering, like, I have about three weeks until my like, phone screening interview, and then you know, I'm definitely going to drag it out, like as much as I can before the actual interview. Like, because also I have like a tonne of stuff at work I need to do to so it helps out with that. I'm just wondering, like, what's like the, how can I? Honestly, I think this was really helpful. I might do one of these like a week. But also, I think, what do you think is like the best preparation like, I could do? Like, you think I can? Like, do you think I should just basically kind of go through problems as if they're as if they're like, interview actual interviews and kind of time myself and then, you know, break it down into those four categories you're talking about? Like, the presenting the refining the algorithm, so you're saying is presenting, refining and an algorithm implementation? And then analysis or what was the

Sly Chinchilla: Requirements. I mean, the interviewer asked question, the first thing you do is, is narrow down what requirements are the next thing is design a solution. And then implement the solution? So design

Fresh Bear: Okay so design solution, and then implement a solution? And then it's in the design where you want to kind of like, see, are we on the same page? If this is like the optimal, like the, the solution we kind of want to go through? But you said you appreciated that?

Sly Chinchilla: Absolutely. Yes. Well specifically about Google, I can't speak for other companies. The goal, the google interviewer is most interested in you coming up with a working solution, not the best solution, but it's much if you're going with the best solution. That's awesome. By all means, but like, I don't know if you've heard the phrase, don't let the perfect be the enemy of the good. And that is definitely the philosophy of the Google interview. So like, the much more interesting cans candidate come up with something that solves the problem. Oh, good. They did it great. Lets hire him or oh, they did it. And then we had five minutes leftover. And we, we both theorise about like, what a better solution would've been. Or a very, very rare case, oh my god, again, I came up with incredibly important solution up front. That's very rare. And, you know, I see, but I want to answer your question related, like you got three weeks, what you want to do. My recommendation is I mean live your own life, do your job, you know, then get through your day, then practice interviews as much as you can, as much as like, you both logistically can and as much as you emotionally can, like, this is you know, a lot of mental stress to go through to do this, you know, so if you do one a week, that's fine. Do one a day that's, you know, that's even better, you know, just don't don't kill yourself. Take care of yourself, you know, like they before the interview, the actual interview, like sleep, well have a good breakfast, that kind of thing. You know, you got to always remember when you get to that final lap, like, don't try to cram it and just relax. Yeah, relaxation will help you perform better than anything else. And yeah, my recommendation is trying to try to focus on building the self discipline around understanding the stages of the interview, I think you're gonna help yourself a lot.

Fresh Bear: Okay, you think timing myself, during like, because I don't feel like there's still a lot of stuff I need to learn on the leetcode side. You think kind of just going through the structure, because a lot of the times I'll run into a problem like, what was the problem I was reading? Like the course schedule, but like, there's like three different ways. Like, there's so many different ways to implement it, you know, and then I kind of get stuck on like, trying to understand like, okay, what is topological sort? Or what, you know, like, why would I do to depth first search versus breadth first search? Or like, like, do you think it's better to really spend a lot of time on each question and understand each question like really thoroughly? Or is it kind of better to just treat each question as if it's an interview? And kind of go through the structure and then, you know, see how I can go through that.

Sly Chinchilla: I think breadth is better than depth.

Fresh Bear: Breadth meaning?

Sly Chinchilla: Do a wide variety of problems. I think it's actually a better preparation. You're doing a Google interview, they're gonna do five interviews for you. Yeah, four or five, whatever they do these days, it's just just going to be a wide range of stuff. So the better preparation is to prepare on a wide range of training drills.

Fresh Bear: Okay, and one of the so, should I treat each one of those kind of like, an interview in itself?

Sly Chinchilla: Yeah.

Fresh Bear: Yeah. Okay. Okay All right. Well, thank you so much for the extra time.

Sly Chinchilla: Yeah, of course no problem, best of luck. I'll see you on the internet.

Fresh Bear: Yeah. I mean, there's no way I can like request, like a specific person.

Sly Chinchilla: Oh, yeah, I'm flattered. You're the first candidate who asked for that. Well, I'll tell you what, there is i'll tell you what i'll do. When I click an interview, when I do the feedback, there is a there's a field that says, do you want to share contact info with candidate? I will say yes, and you can say yes, and then you'll have my contact info. And then you're welcome to follow up if you'd like to. Okay.

Fresh Bear: Okay, thank you.

Sly Chinchilla: All right. No problem. I'm gonna send the notes in 30 seconds. I'll see you around. Okay.

Fresh Bear: Thank you so much.

Sly Chinchilla: Of course. Cheers.