Curious about what a mock technical interview could look like for an aspiring JavaScript developer? I invited on Matt (with an extensive background interviewing junior developers and also prepping them for interviews) to conduct the interview with Brian who is aiming for his first software engineering job. Matt also shared tons of great feedback for Brian at the end that you may find relatable for your own interviews. Hopefully, this can give you a glimpse into a common type of interview you may encounter when trying to land your first job.
Matt Oates (interviewer):
Linkedin - https://www.linkedin.com/in/maoates
Website - https://coachmatt.io
Youtube - https://www.youtube.com/channel/UCrPusfUgx-5dm1WDoTv_HRA
Brian Lam (interviewee):
Linkedin - https://www.linkedin.com/in/brian-lam-software-developer
---------------------------------------------------
🤝 Join our junior friendly developer community:
https://discord.gg/donthedeveloper
❤️ If you find my content helpful, please consider supporting me on Patreon and get access to additional perks. Every little contribution helps me continue to do this full-time.
https://www.patreon.com/donthedeveloper
Curious about what a mock technical interview could look like for an aspiring JavaScript developer? I invited on Matt (with an extensive background interviewing junior developers and also prepping them for interviews) to conduct the interview with Brian who is aiming for his first software engineering job. Matt also shared tons of great feedback for Brian at the end that you may find relatable for your own interviews. Hopefully, this can give you a glimpse into a common type of interview you may encounter when trying to land your first job.
Matt Oates (interviewer):
Linkedin - https://www.linkedin.com/in/maoates
Website - https://coachmatt.io
Youtube - https://www.youtube.com/channel/UCrPusfUgx-5dm1WDoTv_HRA
Brian Lam (interviewee):
Linkedin - https://www.linkedin.com/in/brian-lam-software-developer
---------------------------------------------------
🤝 Join our junior friendly developer community:
https://discord.gg/donthedeveloper
❤️ If you find my content helpful, please consider supporting me on Patreon and get access to additional perks. Every little contribution helps me continue to do this full-time.
https://www.patreon.com/donthedeveloper
All right, good to see you, Brian. How are you doing today?
Brian Lam:Hi, matt, I'm good. Thanks for your time. Glad to be here, cool.
Matt Oates:Well, I think we can just jump right in. We have a really juicy algorithm problem that I've asked at least 50 times, so I've got some pretty calibrated expectations for it and it's there's a lot of interesting talking points on it. But enough about that. Tell me a little bit about yourself.
Brian Lam:Hi, my name is Brian. I am a native New Yorker. I taught high school physics for 10 years. I actually had a little bit of background in engineering before that. I enjoyed a lot of things about teaching, but I wanted a career that's a little more dynamic, kind of like use more new technologies and get to learn things as you work. So I decided to switch into software development and then the last school year I went into software bootcamp at Epicademy and I've been working on projects and finding jobs and practicing my Disney skills since then.
Matt Oates:Okay, what's your favorite project that you've worked on?
Brian Lam:My biggest project is a YouTube clone, so a video player. I designed it to change the comment system. So rather than like comments or a live chat, I kind of combined the two. It's an idea I have when I teach online remotely. When the viewers of video make comments, it kind of saves the timestamp in the video of the comments and then when another viewer is watching the same video, the same comments will appear at the same time. So it's kind of like replicating a live chat kind of thing, and then other viewers can reply to each other and it's kind of like they can have like an eight-year conversation as they watch the video. Cool.
Matt Oates:So I've seen that on like SoundCloud and a few other smaller apps. That's really cool. Yeah, threading, having that that can be difficult in the UIs and on the database side too. So can you tell me about any interesting challenge you faced while working on that feature?
Brian Lam:The biggest challenge was just getting the timestamp out of the video player, because it's kind of like a vanilla dom manipulation problem, but then you want to pass it in to different react components. So I had to like look at a lot of different stuff and figure out a way to make a work together which wasn't really like published online anywhere I could find. So I had to play around a lot of stuff but I got a lot of help, so that was good.
Matt Oates:Okay, so the back end was pretty easy. You know the API figuring out the how to how to send the relationship between all the messages to the front end. That was pretty straightforward for you.
Brian Lam:Yeah, at least just added the timestamp as an extra like you know, characteristic on the comments, and then I handled the sorting and the display of the comments on the front end.
Matt Oates:Okay, and so how was what did you use for your front end, like UI layer, react, react, redux, okay, cool, All right. Well, thanks for the context and I think we can just we can jump into the code. So, if you don't mind sharing yeah, you're on top of it. Awesome, you can share your coder pad session. So I'm going to give you the prompt and I'm going to let you figure out. Any other information you need to get started on this, I'll give you. I'll give you one example too.
Matt Oates:So do you know about, do you know about, query strings? No, well, if you, so if you search on Google and in the URL you'll see a little question mark Q equals. And then what do you? What do you search for? Your query, right? Oh, yeah, a little bit. This is the query string. So it's any, any URL. That is a question mark. The query string is everything after that. But today we're just going to include the question mark in the query string. So, given this as an input, we want to. I'll make this a multi-line comment. Given this as an input, we want to turn that into an object that looks like this, and the input will be a string.
Brian Lam:Okay, so we have a string. It starts with the question mark and then there'll be key value pairs. The key value pairs are always separated by a presence. Yes, and the key and the value are separated by equals. Science, yep, okay, seems relatively straightforward to me.
Matt Oates:Okay. Well, let's jump in then.
Brian Lam:So I think we have to use some dots split to get the pairs and then for each pair we could just do dots split on the equal sign in order to get the key and the value. Can I assume that there won't be any ampersands or equal signs in the actual keys and values?
Matt Oates:Yes, yeah, so there's a, there's like an encoding, so the keys and values will be encoded, and right. So there's a question mark in the beginning and then, as you were saying, each key value pair is delimited with an ampersand.
Brian Lam:Yes, All right. So I would call this function something like query string formatted, or maybe like format query string. It'll take in a string. Okay, I'm more practicing Python so I'm sure there's a nicer way. But I would just strip off the question mark, then I would just split it on ampersand and then I'll just iterate through key value pairs split on equals, and then set them in the dictionary or math. That's where we're. Okay.
Matt Oates:Does that?
Brian Lam:sound good to you. Yeah, cool. Okay, I don't think it's super time efficient, but I think I can just do slice. So about that might take off the first character and then I'm not going to modify it, so I'll use const. Actually, okay, key value pairs will be just split on the ampersand side and then I'll just make a map for my output. Does it need to be a object or a map, or rather one?
Matt Oates:Well, we'll have it as a plain object. Okay, sure.
Brian Lam:Then I'll just use for loop and then I'll just break it into a key and the value Okay, just by splitting on the equals sign, and it'll work, I think, unless there's a weird input that doesn't match the format of string equals sign string. But if it does match, then all I have to do is to output key equals value and then I will return output.
Matt Oates:Okay, I can walk through an example, or this example yeah, if you could write out a task for this, that would be great.
Brian Lam:Okay, well, I can just use this input and then I should print out the same as um yeah, put it over here. Something like that might work. Okay, um, yeah, splitting on, oh, okay.
Matt Oates:You ran it, yeah, so that looks good. Uh, if you don't mind, I'm just going to get rid of this. Should be so we'll have the actual output as the first thing that's printed and then the expected output as a second. I think it's just a little bit easier to visually read, and then I'll do consoleclear. Okay, cool, so that works for this case. Um, do you see maybe any corner cases where this might fail, or are you happy?
Brian Lam:Well, okay, I can save a little tiny bit of time by just putting the slicing here after the right before the split. Um, if there were no input.
Matt Oates:How does that save time?
Brian Lam:Well, slicing is like O of n time, so it was not like saving the amount of time, but it just it does save like one line. It's just a slightly big cleaner. Anyway, um, you were asking about edge cases. So I don't think there's any edge cases as long as there's a question mark and at least one pair. Um, but if? What? If there were no key value pairs, then would there be a question mark?
Matt Oates:So great question. So we're going to assume that there always is a question mark, but it's perfectly valid for the query to be empty. So that would mean, yeah, there are no key value pairs. The input would just be a question mark.
Brian Lam:I think it would be okay then. I don't know the exact specific split, but if you pass the empty string to split, wouldn't you just get an empty array and therefore skip the for loop? You can try that out and make sure. Yeah, obviously. Yes, maybe I'm wrong. So just a question mark and then we expect an empty object. Okay, there we go, we got something. Oh yeah, that kind of makes sense because there's an empty string. All right, so so that's the edge case that I didn't think about. Um, so what should I do? Well, I would think that if the key is empty string, then that's not really key value pair.
Matt Oates:Yeah, that's fair. So the key has to be the key cannot be an empty string.
Brian Lam:Yes, Okay, so I can just skip it. Sure, well, that's pretty easy. Just go line 22 and only do this if the key is falsely, I mean truthy.
Matt Oates:Yeah, I'll try it again. All right, cool. So I've got a, I've got a feature request. This is perfectly valid with query strings, and I see this. I see this actually quite often. So if we have, I'm going to modify our one case in the comments up here so we can also have a key that does not have a corresponding value. So let's say, baz, in that case we want the value to default to the string true.
Brian Lam:The string true.
Matt Oates:Okay.
Brian Lam:All right. Well, that's a little trickier than because we have to break the input to key value pairs. We get full hello bar world, then we get Baz with no equal sign. So I would think that you want to go into the for loop and then do one action if the key value pair has equal sign and then, if it doesn't, there's an L statement, only something else. So we have to check if it has equal sign.
Matt Oates:Okay.
Brian Lam:We could do dot includes. I think that's a little bit. I think that would work fine. I'm going to have to convert to array. I don't remember exactly the JavaScript syntax, but we could do that includes.
Matt Oates:So there is also actually is a redevelop print loop on the right hand side of the screen, that little carrot. You can. You can type arbitrary expressions in there. I don't know if you knew that.
Brian Lam:Oh yeah, I'll try that really fast.
Matt Oates:So we, can dirty one a test Sure.
Brian Lam:Yeah, that seems fine. I don't think it's very slow just to get all then, so not too significant. But I could also like check if after pair splitting. I think that would work. But I read something else. I think I'd rather just call the pair after I call that split the split pair and then the if will be. If the split pair has length two, then it's a key in value. If it has length one, then it's just a key and the value is the default value of the true string.
Matt Oates:Okay, that sounds pretty fine Cool.
Brian Lam:So it's a nested if statement. It's hopefully not too confusing for anyone. But yeah, actually I don't think I need this if statement anymore. Let me just finish up my reasoning before I move on. Then, if the pair length is not two, it's probably one. I can even check that just for like a little bit of edge case safety. And I want to set output key not to be value, because it will be value, it'll be true. I have to change key and value because they're not declared. So actually it would be split pairs, split pair one, and I can rename them over here to make it a little clearer for someone else if I want to. But I think zero and one are okay for this shorter problem. Sure, and then I'll put the same statement to check if it's a empty string. That's what I had in mind. Okay, I'll test it again. Something like that might be my test.
Matt Oates:Okay, sure, I also like that you created a new test instead of blowing away something we had previously. Cool Looks pretty good, yeah, that works. Before we move on to the next part of this question, because that's a little tricky, I want to push you to simplify the logic that you have in here, because I see some Absolutely Either redundancies or unnecessary code.
Brian Lam:Yeah, I don't think I need this if statement anymore, because if the length is two, I'll definitely have a key and a value. I don't think I need this, if exactly, unless there's a weird edge case. Okay, sure, so we'll assume that the length is one. If it's not two, I could go to the nested, if Well.
Matt Oates:Yeah, yeah, I think. Well, does that introduce a regression? Okay?
Brian Lam:I'll just put it up here. If it's adaptive string, then I'll just continue.
Matt Oates:Okay, so that works too, I believe. Let me give this a run. Yeah, and one more thing too. Do you see any corner cases with this solution?
Brian Lam:I have a thing for a second. I'm taking out the question mark splitting on 8%. So after I split on 8%, I'll have either key equals value or just keys. It handles key equals value. It handles just keys. I think if there were no 8%, there's just one query then that would be okay. Yeah, I think it handles that case. Yeah, I don't see it immediately, unless maybe could the value be an empty string or something like that. The value of an empty string? Yeah, Do we?
Matt Oates:know that correctly.
Brian Lam:If the value is empty string, then the split. I don't actually know. I mean check. If split gives you an empty string, so it does, and that's the value, not the key. So I'm not checking for split pair 0 or split pair 1. Check for split pair. Did I make a mistake? I think I made a mistake. Well, not really a mistake, but I'm checking if an array is falsely. But arrays are never falsely in JavaScript, I believe.
Matt Oates:Right, yeah, so this is actually yeah, good point. This is dead code, okay.
Brian Lam:So actually I do need to handle the edge case inside here, I believe, if not split pair 0, because that'll see the key being an empty string, but the value can still be an empty string. Yep.
Matt Oates:And Okay, so, yeah, that's good. So last stage of this part, now what we can do. So this is once again something that actually is valid with query strings. This I don't see that often, but it's perfectly valid. I'm going to amend our example at the top. I'll have this key value pair, all of a key that appears multiple times. I'll say and foe equals again. And now, if a key appears multiple times, we want the corresponding value in the resulting object to be an array of all of the values associated with that key, in the order that they appeared.
Brian Lam:Okay, but if it's not appearing more than once, you still want just a string. Yes, okay. Yeah, a little bit annoying, but not terrible.
Matt Oates:It's a little awkward, yeah, but that's the question for now.
Brian Lam:Okay. So in here, the simplest way I can think of is just check, check if output I'm going to rename to the pair zero. Actually, yeah, I'm going to do it just to be a little bit clearer. Sure, I'll just say I'll just call a key outside the if statement and then inside the statement. If the link is two, then I can have a value also. Now the string is the key in value.
Matt Oates:You wanted to do it up here too, right? Yes, thank you, sure.
Brian Lam:Okay, so sorry, I got distracted. Anyway, I'll check if the output S is a string already. If it's a string, then I'm going to do put the string in an array, make it an array. There's actually three cases it could be a string, it could be an array. If it's an array, you just push it in. And finally, if it's none or null or undefined, I guess it would be. Yeah, it would be undefined. Thank you, and that's when you do line 38, just set it to value the string. Okay, I'll call that up. This I might do the help.
Matt Oates:It's like type of yeah, any kind of awkward type checking in JavaScript is a little funny sometimes.
Brian Lam:Equal to capital S string.
Matt Oates:Laura case, yeah, you got it. And, as you were saying before, if it's a string, if it's not a string, then we know it's an array or undefined.
Brian Lam:Oh no, not a vowel, it would be output key. In fact, I should probably check it's undefined first, because I don't think you can do Well. I guess type of undefined would be undefined, right.
Matt Oates:You could also just check if it strictly equals undefined yeah.
Brian Lam:Okay.
Matt Oates:There's some boring historical reasons as to why the type of check is a little bit better, but checking with strict equality is totally fine.
Brian Lam:Okay, yeah, I'm gonna do that first, just because that makes I think that's the easiest case to check for. So the first thing I'll check is if it's undefined, then I'll do the last, oh, the last line down here. So if it is a string, it has to become an array. So I'll let newVow be an array holding the original string, then append or pushVow and I'll just reset the output key to be newVow instead of Vow, and then, last case, it should be the array, so I have to just push.
Matt Oates:Click that. All right, that all makes sense. Do you want to test this out a little bit? Yeah, I'm sure.
Brian Lam:I'm just gonna oh for this is okay, and I'll copy the example. All right, there we go. Okay, it didn't work. I still got a string. I still just got the overlay. Weston, thank you, I'm going to see if I hit this branch of the else if statement. I did Newvalputkey inside an array Newvalpushval oh, this should be newvalsetval. There we go, that should be good. All right, I think that's good.
Matt Oates:Yeah, okay, cool. So now you know all the features we want for this function. Did we introduce any regressions with your changes?
Brian Lam:I don't think I call format query string inside format query string.
Matt Oates:Why would you need to recursively call format query?
Brian Lam:string.
Matt Oates:Regressions. So we know all the features right? Do we support all the features in all the cases, or is there some corner case where we lost support for one of our features?
Brian Lam:I don't think so. I think it's okay if you have a double key and an empty string val. I still think you don't want any empty string keys, even doubles. Still I don't think you want that. I can't think of anything right now.
Matt Oates:Okay. Yeah, it's tricky because we have a lot of branching logic. It might not be immediately obvious what the issue is, but I'll show you a test case that has a regression. I'll simplify it too. So we do foo equals hello and foo. We expect to get true and hello, but I don't believe we do.
Brian Lam:I see.
Matt Oates:So foo is specified twice, but in that case we're losing the first associated value with foo.
Brian Lam:Right, that's because we never entered this if statement. The second time we go straight to the else and we overwrite the what was it? Bar or hello? Okay, I don't think it's super elegant, but I think what we could do instead of this. If else, we can just check if slip paired out length is one we can just push in a string, true, so it'll always be linked to.
Matt Oates:Okay, yeah, you can go ahead and make that change.
Brian Lam:Sure, all right, I'm going to comment it in case I that's about, because if it's an empty string, it would also be now. If it's empty string, then the key will be empty. And if the key is empty, it doesn't matter what the valid. So that's okay. So then I'll just do slip paired dot, push and then I'll put the true string in there. So if it was an empty string, I'll get it away with empty string. I think that's okay. So this is all. So this will take care of that. I believe it's a little messy. Oops, just this, but yeah, so if we don't have a value, then we add on the value of true for every pair with every key without a paired value.
Matt Oates:Okay, okay, cool. So that looks good. We have a little bit of time left for this problem, so I think we can go to the final stage, the final level, all right. So, remembering all the features that we have for this query string parsing, let's build the inverse. So, given a parsed query string in the shape of an object, as you saw before, let's create the original query string.
Brian Lam:Okay, Can I call that whatever I want, Just like I don't know not for it, not parse, I'll leave the naming up to you.
Matt Oates:Sure.
Brian Lam:Make a query string and it will take an object which I'll call parsed Maybe not the most clear, but I like it parsed. Okay, so for this we have to go through every key value pair and just add it on to the end of a string in format key equals value. That every say in the between them all. Does the order matter?
Matt Oates:The order. We really only care about preserving the order in the case that a key has multiple values, so we want to preserve that order. But in terms of the order of different key value pairs, we don't, we don't care, so you want the, the keys with one value, to be together. They don't have. They don't necessarily have to be together, but the values for repeated keys have to be in the same order that they were in the the parsed object.
Brian Lam:Okay, that doesn't seem too hard to me. So I will initialize a string, which that's a question mark, then I'll loop through parsed and then there are two possibilities. If val is a string, append key equals val l. If it's a array, for val in val's array append key. So we don't want to understand for the first one or the last one. So that's, that's enough to fix, though. That's my general structure for this problem. Okay, actually, you better to make the queries a array and then just join them on a percentage. That that's a little clearer, I think. All right, if that sounds good, I'm ready to try it, go for the fifth time.
Brian Lam:Okay, empty array. I don't want to initialize a string. Hopefully this is the right syntax, not values, not keys. Is it in your hairs, thank you? Thank you, then I'll push into queries a formatted string or I forget the term, but this kind of string it would be well. I don't know how to do that Key plus equal sign, plus val. Else I did a for loop, really it'd be vals not val. So it's for every individual value. Val is not a single, it's actually an array of vals if it's not a string, and then at the end I'll just return plus queries to join on a presence. So if there's only one val, I'll push in key equals val. If there's only one val, for every individual val I'll put the same key equals sign, individual val, and it should be in the same order that they were in the parsed object that was passed in.
Matt Oates:Okay, that makes sense.
Brian Lam:Okay, I'll try it up. Can I just pass in the formatted string for my examples?
Matt Oates:Well, we need to pass in an object to this.
Brian Lam:Yeah, sorry, can I pass in the parsed string, parsed by my previous function? Sure, okay, cool.
Matt Oates:Then one more closing parentheses right there.
Brian Lam:And that should be the same as the string I passed in to the first function. I probably want to do it for all them, but I just want to see if this works.
Matt Oates:Let me just log a little to limiter there. So it's a little easier to visually parse the test output.
Brian Lam:Oh, I didn't run the second function. That was not iterable. Okay, so val could be not an array, not a string. It must have been undefined, I guess. Well, let me see.
Matt Oates:Yeah, so how could it be undefined that? Doesn't really make sense, does it?
Brian Lam:So in this query string this is the one with the doubled keys, so I passed in this into the second function. Key val. Val is not a string.
Matt Oates:The issue is up here. Oh, my gosh, thank you. You want to?
Brian Lam:move. Yes, too much Python. Okay, is that it Maybe?
Matt Oates:Whoops, I stopped your run. Sorry Foo, hello Foo again. Bar world Best true.
Brian Lam:No, wait, no, I'm missing the true, the true string.
Matt Oates:Well, so you're actually adding the true string for strict compliance. We want to, in the case where this value is true, to just not add an equal sign and a value.
Brian Lam:Right, I'll put it in right now. Then you just want to push the key, and that could also happen here. Yeah.
Matt Oates:Can you do this without duplicating the code, because I trust you to get it working.
Brian Lam:Put it in the code.
Matt Oates:Maybe refactor this a little bit and have that feature, the code for that feature, in not two places.
Brian Lam:I guess I could make these two into a similar function.
Matt Oates:Yeah.
Brian Lam:Helper function Like a helper function. Okay, sure, so this function is going to put key value pairs into queries. I don't know if this is like good practice, but I want to declare it inside the make query string function. Okay, I'm going to use K and V to not reuse key and value, because I might get confusing. But it's just, if V is equal to the string, true, then I'll just queries to push key only. Otherwise I'll push in key plus equals plus V. I said I was going to switch to K and V, but I didn't. All right, so I can just change these two lines or all these lines. Okay, so I don't need these two. I will do insert key comma and then any other statements. I'll insert a key comma individual there.
Matt Oates:Okay, I think that should be good and we have all of that in there and we have, yeah, great, yeah, just in order.
Matt Oates:Okay, so we've got the corner cases pretty thoroughly mapped out. We did touch on one more thing that would be an obstacle for you to ship this into production or release this as some package that other people would use. Yeah, so there's something still quite limiting about this approach. It's not performance. It's not performance. Imagine using this in the real world and wanting to encode really arbitrary keys and values in a query string. Can you think of anything else that we might want to add to this?
Brian Lam:Specifically for the second function.
Matt Oates:Well, both of them really, and this isn't a new feature, they're still a bug with some inputs and this is either, like a, you know it or you don't.
Brian Lam:I might not Okay.
Matt Oates:So what? If I right, so you know, in Google you can search for in your query, you can have like a question mark, right? But we were saying with the in this problem that a query string is not going to have any question mark in any key or any value, right? So how is that possible?
Brian Lam:You're saying like what if someone does search for a question mark?
Matt Oates:Yeah, what would that look like in the query string?
Brian Lam:There'd be a question mark.
Matt Oates:There, actually wouldn't, so there's encoding and decoding.
Brian Lam:Oh, like percent 20 or something like that.
Matt Oates:Yeah, yeah, so you recognize it. Yeah, so you've seen it before. You know this stuff. So I'm down on line 115. There is the encode URI component and there's decode URI component. So that's your encode and decode respectively for the project. Here I will scroll up to our first algorithm. We don't need to add this to both of these because I don't think that's a. We can skip past that. But right, so the question mark, the actual encoding for that is yeah let me refresh myself.
Matt Oates:So encode URI component of a question mark is going to be percent 3f. So this we really want this to be Q mark question mark. So that's the final feature. Got it.
Brian Lam:Well then, but it wouldn't be just percent 3. Like it could be percent 3j or something like that, Right.
Matt Oates:Right. So I told you the functions that we can use for this. So you'll want to use I'll just show you for it. So this encode URI component and decode URI component essentially right. So you have your split pairs here. So I'm on line 21. We can just map string, start, map it where we decode URI component. Right, and I believe that would do the trick. Yeah, and then without that, you would of course get the ugly percent 3f.
Brian Lam:Oh cool, so that was built in.
Matt Oates:Yeah, yeah, so that's a native function. Anytime you have an impulse to build some kind of you know, write something to escape HTML or escape things like that on your own, that's a really hard problem. I would strongly, strongly advise against doing that.
Brian Lam:Cool and that works for both keys and values.
Matt Oates:Yeah, so we would do this the way that I did this. So I did a pair split map decode URI component. So this will call the function on the key and the value.
Brian Lam:All right great.
Matt Oates:Cool, thank you. So that's the question. Thank you for that. That was great. Lots of interesting points, and you're in a good place too for this. What I want to do first is talk about the tell me about yourself question, and then we can get back to the algo here. Yes, please, ok, yeah, how do you feel the tell me about yourself prompt Wint?
Brian Lam:Maybe I was a little bit too fast. Maybe I should slow down. I probably done it a little bit too much, so I think I get a little bored of it.
Matt Oates:Oh yeah, that's fair.
Brian Lam:Yeah, I think I should probably slow down. Maybe get some back and forth going if possible.
Matt Oates:OK, yeah, back and forth. Yeah, definitely back and forth. It can be engaging, but it's yeah. So that also requires the other person to ask questions, and that little back and forth. I really. Yeah, that's a great point. Talking too fast, yeah, you were almost slurring your words a little bit and I could understand what you were saying and you were still communicating pretty accurately. But I think if you were to slow down a little bit, I don't know, take a deep breath, or were you? Were you nervous or just high energy, how were you feeling?
Brian Lam:I think a little nervous yeah.
Matt Oates:OK, yeah, that's totally fine, that definitely happens. Yeah, I think, like just physiologically, one of the things that I do that really helps me prepare for big calls, interviews, things like that, is to just really get my neurons a break. So that can be like go for a walk outside for five minutes or stare at a wall. Definitely don't be on your phone, don't be on Twitter, instagram, whatever, or X, which is it what it is? Oh my god. Yeah, just find some way to wind down before the interview. Another really big point, too, about the back and forth. So your YouTube clone project, that's like a massive scope and really interesting and I wanted to dig into your threading, the comment thread feature having replies and things like that and timestamps. Wait, did you have threads where one person could reply to another and then one to another and so on and so forth?
Brian Lam:Yeah, but not if the comments are made at the same time. If the comment was loaded before the new person loads a video, then yes, they can reply.
Matt Oates:OK, cool. So that's a really juicy problem and I got the impression that you as an interviewer in that exchange I would have assumed that there were pretty significant technical aspects that were overlooked. So, youtube scale of course, you're not building something at YouTube scale, but something beyond, a pet project that would support maybe 500 or 50 or like 100 comments. One of the features you're going to need for comments is pagination, and then when you introduce another feature, as we were noticing today with this query string problem, you have these two different features like this defaulting to true and then the supporting multiple values. Like those features, when you implement one, you could break the other. So supporting threads and then supporting pagination and supporting timestamps. That sounds really complicated and I was hoping to hear a little bit of interesting technical challenges that you faced with, either the API layer or state management on the front end or the database layer. Am I jogging your memory on any challenges?
Brian Lam:Yeah, I remember I had to write a recursive function to display all the replies to a comment. It was a little bit tricky, yeah.
Matt Oates:OK, so it has been quite a while. But yeah, so there was no pagination, right, you just loaded everything.
Brian Lam:Yeah, it's a scrolling window. There's no pagination.
Matt Oates:OK, but does it attempt to load all the comments on its own, or will it only do that if the user clicks expand or scrolls down or something?
Brian Lam:The default is to load them all as the timestamp passes. There's a tab. You can click a tab to just load all the comments regularly.
Matt Oates:Ok, yeah, so obviously that wouldn't work at YouTube scale and that's OK for a project like this. I think it's also really, really important. So you don't have to build something that's going to handle all those cases, especially the massive scale of comments. But really to get half of the value is to acknowledge that, ok, I built this, it handles these two features, but it would break down once you get past, say, 2,000 comments for this technical reason and you could explain oh, I didn't get to that because it was a pet project or I decided not to.
Matt Oates:I felt like you were just glossing over those technical challenges and I don't know if that's because you weren't aware of them or you weren't able to solve them, or what. That, to me, felt like a blind spot in the tell me about yourself. Ok, prompt, yeah, yeah. Also another, I think, untapped opportunity. So you mentioned teaching. So you taught physics, right, yes, cool, have you taught any of your peers in App Academy or any project that you've worked on? As you're working together, maybe you try to explain something you're teaching, like teach how to use Redux or pairing on algos, like, can you tell me maybe really quickly about one instance that comes to mind?
Brian Lam:That's also. It's been a while but I did work on some projects in like peers since graduation that I helped some of my old classmates and people.
Matt Oates:So I think that's like a really interesting point to dive deeper on, to dive deeper into in interviews. So you have this teaching background. A good interview, a good engineer, is going to, of course, another stuff, but they're also going to be teachable, and to be teachable like being able to teach others really helps. And then, of course, once you get past the entry level, junior level, you're going to be leveling up your team as you yourself level up, and that ability to teach, to convey complex concepts, is really important, and to have that expertise in teaching physics is certainly transferable here. So I think any kind of case study that you can imagine, any kind of examples, little stories that you can tell, would be super interesting in an interview like this.
Brian Lam:That's very helpful. Thank you, cool.
Matt Oates:Yeah, so it's really interesting projects. I think you can just really drive the point forward by telling some interesting stories about how you've taught your peers and then also getting into the weeds about some of the technical challenges, because building a YouTube clone of course, depending on the level of complexity you commit to is incredibly rich. It's a very rich technical problem Cool. Do you have any questions on that?
Brian Lam:feedback. Yeah, can you expand on something? So that's a really good advice, for the question you always get was telling about your cell, telling about your background. But it's such an open-ended question. How would I know whether this interviewer wants to talk about the technical difficulties or hear a teaching story or talk about something else? Yeah, so should I ask them directly?
Matt Oates:That's a great question. So I'm not sure that I would ask them directly. But yeah, I can summarize it's a conversation, so there's some signal to you of what is interesting to them in either their facial expressions or questions that they would ask you as you're talking. So I think that pretty much any interviewer would find both of those subjects pretty interesting. It's just that maybe if you get really into the weeds on some technical aspect say like the YouTube comment section, if you were interviewing in like MongoDB, that's a database company they would probably be really interested in how you orchestrated that on the database side. If you were doing this for Facebook, they might be really interested in the interactions between the front end and the back end. There's a context that's a little bit more relevant based on the company that you're talking to. Yeah, that makes sense.
Brian Lam:Yeah.
Matt Oates:And yeah, it's a conversation, it's a negotiation, yeah, Cool. So great questions from you all and back to the algo. What did you? Well, I'm going to ask you two questions. So how do you feel it went? Like strong fail, fail, pass, strong pass. What do you think?
Brian Lam:I stopped sharing. Do you want to see it? I don't know.
Matt Oates:Yeah, you can keep it up, because I'm going to. I'm going to be making some code changes in the feedback. So actually, yeah, let's keep a big picture and then when we get back into it, I'll have you share again and I'll show you some code changes. So we still have good time for that.
Brian Lam:You can see it right. I think, logic-wise, I did a good job of passing the specs. I think, like we're saying earlier, sometimes I do talk a little bit fast and could slow down on some parts.
Matt Oates:We weren't doing that. I didn't notice you doing that on this problem. I think the nerves were worn off a little bit at that point.
Brian Lam:Yeah, so I did my best to lay out some pseudo code before I started and then I tried to match up my actual code with my pseudo code and hopefully that was followable. Yeah, I think I did well overall, but maybe I could have taken a little more time to pick up some other edge cases before I ran tests or something like that.
Matt Oates:Well, yeah, the edge cases and help you decide on what tests to write. I agree with that, with the caveat that you could have been more proactive about envisioning those test cases. Yeah, but how do you feel like, objectively, how did you feel the interview went?
Brian Lam:I think I did it pretty well. Objectively, I think the question was on the easier side of everything I've seen ever.
Matt Oates:Okay, interesting, cool In terms of Right. So this question was on the easier side. Do you have any feedback on the problem before I give it, before I get into specifics?
Brian Lam:I liked it. It's a real-world problem. I've seen Google search queries before, even though I haven't really dealt with them. I even knew the deco you arrived, even though I didn't know what it was. So it was just fine, nothing too tricky.
Matt Oates:Okay. Yeah, so the intention with this problem is that it's quite approachable, but there's opportunities for introducing regressions, which you did with the format query string and the other problem. So this one, I think, is a little bit between a theoretical algo leak code style problem and slightly in the direction of practical coding. Yeah, I was saying I don't think there's really anything conceptually in terms of advanced concepts. That's too crazy. Here the challenge is really writing elegant code and not introducing regressions with each additional phase for the problem and then envisioning those corner cases along the way. So this one this is actually quite representative of a question that you could see in an interview and then the focus, as I was saying, would be on envisioning those corner cases as well as not introducing regressions.
Matt Oates:Clean code. This would be a pass, not a strong pass. And to get to a strong pass, what I would have wanted to see was the productivity around envisioning those corner cases, which you eventually did. You came up with the good corner cases. You were really good about that. You were really good about variable naming. But I'm staring at line 13, without ampersand this is actually without question mark, but that's pretty minor, minor thing, that's not a big deal. Yeah, so your code was really easy to follow. But once again, I did have to push you to consolidate your code, to simplify it, and that's something that I think like proactivity around that would be good too. So once you get to a working solution, then you can start thinking about well, does this code work? Other opportunities to clean this up?
Matt Oates:There was also the one line of dead code. If not some value, that was always an array. That was there. So really as a high level, it was good. There was like a level of fluency with JavaScript here. You didn't really hesitate and you were able to write out your pseudo code. It was pretty easy to follow along and that actually you stuck with the pseudo code. I think really just the two main things if you're struggling in your interviews is to be proactive about those corner cases and then also, if you get to a working solution, then look for ways you can tidy up your solution to. Do you have any questions?
Brian Lam:about that? No, that sounds very helpful though.
Matt Oates:We'll name it in corner cases. Yeah, do you want me to show you a few opportunities to simplify code here further? Okay, cool. So let's just look at the format query string. So up here, this is all great Sting splitting, and then you're doing this here. I'll just get rid of the commented code for a moment.
Matt Oates:So this one, this format query string, is pretty tidy. There's really just one thing that I think could simplify it a little bit further, and this is just syntax. This is pretty minor, so okay. So val equals split pair, index at one. And then this little feature here so in the case that no value is specified, you want it to default to the string true. So that can actually be done by destructuring. So you have this thing here, and that is. Let me put this up here. So you have this. Let's comment this out. For now, what you can actually do instead of these two lines of code is you can just do const key val equals split pair, and if you want to get this, this defaulting to true, then you can just do equals true here. So there's no value in the original array. If this array is of length zero or one, then this will get the value true. So you get all that functionality there and then, if you want, you could even inline this here. So this is kind of like advanced JavaScript syntax. It's not a huge deal if you don't get that. That tidies that a little bit.
Matt Oates:Coming down to your make query string, I'll get rid of some of the code here. I'll push you a little bit to come up with the idea behind this simplification. So I do like the helper function. I think that's quite helpful. I've already covered all of the, but we still have this like if it's a string, do this. If it's not a string, if it's an array, then do the other thing. Do you think it would be easier if we just could assume that it was an array, like if it was just always an array? Yeah, definitely. Can you make that happen?
Brian Lam:Um, I don't know if it'd be elegant, but you could do something like if type of vowel is string, vowel equals vowel, yeah, yeah, then you wouldn't need any of this stuff.
Matt Oates:Yeah, that melts away, this melts away. Yeah, that's cool. Um, and then, if you want, you could even inline this logic again. But I think having this as a helper function is good too Cool. So that's the two problems.
Matt Oates:I'm glad you were able to get through all of the different stages for that. And then this like encode your iComponent, decode your iComponent thing. I've asked this question at least 50 times. Um, people have gotten a good amount of let's, let's give you some truth data. So I'd say about 60% of the people will pass this question and maybe only 15 or 20% get all the way to this like final stage of doing the inverse function.
Matt Oates:And I've only had one other person come up with this encode your I, decode your iComponent, right. So like this is this is like the final, the final boss, right, knowing that. So like this certainly wouldn't fail anyone. But like at that, with problems like this, they're like there is, there is like a certain amount of domain knowledge that can be useful, right? So this is query string parsing encode your iComponent, decode your iComponent. That's query string stuff. And then, like when you're when you're, when you're like a senior level, especially with front end experience, I guess back end, too, you're gonna be this encoding and decoding is gonna be like very top of mind. So this is something that I can, that I think can like separate. It's a signal of you know, like junior versus senior level, that kind of thing. So problems can seem easy on the surface, but it's the execution that can really reveal the strength of a candidate. Yeah, and you did execute, execute well, but of course, for there's there's pretty much always room for improvement. Do you have any questions or thoughts?
Brian Lam:How can you tell if you're going too fast, Like sometimes? I've done interviews where I've seen the problem before and I just remember my solution, or how can you like, is it generally good to? How do you know when to pseudocode, when to not pseudocode, when to make helpers, when to not like, how? How?
Matt Oates:to determine, like, how fast to go. So two different questions those feel like very different questions to me about, like helper functions and then pseudocode or not. To pseudocode or not to pseudocode, I'll address helper functions. So helper functions is one of the great ways to separate concerns. So, on, one of the questions that I really like to ask is counting the number of islands, counting the number of square islands in a matrix. So there's this really popular elite code problem counting the number of islands in a matrix. If you add an additional constraint, that is, counting the number of square islands in a matrix, then all of a sudden people get really overwhelmed with all the corner cases, right? So like you wanna make sure that the entire square is filled, you wanna make sure that outside of that square it's always water or out of bounds, and then you wanna make sure that nothing is touching on the corner. There's like a lot of corner cases and with a problem like that, if you're considering all of those corner cases for each line of code that you write, you can be really overwhelmed. I've seen candidates where they spend the entire hour talking about the problem and writing comments and they don't write a single line of code. That's pretty rare, but like. That's the kind of problem that can do that, and that's where the separation of concerns really helps, creating different helper functions that elegantly break down the problem, where you have this little helper function and you only need to think about, well, what's the input, what's the output, what does it do, what's the contract? So, helper functions my strong opinion is that if there's a helper function that you have thought of and that's useful, use it Like. I haven't seen anyone write too many helper functions ever in an interview. So if you can imagine one, then do it In terms of like pseudocode.
Matt Oates:Pseudocode is let me get a little bit more general. So do you ever feel this impulse to like talk and code at the same time in an interview, or not? Yeah, okay. So let me replace the word talk with like communicate. So the okay, I don't need to do that. So the priorities that I see is priority one is code. Priority two is talk. You can communicate with the code that you're writing or comments that you're writing, and if you're following best practices, you're not going to be writing a ton of code and not talking at all, even if it's a problem that you've seen before. Right, if it's a problem you've seen before. You still probably aren't going to bang out a solution without any bugs when you get to when you.
Matt Oates:The times where I actually think about like pseudocode is when I don't know what code to write. So if I don't know what code to write, then perhaps I'll write some pseudocode to help break the problem down, or write a helper function and think of the input arguments and out in the return type and what the function does, or I'll write out some pseudocode, or I'll talk through what I'm trying to do and then that might help me write some pseudocode, which will then help me write the code. So this is all really just on demand, right? So now of course there's the clarifying questions and things like that that you want to ask upfront. But if you know what code to write, then write the code. If you don't know what code to write, then write pseudocode or talk through it, but don't try to talk and write code at the same time. That can be counterproductive, okay sure.
Matt Oates:Yeah, so pseudocode on demand. Talk if you don't know what to write. Any other questions?
Brian Lam:No, I think that's a lot. That was very helpful.
Matt Oates:Awesome. Well, brian, thank you for doing this question justice. You did a great job and I think, with a little bit more targeted preparation for the tell me about yourself question and any other just soft skill questions, you're going to be able to extract a lot of value from your background and I'm seeing a good level of baseline fluency. I'm seeing a very clear thought process. You're writing pseudocode and you're sticking to that. You're not diverging and writing some other approach. I'm seeing like very good mechanics here and, yeah, just to get from someone that can like pass an interview to someone, where the interviewer is going to be is going to like fight for you as a candidate. The next level is to proactively envision those corner cases and tidy up your code, given the opportunity. Good stuff, man, all right. Thank you very much for your time and your feedback.
Brian Lam:Thank you, yeah, hey, I hope you enjoyed this mock interview.
Don Hansen:That was actually a mock interview between Brian, who's a brand new developer he's here in Atlanta's first position and Matt, who has extensive experience in the software engineering industry, and he actually helps a lot of junior developers who are not familiar with software engineering. He actually helps a lot of junior developers prep for interviews, just like this. But he actually created his own platform at coachmetio and you just practice algorithms and it has a little bit of a twist. It's not so focused on memorizing the algorithms but more focused on learning concepts. So if you want to check that out, definitely do so. And also let me know what you thought of the interview and the comments.
Don Hansen:I definitely want to hear about it. Did you love it? Did you hate it? I actually read every single comment, so I do appreciate people that take the time to do that. And if you want to find a community, you're looking for a Discord community. I actually own one. I'm gonna leave the link in the description, but it's a junior friendly Discord community. We have about 2,000 members there and we'd love to have you.
Brian Lam:Anyways, thank you so much for watching this. Check out the fullhand nails Galaxy ensuiteedam Organ.