We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free

Python Interview with a Meta engineer

Watch someone solve the two city scheduling & longest common prefix problem in an interview with a Meta engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Two City Scheduling & Longest Common Prefix

Interview question

**Two City Scheduling:** Given a 2D cost array where each entry represents the cost to fly a person to either City A or City B, determine the minimum total cost to fly exactly n people to each city. The candidate identifies a greedy approach — sorting by the cost differential (A minus B) and splitting the sorted array down the middle. **Longest Common Prefix:** Given two arrays of positive integers, find the length of the longest common prefix shared between any pair of integers (one from each array). The candidate precomputes all integer prefixes for the first array into a set using repeated integer division by 10, then searches each element of the second array against that set.

Interview Feedback

Feedback about Golden Eel (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

4/4

How was their problem solving ability?

4/4

What about their communication ability?

4/4

Overall Impression This was an exceptional interview performance. You demonstrated strong problem-solving skills, excellent communication, and a highly structured approach throughout both problems. What stood out most was your ability to clearly articulate your reasoning, align the interviewer with your thought process, and efficiently translate ideas into clean, correct code. You consistently exhibited behaviors that interviewers look for in strong candidates: clarifying requirements, discussing tradeoffs, identifying appropriate algorithms quickly, writing maintainable code, and validating your solutions through walkthroughs. Overall, this was one of the strongest interview performances possible and reflected a high level of technical maturity. What You Did Well Excellent communication from start to finish One of your biggest strengths was how clearly you communicated your thinking. You consistently explained your reasoning out loud, and your explanations were concise, confident, and easy to follow. Throughout the interview, it was always clear what you were thinking and why. Strong problem analysis and edge case awareness You quickly reasoned through the problem statement, identified relevant edge cases, and established confidence in the requirements before moving into implementation. Quick identification of the correct algorithmic approach You immediately recognized that the first problem was well-suited for a greedy solution and were able to justify the approach clearly. This demonstrated strong pattern recognition and algorithmic intuition. Great use of comments and solution structure Your comments were extremely effective. They communicated intent and made the overall strategy easy to follow. This significantly improved readability and helped keep the interviewer aligned throughout the session. Strong optimization mindset For the second problem, you quickly identified a brute-force solution and then proactively continued thinking about optimization opportunities before settling on an implementation. This showed strong awareness of tradeoffs and a desire to find the best solution rather than stopping at the first correct one. Fast and efficient implementation You translated your ideas into code quickly while maintaining clarity and correctness. Your implementation was concise, organized, and easy to follow. Good responsiveness to hints When given a small hint regarding how to store prefixes efficiently, you immediately incorporated it and continued progressing without losing momentum. This was a very minor prompt and was handled well. Strong validation and debugging process After completing your solutions, you performed a thorough walkthrough of the code to verify correctness. This demonstrated confidence in your implementation and helped reinforce that the solution behaved as intended. Areas to Continue Building On There were very few meaningful areas for improvement in this interview. Most feedback falls into the category of continued refinement rather than addressing weaknesses. Continue balancing optimization discussions with implementation speed You did a great job exploring optimizations before coding. As you continue interviewing, maintain that balance between discussing alternatives and moving toward implementation so that you maximize both problem-solving signal and execution signal. How to Continue Improving 1. Keep leading with structured communication Your communication style is already a major strength. Continue: Clarifying requirements Explaining tradeoffs Summarizing your plan before coding Walking through solutions afterward 2. Maintain your validation process Your habit of dry-running solutions after implementation is excellent. Even experienced engineers catch mistakes during walkthroughs, and continuing this practice will help maintain a high level of correctness. Final Thoughts This was a standout interview performance. You combined strong technical problem-solving with excellent communication, clear reasoning, efficient coding, and thorough validation. The interview consistently felt organized and collaborative, and it was easy to understand both your thought process and your implementation decisions. The most impressive aspect of the session was not just that you arrived at the correct solutions; it was how clearly and confidently you communicated your approach every step of the way. Your comments, explanations, and structured problem-solving process made it exceptionally easy to follow your reasoning. Overall, this was an extremely strong performance and demonstrated many of the qualities associated with high-performing software engineers in technical interviews. Best of luck on your future interviews!

Feedback about Admiral Dictaphone (the interviewer)

Would you want to work with this person?

Yes

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

You were awesome! Good communicator, and I felt at ease solving the problem without hand holding.

Interview Transcript

Admiral Dictaphone: Cool, yeah, go ahead and introduce yourself.

Golden Eel: Yeah, so just keep it anonymous. I'm Golden Eel. I I have 3 years of industry experience. I just graduated from my master's this past April. I have an interview coming up for [REDACTED]. It's for [REDACTED] in the next week, and it's the onsite. So it's the final round, and I just wanted to get a little bit of hands-on algorithms practice before, before I jump into it.

Admiral Dictaphone: Cool. Well, congrats. I have worked at [REDACTED] before, so I know how their interviews have gone. They're pretty straightforward, so nothing too crazy. But yeah, so I've worked at [REDACTED]. I currently work at Meta. I've been there for about 2 years now and I just like interviewing people, so, and providing feedback. So that being said, let's get started. What language are you most comfortable with?

Golden Eel: I'm most comfortable with Python.

Admiral Dictaphone: Sounds good. Let's switch it over to Python. Second question, would you prefer to do a more [REDACTED] style question that I can— that you can reference afterwards, or would you prefer more of a custom style question, just to do something off the books?

Golden Eel: Um, I think let's do a [REDACTED] question. I hope I don't I haven't seen it before. If I haven't seen it before— if I have seen it before, we can switch to the custom style question.

Admiral Dictaphone: Sounds good. Now I have plenty of [REDACTED] questions that I've done. So let's just do this one. All right. Have you seen two-city scheduling before?

Golden Eel: Two-city scheduling? Um, I may have seen it years ago, but I don't actually remember this.

Admiral Dictaphone: All right, let's see if, if it rings any bells. So I post the question: company is planning to interview 2n people, and given the array costs where costs of i is an array of static value to the cost of flying. Yeah, it's a bit confusing, but basically what's happening is you have to balance it such that if there's a 4 values in the 2D array. Yeah. 2 people must go to position city A and 2 people must go to city B, and you must decide the cheapest cost overall for the logistics of traveling all of these people to these cities. So in example 1, you would pick city A and then city A for 2 and then city B and then city B because that's just the cheapest costs. But yeah, yeah, and that's a total of 2 people. But if we're larger or different sizes of arrays, this number of people must be equal across city A and city B.

Golden Eel: Okay, I see. All right, um, so I'm just taking a look at the examples really quick before I formulate a plan. And before I even think about coding, um, let me get rid of these just so it's a little bit clearer to me. I'm just going to comment out my thoughts, um, before I go into my implementation. So based on this, uh, we're interviewing 2n people, right? Um, It's going to be an even number, which is a good thing for me to keep note of. This is going to be an even number of people being interviewed. So we're going to fly out n people to City A. And n people to city B. I'm going to, for the next thing I'm gonna say a lot, I'm going to tell you what my ideal thought process is for this. And you can interrupt me or tell me after I'm done speaking if you think I'm on the right path. So we see the cost given to us, right? It's a 2D array. I immediately think that this is going to be a greedy problem, right? But in the sense that we can sort by— in Python, the sorting function is used by key lambda, right? We can do something like key lambda and then the first element minus the second element, right? So by doing that, you get to see the differentials for— for each city, right? And if you sort it by the differentials, right, we can split it right down the middle. On one end, right, if you do, um, let's say, uh, the A minus B, right, uh, I'm gonna go straight here and I'm gonna give you the cost, uh, array right here, right? So this is kind of the way that I want to picture this, right? Let's, let's sort by a . I'll just, let's do a , just following the interview queue format right there. a minus b , right? So the essential, the underlying sorting process, not what we're going to store, is going to kind of look like this, right? So, let— before sorting, this is probably going to be— this is going to be the differentials, right? So, it's going to be negative 10, negative 170, it's going to be 350, and it's going to be 10 right here, right? So, as we can see right here, you can easily sort these, right? So let's reformulate cost by sorting it this way. So now since the second element right here is the lowest, it's -170. So it'd be 30, 120, 200 first. And then we would pick 30 here, right? So basically on the left side, n, right, up to n people, we're going to pick the a element, right? And we're going to do the same for the second element right there, which equates to 10, 20, and we're going to pick 10. And then the next one we're going to pick, the next one on the line is, it doesn't matter now because we're past the line, right? Now we're going to start picking b. So we're going to pick 20 here. And we're going to pick, uh, what is it called, 50 here, right? So the total cost, the total cost will end up 30 plus 10 plus 20 plus 50 equals, um, let's, let's, it's 110, right? And this is the minimum, right? What we're essentially doing, and it's nice that we have two to n exactly. I don't have to worry about an odd number, splitting the difference, right? It's just a little bit more work, just noted it, right? But I think I am ready to code. I think it's a fairly simple process. I'll get the, the length of the array, keep track of n. Once I reach n, I switch over to picking b, keep adding to a res array, I'll just call— I'll just use the total cost variable that I stated right here. And then once I go through the array after it's been sorted, I'll return the value.

Admiral Dictaphone: Can we go through a quick example here by chance just to see how that works with your algorithm?

Golden Eel: Yeah, of course. So when you sort this out, and I'll do the same thing that I did above here, this is going to be cost, right? So if we're sorting by ACost minus BCost, right, it's going to end up being, let's see here, minus 500 and then minus 450, right? And it's already sorted. We're going to pick 0 here and— We're going to pick 600 here, right? Because right here, this is how the array is going to look like afterwards, right? So it's going to, it's going to look like the same, right? We don't have to sort it, but it's the same process applies, right? The total cost is going to be 0 plus 600, right? And that's opposed to picking 500 and 150. And I think my algorithm still applies here.

Admiral Dictaphone: Yep, cool, that makes sense. Let's go ahead and do it.

Golden Eel: Okay, perfect. Uh, let me put out total cost right here. I'm just going to comment it just to denote that this is the return variable storing cost of interviews. And so I'm assuming that we give costs as the array based on the description, right? So I'm just gonna say, let's call this 2n equals len costs, or yeah, let's just do 2n equals len costs. Right here. And then n equals 2n divided by 2, right? We don't really need to store 2n. I think that's a little unnecessary on my part because we can just loop through, through costs, right? It doesn't really matter. Now we get to the sorting function, right? We can just sort costs in place, that's no problem. I don't think— let me just read through the question one more time to see if we're not allowed to modify the cost array. I don't believe we do. I'm going to assume that it's fine to modify it in place as opposed to doing it in creating a new array, right? We don't need to create extra space if we don't need to. So I'm just going to go ahead and do this. Key equals lambda x, x0 minus x1, right? And by the way, just because I didn't talk about base cases, a base case could be you could have a zero array, right? I might as well just do this for integer division. I don't know, like it's, it's not a relevant point. But if you have an empty array, right, we're, we're sorting the array and then we're going to iterate through the array. It does not matter. It does not matter if we get an empty array because total cost is set at 0 in the first place. It is a moot point. We don't have to care about that base case, right? So I'm just gonna, I'm just gonna go ahead and iterate through costs, right? And then I'm going to actually, might as well enumerate, right, because we both need the cost and the index. So, let me do index cost in enumerate costs, right. So, I'm gonna have the index right here. If index is greater than or equal to n, right, we need to, Choose a cost i when for sorted indices 0 to n minus 1. That's about n elements. And then we need to choose b cost i for sorted indices n to 2n minus 1, right? And then we get n indices, uh, we choose n times for both, right? So if, if index is greater than equal to n, then we do total cost plus equals to cost 1, right? That will choose the bcost right there. Else total cost plus equals cost to zero right here. Makes sense. I think that should be it. What do you think?

Admiral Dictaphone: Well, the total cost, you have to return the total cost, right? But we have to —put in a definition of a— let's just put in a definition of a function to be clean here.

Golden Eel: Yeah, that makes total sense.

Admiral Dictaphone: That way I can create a quick test case too while you're doing that.

Golden Eel: Yeah, okay, so def, uh, to_cities, um, cost_list, um, list Teachers. Right here. I think from typing import list. I think that should be fine now. Yeah, we shouldn't have any errors there. Cool. Yeah, I totally forgot to put the function declaration there, but I think this should be fine now.

Admiral Dictaphone: Yeah, let's go ahead and test with the 3 test cases that were provided by the example.

Golden Eel: Yeah.

Admiral Dictaphone: I put it on line 68 to 70 if you just want to call the function and do an assertion.

Golden Eel: Uh, lines, uh, okay, yeah, um, okay. Print. Two cities. TestCase 1. Then we'll do the same for TestCase 2 and then TestCase 3. And then let's run it. I'm gonna put out my expectations first, right? For TestCase 1, we should have, um, 30.86.

Admiral Dictaphone: Oh, 30.86. Okay. 2 should be 18.59.

Golden Eel: 18.59.

Admiral Dictaphone: And 3 should be 110.

Golden Eel: 3 should be 110. Perfect. All right.

Admiral Dictaphone: Beautiful. Looks good to me. Let's move on with the second question, shall we?

Golden Eel: We shall. Thank you.

Admiral Dictaphone: Cool. Let's do—

Golden Eel: oh, by the way, before, before we move on to the next question, do you think I kind of ramble or something a little bit too much? Should I put some pauses in between, or should we save that to the end?

Admiral Dictaphone: We'll save that to the end. We'll save it at the end. Before we do that, actually, what is the runtime complexity and space complexity?

Golden Eel: I'm glad you mentioned that. This should be If n is— I know we said 2n for cost, right? If n is the length of cost, it should be n log n right here, because that is the worst-case time complexity of TimSort for Python sorting. And then we just iterate through, um, well, of the array normally, right? So it should be O log n, and we don't use any extra space. So this should be O of 1 extra space.

Admiral Dictaphone: Beautiful. Sounds good. All right, second question. Let's get this one up. Have you done longest common prefix? I'll post the question here. See if you can go ahead and read that. You're given two arrays with positive integers, and And you need to find the longest common prefix. Let me know if you've done this.

Golden Eel: Oh, different question, but otherwise I actually haven't done this question. Okay, this question doesn't even look remotely familiar to me. Sounds good. Let's get it done. Okay. Okay. So let me read through the question really quickly. You're given two arrays with positive integers, array 1 and array 2. Prefix is formed by one or more of its digits starting from its leftmost digit, right? Mm-hmm. Okay, so I see. So 123 is a prefix of that integer, but it's not— okay. I see. Okay, so you need to find the length of the longest common prefix between all pairs of integers xy such that x belongs to ary and y belongs to array2. I see. Okay, I'm just gonna read the input and the output really quickly. Longest common prefix. Oh, so you're checking— okay, so you're checking for each number right there, I see. Okay. When I'm thinking of a naive solution, it's, it's going to be O, right? So I'm just going to try to think a little bit more intuitively before I put my head into it. Let me think on this. Bit more.

Admiral Dictaphone: Yeah, feel free to share your thoughts if you're—

Golden Eel: Yeah, yeah, I didn't want to stay too quiet. At the moment, right? So we do have— we have two arrays here. And for each element in array 2, you have to find the longest common prefix that applies for each element in array 1, right? So, trying to think right here. Okay, we don't necessarily— I'm trying to think. Hmm. We could, what we could do is instead of storing, instead of searching each element, I'm not sure if you can see my cursor or anything, I'm not gonna do that. Instead of searching on a brute force method of using each element of array2 and through and then checking for each array element, array 1, which would be O. What we could do right here is pre-compute prefixes for array 1, right? That way, that way we can— we don't have to search the array, array 1, every time and for the same for the same element right there. Precomputing this, precomputing this would be, I'm trying to think if it makes a reasonable improvement, right? So precomputing the prefixes right, to— and into a set, we can kind of do this. Here, let me think. Yeah, precomputing these prefixes into a precomputing All prefixes into a set will take O), right? Because let's say L is the longest digit in, um, in array 1, for example, or both arrays. L is the longest digit in array, and I'm not sure about what your constraints are. But especially given the integer constraints in Python, you're not going to have a super long number comparatively, right? Do you want to clarify on that? How long of the numbers are we working with?

Admiral Dictaphone: It should be reasonable within a regular, just like reasonable. Yeah, yeah.

Golden Eel: So precomputing these prefixes using the length as part of the, as part of the worst case right there makes it O, which is much better than O because n could be a humongous number comparatively, right? So once we precompute these prefixes, into this set, we search each, each digit combination. Digit combination is we search each succeeding digit within each element in ARR2, right? And Python, I mean, obviously set operation, when you're looking if something is in a set, it's O time complexity. So we don't have to worry about working with that. And this is also O, right? Because you're also going through each— worst case, you're going through the longest possible digit on each element in array 2, and there's n digits, right? So I think this would be a good, good solution to come with, right? What do you think about this idea? Do you think I'm on the right path?

Admiral Dictaphone: I think that makes sense to me.

Golden Eel: Perfect. Okay. So let me start with the function declaration, right? Let me name this correctly as well. Say, prefix, let's call it longest prefix right here. And then we will have two arrays, so array one, and then we have the typing imported right there before, so not to worry. Array two, and then return zero. Okay. Oh, what am I doing? That's a little stupid. Okay. Okay. So we will have prefix length equals to 0 initially, right? And then Let's first— we might as well just return prefix length right here just so I have it already. Let's first precompute the prefixes in array 1 for array 2 to search after.

Admiral Dictaphone: So, to clarify here, For array 2, do we also have to do the same thing in terms of figuring out the prefix, like chopping up a number into its individual prefixes and getting every single time?

Golden Eel: Um, for array 2, I think what we could do is, which I'm trying to think right here. What we could do is we could have some early stopping for array2, right? We could check if, um, I'm just going to put this above here. We could check if the element that we're on in array2, um, has a lower overall length than the current prefix length, then it's not worth checking, right? In terms of answering your question though, chopping up all the prefixes in array 2, I think that might be necessary. I think just because you check if, like, if you have like 746, right? I think it might be necessary to check 7, then 74, then 76, and 746 sequentially in order. That's what I'm thinking. Do you think that's the correct line of thinking right there?

Admiral Dictaphone: Yeah, no, I think that makes sense.

Golden Eel: Yep. Yeah. We could check if the element is already shorter is then our current longest prefix and early stop there. For array2 checking, on first mismatch, we Uh, we abort, uh, checking and then update prefix length as such. Prefix length equals max prefix length, uh, new prefix length. Okay. Or rather current prefix length, right? So that's how I would do it. First, let's precompute the prefix set for array 1. prefix_set array 1 equals set, right? And let's go into this. Let's for num in array 1. I'm trying to think right here. Let's do this. I'm not sure if this is the 100% most efficient thing right away, but my idea is to We're getting these as integers, right? My idea is to convert the number into a string, iterate— I'm trying to think right here. Yeah, okay. Iterate through it And sequentially add this— actually, give me one second. I'm trying to think about how to do this because I think string concatenation could be a little bit of an inefficient way to go about this.

Admiral Dictaphone: Oh, why are you string concatenating?

Golden Eel: Because I'm trying to iterate through each digit in num, right? So I'm trying to think of how to do that without converting it into a string, right? What I could do is I could converted to a string at first, right? Um, I'm just trying to—

Admiral Dictaphone: yeah, I think, I think basically what you're thinking, your thought process is, is you either get the first digit or you create effectively a StringBuilder in Java, but for Python, right? Yeah. One of the—

Golden Eel: I think, um, I think what we could do is, um, we can extract it digit by digit. And then, yeah, that's what we can do. We can do. Okay. We can abstract the number digit by digit, and keep going from there. Let's use the example of, of 746, right? I'm just trying to articulate this before I implement this, right? We can extract 7 from 746 by doing— give me a second.

Admiral Dictaphone: What if we do it the other way? So your, your thought process is you are putting 7 in there as a prefix, correct? Yeah, that's what about after 7?

Golden Eel: We have 46.

Admiral Dictaphone: Sorry, sorry, what, what is the next prefix after 7 that you're going to put into the URL?

Golden Eel: Oh, 74. And then what's the last one? 746. Okay, I think I, I get what you're saying. Um, we, we can, we can do this. Uh, we can extr— yeah, That's a great hint, actually. We can do— by doing 746 divided by 6—

Admiral Dictaphone: maybe not 6.

Golden Eel: No, no, no, I meant 10. We get 74, right? We first put— we first put 746 into the string, right? I mean, into the set. Yep. We first put 746 into the set, um, and then we— uh, hold on— we sequentially, um, integer divide by 10 to get each successive number that we need to get, right? So, that's great right there. We'll do this until while num— and I just wanna clarify, are the— okay, these are positive integers. That is perfect. So, while num is greater than 0, Let's do prefix_set_array1.add, or we can just do prefix_set, no need to overcomplicate things. prefix_set.add, and then we can do num integer divide by 10 right there. And that, that does our first loop. Our first loop would be Complete right there. Next, let's go to for num in array2. This actually makes things a little bit more intuitive, actually, because we can check the longest portions of the prefix before we move on, right? And then we can break early. So for num in array2, right? Let's do this. Yeah, we can do the same thing right here. While num is greater than 0, we can do if num in prefix set, we can do break. Otherwise, num integer divide by 10, right? And then now we get— we have to find what the— we have to find what the longest prefix, right? And the longest prefix— I mean, the longest common prefix is right here. Oh yeah, I just needed to check really quickly. Okay, so the longest common prefix is determined by the digits, right? The total number of digits, right? So let's compute that, and then we'll have digits equals to 0 at first because we have— we do have the 0 case. Right here? I mean, that's when you don't find a prefix. This is when prefix length— let's call this curr_prefix_length. curr_prefix_length is 0. When a prefix is not found, right? So we're gonna do this right here. So to find how many digits Something is— we can find like the log of it, right? But that's a little bit like log base 10. That's a little bit, I would say, complicated for this kind of setting. We could have a counter, right? Now that we found our num, right, we can still do while num is greater than 0. We can do curr.prefix.length += 1. And this is still not going to affect the time complexity. We're just going to keep dividing by 10 until we get to 0, right? And then finally, um, CURP prefix— oh, no, no, no, right here. Prefix length equals max CURP prefix length and CURP prefix length. Right here. Oh, no, no, okay. So, let me just make this camelCase as well. I mean, not camelCase, underscore as well so that it just matches and I think that should be set. Why is this not closed? Oh, I see. Perfect. Yeah, let me do another dry run just to understand this better and just so I can explain my process thoroughly before we start testing, right? So we have the prefix length that we are trying to return. That's our return variable. And what this function is trying to Pursue, right? We have the prefix set that we talked about. We have— we iterate through each num in the first array, and we add each of the prefixes in for each number, right? And we do that by integer dividing by 0 for each one, and then prefix set gets precomputed perfectly right there. Then we go on to the second array and we integer divide until we find a prefix that's in the prefix set, the precomputed prefix, right? If it reaches zero, that means the prefix isn't found. The curr_prefix_length is set default as zero because it assumes a prefix isn't found. And then we continue inner divide— integer dividing by zero because that denotes how many digits are left after we found the prefix, right? Then we update the prefix length with the current prefix length on that number in the second array. Then we finally return the prefix length. I do think this is a pretty— this kind of covers every ground right here. Oh yeah, this, that. Little thing right there should help. Yeah, and I think it should be good.

Admiral Dictaphone: Nice. All right, let's test it. Okay. Let's just do this. And then feel free to plug that in and create the test case.

Golden Eel: Perfect. I will do just that.

Admiral Dictaphone: Uh, no, you both array arrays go in one time and in one. Oh, oops.

Golden Eel: Yeah, I'm a little brain fart right there. Uh, did you mean it like this or the other? Like, yep, array one. Yeah, perfect, you got it. Oh. I kind of ran it without— yeah, 3 and 0. Yeah, I think that does make— yeah, that is expectation.

Admiral Dictaphone: Let's run through one more custom test just to make sure we cover all of our bases here. Mm-hmm. And then let's do 2002. 30 and 9. Okay, and then set this as our third. Perfect.

Golden Eel: And we have 3 at the end.

Admiral Dictaphone: Uh, it should be B, larger than 3. Oh, size. Size, size, size, size. Yes, yes, thank you. Yep. Cool, that works. That, yeah, you did well. Okay, time and space complexity.

Golden Eel: Okay, perfect. Well, I talked about it early on about the time complexity, right? Yep. I'm not sure if mentioning the digit length is that relevant, but I just wanted to mention that whatever the longest digit is, longest possible, whether it's 32-bit or 64-bit, however many the longest possible integer is, along with n, it's O of ln because that's how many prefixes we're computing and searching for. That's going to be— the time complexity right there. And space complexity is going to be the same because that's what— that's the size of what prefix set is going to be. It's going to include L digits for N elements, right? So space and time complexity is both going to be O.

Admiral Dictaphone: Cool. That looks good to me. And that is, yeah, that's pretty much the interview. I will hand it over to you to do a self-evaluation of how you thought the interview went before I provide my thoughts and notes.

Golden Eel: Yep. Yep. So I think I just, some things are nitpicking, some things I do want to work on a little bit. I got stuck right here, right in the lines 121 through 127, when I was trying to formulate how to, um, extract each, um, integer properly. I became a little bit too fixated on trying to get 7 first rather than keeping my options open, going from 746 down, um, to 74 to 7, right? Um, just, I just need to keep that in mind. I did need a little bit of a nudge from you right there, which I appreciate, but, uh, it would be better if I just did that alone, right? Um, maybe I could have talked a little bit more about edge cases, uh, in both of my processes. I think I covered it better on the first one. I don't think there were, there needed to be edge cases met on longest prefix, but just mentioning them in passing or acknowledging them could be a little bit better, just so that we acknowledge it, move on. It's not necessarily something that needs to be detailed upon at the beginning, right? We can talk about it a little bit later, but that's just something to keep in mind. And maybe I ramble a little bit too much, just in the way I speak. I feel like sometimes you try to get a word in, and I was kind of in my thought process, maybe I do need to step back a little bit, have you jump in, or kind of talk a little slower, segment my thoughts a little bit more. What do you think?

Admiral Dictaphone: Yeah, personally, I think it's very dependent on the interviewer, and unfortunately, it's really dependent on whether or not they like that type of thought process or they dislike that type of thought process. And I'm definitely okay with it. And I think it's a positive because overexplaining your thoughts to where I understand everything is just significantly better than underexplaining. But I do see the perspective where some people might think, oh, you know, he's talking a bit too much that to where I'm not able to provide a hint. But I don't think that happened in this interview because you were able to provide your line of thought so clearly and it was correct as well, right? So we didn't get to that experience. And when you did have a part where it wasn't wrong, but it wasn't— you weren't finding the correct solution fast enough, you— it was just empty silence, right? Which is totally fine as well. I think that that's totally normal. And during an interview, as long as you say, hey, give me a minute to think about it, it'll be welcomed. There's no problem there. And yeah, so without further ado, let me just talk through my process here. You were able to quickly define the edge cases, especially in the first problem, reason about the problem statement, speaking out loud, confidence. And I think this is one thing as well, you have very, you have a lot of confidence in speaking. And I think that definitely comes up as a positive. So just continue to iterate through your processes and thought process and make sure that comes out. There might, again, just to really nitpick, there may be an interviewer who doesn't— who wants the, is this okay? Or am I doing it correct? Like a follow-up to make sure that you're aligned, because again, if you think of a problem and of a solution to a problem and it may not be correct, the interviewer may want to make sure that You're checking in with the interviewer, but again, I, yeah, depends on the interviewer. It depends on the problem. There's just a lot of variables and this particular interview when doing this mock interview, I think that there's really, there's really no problem, right? You solved 2 questions, 2, I think, [REDACTED] mediums under 40 minutes, maybe 45 minutes. You identified both problems really well. You again, clear the edge cases. When talking about that minor hint to be super effective, it's barely a concern. I think that that's totally fine to get hints, especially from an interview. So, one really quick fun fact. If you ever want to do a line 143 where you are trying to find the length of an array, I had to look this up. I think I actually didn't know this, but if you do math.log, yeah, I believe it is, this gives you the evaluation in order 1 runtime as opposed to log L where L is the length of the number. But yeah, I wouldn't know that.

Golden Eel: I did mention in passing that we could use log base 10. Yeah, just for simplicity's sake and for the fact that it's not gonna affect worst case, I just decided to scrap that line of thinking. But yeah, importing math and then doing that log10 would be more efficient. Absolutely.

Admiral Dictaphone: Yeah, so I think the other really good positive thing that you did, especially on the second problem, was go through a dry run-through of the code. I think that is really important that people, a lot of people miss actually, and being able to do that without being prompted just really stands out as a, oh, this person not only finished the code really quickly, but also is going to review it to ensure that there aren't any bugs or mistakes. And it aligns really well with, you know, an interviewer who's trying to also figure out what you wrote, so. Yeah, I mean, that's pretty much it. I wish I had more helpful tips. But again, you kind of blew this interview out of the water. So there's really not much more I can provide.

Golden Eel: No, thank you. Honestly, I didn't even think about like, you know, doing the function declaration. And I really needed to like do a dry run because sometimes I get kind of cold feet before an interview, right? And it's really a mentality thing because I know I can nail this, but I don't want to like, you know, kind of tread water in the moment. And kind of doing this and kind of getting this feedback is like really important to me. So I appreciate it. Would you provide feedback after the interview is over in that little form?

Admiral Dictaphone: Everything that I've said so far plus the questions will be in in the interview feedback, so you should be able to look through it and be able to do it again if you want on [REDACTED] and just look through our feedback as well.

Golden Eel: Awesome. Thank you. Thanks so much for your time.

Admiral Dictaphone: Ah, thank you, and good luck on your interviews.

Golden Eel: All right, appreciate it.

Admiral Dictaphone: You have a good day. You too, bye. Bye.