We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free
Please read our definitive guide on Microsoft's hiring process and questions
Python Interview with a Microsoft engineer
Watch someone solve the reverse nodes in k-group problem in an interview with a Microsoft engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.
Interview Summary
Problem type
Reverse Nodes in k-Group
Interview question
Given the head of a linked list, reverse the nodes of the list k at a time, and return the modified list. k is a positive integer and is less than or equal to the length of the linked list. If the number of nodes is not a multiple of k then left-out nodes, in the end, should remain as it is. You may not alter the values in the list's nodes, only nodes themselves may be changed. Input: head = [[1,2],[3,4],[5...], k = 2 Output: [2,1,4,3,5] Input: head = [1,2,3,4,5], k = 3 Output: [3,2,1,4,5] Input: head [1,2,3,4,5,6,7,8] k = 3 Output: [[3,2,1],[6,5,4],7,8]
Interview Feedback
Feedback about Green Wolf (the interviewee)
Advance this person to the next round?
NoHow were their technical skills?
3/4
How was their problem solving ability?
2/4
What about their communication ability?
4/4
Probing question ``` Given the head of a linked list, reverse the nodes of the list k at a time, and return the modified list. k is a positive integer and is less than or equal to the length of the linked list. If the number of nodes is not a multiple of k then left-out nodes, in the end, should remain as it is. You may not alter the values in the list's nodes, only nodes themselves may be changed. Input: head = [1,2,3,4,5], k = 2 Output: [2,1,4,3,5] Input: head = [1,2,3,4,5], k = 3 Output: [3,2,1,4,5] ``` ### Strengths - Overall very strong communication., clear and easy to follow. - Took time to break down the problem. Seemed a bit stumped by what the question was asking - Quick tip on this, it is always okay to ask the interviewer for more examples, or a run through. This is usually my go to approach to get interviewers to explain confusing or super long prompts. - Overall good job with the run through. It was clear you understand the request. - Communicated thought processes as they code which is beneficial. - Clearly understands complexity analysis. Good job on this, a bit of speed would certain help still, but overall it was good to see that you understand what it all entails. ### Points of Improvement - With practice, patterns associated with questions become more apparent which can speed up how fast we start coding. In terms of a breakdown, you can aim to start coding after at most 7 mins or so. - When the input format is not specified, try and leverage a structure that may be more friendly for you. An example, a list might actually be easier to work with. You may n - I love the depth of planning but this can end up consuming a lot more time than you want. Aim to combine a mix of verbal and written communication to run through proposals as fast as possible before delving in. My go to approach has always been ideating and doing complexity analysis verbaly, only noting the solution steps and final complexity. This ensures I can ramble on if need be until a solution sticks, while not documenting this ideation process since thats when you make a lot of mistakes. Also make a point to engage your interviewe in this phase, get as much info from them at this stage as possible. You can get away with a lot. - Gave a minor hint to a less optimal approach that builds on the same idea, using an aux space. Quick tip here, optimal solutions can sometimes be harder to code. If you have a sense of the less optimal approach, feel free to code it but mention that you are aware of an optimization that you can leverage down the line. Software Engineer Study Guide https://docs.google.com/spreadsheets/d/19vhVZ18LAvZTtKWn-cuJzto3AMpJ1npYK4vDWppDnrQ/edit?usp=sharing Coding Interviews starter questions # Starter Questions This list here is not exhaustive. Use it more as a source of patterns. The Blind75 or Neetcode 150 list may also be worth a look but they are not broken down by pattern: Blind75: https://www.techinterviewhandbook.org/best-practice-questions/ Neetcode 150: https://neetcode.io/practice ## Pattern 1: Arrays Here are some additional examples for the array pattern: 1. Search in Rotated Sorted Array - Difficulty: Medium, Estimated Time: 45 min 2. Jump Game - Difficulty: Medium, Estimated Time: 40 min 3. Merge Intervals - Difficulty: Medium, Estimated Time: 35 min ## Pattern 2: Linked Lists 1. Reverse Linked List - Difficulty: Easy, Estimated Time: 25 min - [Link](https://leetcode.com/problems/reverse-linked-list/) 2. Linked List Cycle - Difficulty: Easy, Estimated Time: 30 min - [Link](https://leetcode.com/problems/linked-list-cycle/) 3. Merge Two Sorted Lists - Difficulty: Easy, Estimated Time: 35 min - [Link](https://leetcode.com/problems/merge-two-sorted-lists/) 4. Palindrome Linked List - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/palindrome-linked-list/) 5. Intersection of Two Linked Lists - Difficulty: Medium, Estimated Time: 45 min - [Link](https://leetcode.com/problems/intersection-of-two-linked-lists/) ## Pattern 3: Strings Here are some additional examples to replace the easy ones with more challenging ones: 1. Reverse Words in a String - Difficulty: Medium, Estimated Time: 30 min - [Link](https://leetcode.com/problems/reverse-words-in-a-string/) 2. Group Shifted Strings - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/group-shifted-strings/) 3. Longest Substring with At Least K Repeating Characters - Difficulty: Medium, Estimated Time: 50 min - [Link](https://leetcode.com/problems/longest-substring-with-at-least-k-repeating-characters/) 4. String Compression - Difficulty: Medium, Estimated Time: 30 min - [Link](https://leetcode.com/problems/string-compression/) 5. Palindromic Substrings - Difficulty: Medium, Estimated Time: 50 min - [Link](https://leetcode.com/problems/palindromic-substrings/) ## Pattern 4: Trees 1. Path Sum III - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/path-sum-iii/) 2. Construct Binary Tree from Preorder and Inorder Traversal - Difficulty: Medium, Estimated Time: 45 min - [Link](https://leetcode.com/problems/construct-binary-tree-from-preorder-and-inorder-traversal/) 3. Binary Tree Zigzag Level Order Traversal - Difficulty: Medium, Estimated Time: 50 min - [Link](https://leetcode.com/problems/binary-tree-zigzag-level-order-traversal/) 4. Subtree of Another Tree - Difficulty: Easy, Estimated Time: 30 min - [Link](https://leetcode.com/problems/subtree-of-another-tree/) 5. Diameter of Binary Tree - Difficulty: Easy, Estimated Time: 30 min - [Link](https://leetcode.com/problems/diameter-of-binary-tree/) ## Pattern 5: Dynamic Programming 1. Longest Palindromic Substring - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/longest-palindromic-substring/) 2. Maximum Subarray - Difficulty: Easy, Estimated Time: 30 min - [Link](https://leetcode.com/problems/maximum-subarray/) 3. House Robber II - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/house-robber-ii/) 4. Counting Bits - Difficulty: Medium, Estimated Time: 35 min - [Link](https://leetcode.com/problems/counting-bits/) 5. Longest Increasing Path in a Matrix - Difficulty: Hard, Estimated Time: 90 min - [Link](https://leetcode.com/problems/longest-increasing-path-in-a-matrix/) ## Pattern 6: Hash Tables 1. Top K Frequent Elements - Difficulty: Medium, Estimated Time: 35 min - [Link](https://leetcode.com/problems/top-k-frequent-elements/) 2. Intersection of Two Arrays II - Difficulty: Easy, Estimated Time: 25 min - [Link](https://leetcode.com/problems/intersection-of-two-arrays-ii/) 3. Longest Substring with At Most Two Distinct Characters - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/longest-substring-with-at-most-two-distinct-characters/) 4. Minimum Window Substring - Difficulty: Hard, Estimated Time: 90 min - [Link](https://leetcode.com/problems/minimum-window-substring/) 5. Group Anagrams - Difficulty: Medium, Estimated Time: 35 min - [Link](https://leetcode.com/problems/group-anagrams/) ## Pattern 7: Binary Search 1. Find Peak Element - Difficulty: Medium, Estimated Time: 35 min - [Link](https://leetcode.com/problems/find-peak-element/) 2. Search a 2D Matrix - Difficulty: Medium, Estimated Time: 30 min - [Link](https://leetcode.com/problems/search-a-2d-matrix/) 3. Kth Smallest Element in a Sorted Matrix - Difficulty: Medium, Estimated Time: 45 min - [Link](https://leetcode.com/problems/kth-smallest-element-in-a-sorted-matrix/) 4. Search in a Sorted Array of Unknown Size - Difficulty: Medium, Estimated Time: 45 min - [Link](https://leetcode.com/problems/search-in-a-sorted-array-of-unknown-size/) 5. Median of Two Sorted Arrays - Difficulty: Hard, Estimated Time: 90 min - [Link](https://leetcode.com/problems/median-of-two-sorted-arrays/) ## Pattern 8: Graphs 1. Minimum Knight Moves - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/minimum-knight-moves/) 2. Cheapest Flights Within K Stops - Difficulty: Medium, Estimated Time: 50 min - [Link](https://leetcode.com/problems/cheapest-flights-within-k-stops/) 3. Course Schedule - Difficulty: Medium, Estimated Time: 45 min - [Link](https://leetcode.com/problems/course-schedule/) 4. Number of Connected Components in an Undirected Graph - Difficulty: Medium, Estimated Time: 35 min - [Link](https://leetcode.com/problems/number-of-connected-components-in-an-undirected-graph/) 5. Word Ladder - Difficulty: Medium, Estimated Time: 50 min - [Link](https://leetcode.com/problems/word-ladder/) ## Backtracking 1. Letter Combinations of a Phone Number - Difficulty: Medium, Estimated Time: 35 min 2. Subsets - Difficulty: Medium, Estimated Time: 35 min 3. Permutations - Difficulty: Medium, Estimated Time: 40 min 4. Combination Sum - Difficulty: Medium, Estimated Time: 50 min 5. Word Search - Difficulty: Medium, Estimated Time: 45 min ## Depth First Search (DFS) 1. Number of Islands - Difficulty: Medium, Estimated Time: 40 min 2. Surrounded Regions - Difficulty: Medium, Estimated Time: 45 min 3. Max Area of Island - Difficulty: Medium, Estimated Time: 45 min 4. Pacific Atlantic Water Flow - Difficulty: Medium, Estimated Time: 50 min 5. All Paths From Source to Target - Difficulty: Medium, Estimated Time: 45 min ## Breadth First Search (BFS) 1. Surrounded Regions - Difficulty: Medium, Estimated Time: 45 min 2. Clone Graph - Difficulty: Medium, Estimated Time: 40 min 3. Shortest Path in a Binary Matrix - Difficulty: Medium, Estimated Time: 50 min 4. Walls and Gates - Difficulty: Medium, Estimated Time: 45 min 5. Course Schedule II - Difficulty: Medium, Estimated Time: 45 min ## Greedy Algorithms 1. Jump Game II - Difficulty: Hard, Estimated Time: 90 min 2. Best Time to Buy and Sell Stock II - Difficulty: Easy, Estimated Time: 25 min 3. Task Scheduler - Difficulty: Medium, Estimated Time: 50 min 4. Minimum Number of Arrows to Burst Balloons - Difficulty: Medium, Estimated Time: 45 min 5. Jump Game - Difficulty: Medium, Estimated Time: 40 min ### Recursion 1. Fibonacci Number - Difficulty: Easy, Estimated Time: 20 min - [Link](https://leetcode.com/problems/fibonacci-number/) 2. Climbing Stairs - Difficulty: Easy, Estimated Time: 20 min - [Link](https://leetcode.com/problems/climbing-stairs/) 3. Binary Tree Maximum Path Sum - Difficulty: Hard, Estimated Time: 90 min - [Link](https://leetcode.com/problems/binary-tree-maximum-path-sum/) 4. Unique Paths III - Difficulty: Hard, Estimated Time: 60 min - [Link](https://leetcode.com/problems/unique-paths-iii/) 5. Combination Sum III - Difficulty: Medium, Estimated Time: 35 min - [Link](https://leetcode.com/problems/combination-sum-iii/) ### Dynamic Programming 1. Longest Increasing Subsequence - Difficulty: Medium, Estimated Time: 45 min - [Link](https://leetcode.com/problems/longest-increasing-subsequence/) 2. Unique Paths - Difficulty: Medium, Estimated Time: 30 min - [Link](https://leetcode.com/problems/unique-paths/) 3. Coin Change - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/coin-change/) 4. Best Time to Buy and Sell Stock - Difficulty: Easy, Estimated Time: 25 min - [Link](https://leetcode.com/problems/best-time-to-buy-and-sell-stock/) 5. Word Break - Difficulty: Medium, Estimated Time: 40 min - [Link](https://leetcode.com/problems/word-break/) For communication, here are some example filler statements to use to bring interviewers into the convo while timeboxing yourself: Example filler phrases: 1. "Am I going in the right direction with this?" 2. "Is this the kind of solution you had in mind?" 3. "Would you like me to go deeper into this aspect?" 4. "Do you have any preferences on how I should proceed?" 5. “Does this make sense to you?” Timeboxing strategy 1. **Set a Mental Timer**: Before answering, set an internal goal for how long your response should be, like 1-2 minutes, and try to stick to it. 1. This can involve limiting your scope to just the problem/ Solution 2. **Structure Your Answers**: Use frameworks like the STAR method (Situation, Task, Action, Result) to structure your answers. This provides a beginning, middle, and end to your responses. 3. **Practice with a Timer**: Before the interview, practice answering common questions using a timer to get a feel for how long 1-2 minutes is. 1. May not be viable in an interview, but do this with async practice. It comes in handy to built that communication muscle 4. **Bullet Points**: Mentally outline 2-3 main points you want to cover in your answer and stick to them. 1. Scoping your thoughts again to avoid rabbit holes. 5. **Pause for Feedback**: After making a point, pause briefly to see if the interviewer is indicating (verbally or non-verbally) that they'd like more detail or if they're satisfied with your answer. 1. Do this often! It really makes interviews natural and forces you to practice brevity. 6. **Open-Ended Closure**: End your answer with a phrase like, "Does that answer your question?" or "Would you like me to go into more detail on any point?" This gives the interviewer a chance to guide the conversation if they want more information. 1. See the filler list above. You can use one, you can use many, judge by context. 7. **Limit Examples**: While real-world examples are valuable, avoid giving multiple examples for a single point unless asked. 1. 2-3 at most, 1 good one is usually enough. 8. **Practice Brevity**: Regularly practice answering questions in a concise manner, even in everyday conversations, to build the habit. 1. STAR can help here. You can also use breath count or sentence count here. I usually try to keep things within 2 breaths before bringing the interviewer in, with a pause between each breath. 9. **Deep Breaths**: Never communicate yourself out of breath, make this a heuristic. Take a deep breath, then communicate for 1 or two cycles. 10. **Summarize**: If you find you've been speaking for a while, wrap up with a brief summary of your main points to bring closure to your answer. 1. Do a quick recap after particularly long points, or once you are done with a probing type of conversation. Use these as chances to also document. 11. **Pre-prepare Answers**: Anticipate common interview questions and prepare concise answers in advance. This reduces the chance of rambling as you're not constructing your answer on the fly. 1. We can discuss this further, but with system design especially, there is quite a lot that can be pre curated.
Feedback about The Legendary Avenger (the interviewer)
Would you want to work with this person?
YesHow 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
Interview Transcript
The Legendary Avenger: Hello.
Green Wolf: Hi. Can you hear me?
The Legendary Avenger: I can hear you. Can you hear me?
Green Wolf: Well, I can.
The Legendary Avenger: Awesome. All right, so let's get started. Maybe just do some quick intros here and then kind of like, basically set the tone up for the sessions we're going to have here. I'll start here. I'm Brian. Used to work at Microsoft for about two years, and I was working specifically as a backend and machine learning engineer, and I specialized in building data infrastructure. And I'll just give you a quick recap of what I know so far and then you can do the intro. But my understanding here is you have at least four years of experience and you have a software engineering role lined up. And the area you want to focus in in this regard is essentially problem solving and identifying more optimal solutions really quickly, like in all the scene that are extra perspective, so to say. And you also listed operating systems as a specialty you would like to look into as well as full stack and back end engineering. But, yeah, at least in your own words. Maybe just run me through what you have lined up as well as what you're looking to get out of this.
Green Wolf: Okay. Yeah, I know I filled out that survey and there's a lot of open ended text fields. So, yeah. My name is James. I'm a software engineer. Well, I have been at a software engineer since 2014, was at Amazon most of my career. And then prior to that I was at Seagate working on embedded systems. And then I left Amazon at the beginning of 2022 just to try something new, went to startup, got laid off, and then recently joined [Redacted] as a consultant just to figure out what I want to do. Because I'm kind of in this limbo stage of I'm not sure what I want to do. But I do enjoy tech in many areas. I also really enjoy writing. I'm at a crossroads in my career that there's just so many avenues and ways to slice tech careers and tech adjacent careers that I'm still trying to figure it out. I don't have anything lined up, actually. I'm in the process of trying to line them up. Unless you mean line up, meaning I've applied to places, but no, as of right now, I don't have anything lined up. So I've like eight years of professional experience, over ten of just like internships and other stuff, if you want to add.
The Legendary Avenger: That makes sense. Yeah. And I appreciate this kind of transparency. Is there like, a particular reason? Actually, it's listed as standard. Never mind. I thought it was listed as Microsoft.
Green Wolf: But I did list Microsoft actually because I'm interested in Microsoft structure. Just because it's completely separate from other jobs that I've interviewed with in the past. Obviously Microsoft's not a Linux house or other operating systems. That's what most of my career has been. But there's so many things that Microsoft does that it's interesting. Obviously it's a very large company and you can't broadbrush it like that. But just that culture is something I would like to break into for many reasons. I'm not sure know my biggest restraints and reservations are communicating that clearly and myself clearly to Microsoft. Not that if I can do the job or not, but that's half the battle for a lot of people, right? So how to put my best foot.
The Legendary Avenger: Forward and full transparency? I actually have a very similar journey. I also have about seven, eight years of experience approaching. I've pretty much worked both in big tech. My first foray was basically at Microsoft. And then from there I went to Qualtrics and I wanted that up in responsibility, so to say. And unfortunately they had layoffs. And so with the recent advent of AI tools I kind of decided okay, let me take a step back, jump back into the startup world. And so I came into this startup. What I'm doing is basically building pretty much every AI service that they'll need for a while. So it's ranged from the stereotypical LLM because everybody's obsessed with that all the way down to some classical techniques like collaborating filters. But essentially it's been full ownership. And now I'm kind of looking to go back to big tech. And one thing I know I'm really good at is actually problem solving, especially in the context of an interview. That's the one thing that I feel I usually am very passionate about. And I enjoy mentorship even more so than going through interviews themselves. But I've also made it a habit to actually go through interviews even when I'm not looking to change a job, just to get a sense of what questions they ask, what the process looks like. Because clearly I'm trying to also make a career of that. And so hopefully I will have tips as we at least go through these sessions that will also help you in that regard, just to make sure that if you want the option, you can get it, because that's usually the core goal for me, at least as an engineer. I really wish we all had the ability to just jump whenever we want and easily go through this process, because frankly interviews suck. But hopefully this will be of benefit in that regard. And maybe it also clarified, I'm assuming you've done this kind of interview before, given you at Amazon. Have you ever gotten a sense of what you're good at and what you struggle with? Just to make sure we can also drill down and focus the set of.
Green Wolf: Interviews we have, appropriately so asking what I'm good at or strengths in the context of interviews or just generally as an engineer?
The Legendary Avenger: Yeah, we can speak of it generally, even generally speaking, but in the context of interviews, because I'm assuming that's the whole purpose of this. But I think if you, let's say, have a domain you're targeting, I can think of interviews in that context.
Green Wolf: Yeah, okay. There's a few. I mean, some of it just comes down to practice. I guess. I'll roll it back a little bit. I'm fine for the most part on behavioral and explaining myself. I got to do the due diligence to map culture paradigms to my experiences and whatnot and explain how my seniority. But when it comes down to system design, in those moments, system design problems and then novel coding interview questions, I'll get stumped by simple ones. Obviously these aren't skills mean we tell ourselves we're not going to let those fatigue and atrophy, but they do inevitably. The Amazon interview process was grueling and I got through that, but it took a lot of practice. System design is something that I did and do all the time. But when you're in a situation where it's an hour, I just struggle to break it down and treat it as a pair programming session or a discussion more than I'm trying to find the right answer. And same with coding problems. It's like, okay, maybe they ask me some write some function that does some basic conversion, and then I get locked up on the fact I'm like, I don't know what that conversion is. Instead of me talking to them about that, I just sit there and kind of finangle myself. So it's really just practicing with the framework of creating a discussion, working through the problems. Obviously getting them right is one thing, but it's really making it a conversation that I'm struggling with and also just how to present my approaches in a way that seems that I'm not rambling. Sometimes I'm like, I think it's this. And then I double back and say, I don't know. And then what do you think? Obviously it depends on the interviewer on the other side and whether or not that they think, or that they're going to treat the same way or not. Then there's simple ones like do fizz, buzz, and it's not that easy, but ones that are easy. I'm like, oh my God, I haven't done that forever. My last three years have been gluing together cloud architecture patterns and then automating that. Not writing these novel programs, it's kind of that balance. And what I'm looking for right now is I'm sitting here by myself every day at home trying to build a structure of like, where do I need to deviate my attention and resources? Obviously just practicing and iterating. But then system design seems like it's like read a design that seems hard to practice for me unless it's.
The Legendary Avenger: Makes sense. And I'll be frank with you, as I said, you can tell even as an interview, I'm not going to sit here and tell you interviews are perfect. They are honestly bullshit. But what we're going to try and do here is give structure to the chaos, because that's essentially what it is. And then here's the other reality I'll give you here. And I think fortunately, your experience, so you get it. It also comes with an element of luck. Some interviews are just crap, and when you encounter those kinds, really, there isn't any way to really escape it other than just making sure you do your part and then hope for the best. But under the assumption that most interviews will be good, we'll try and structure it. And we'll try and structure the process for you such that you'll always show the most knowledge in any interview. But even before that, I wanted to at least give you an initial proposal and reiterate on this before because I also want to make sure we use this session to at least go through one exercise so that I get a feel of where you are. So we can maybe have this first session and maybe the second session focus on coding interviews. And then the third session can focus on design interviews. And then on the feedback side, especially on the second session, I can make it system design heavy. And then for these first two sessions, because they are coding interviews, I can focus more so on, how do you call it? Like, in this case, we can do like more of a mentorship just to get a sense of where you are. So it would be tricky. And then I'll give you resources for the second one. It will be more of like practice, but under the assumption that you'll have had the time to at least go through the process just to get a sense of how comfortable you are with the process. Then I'll make sure I come in with a curated list of resources, recommend them for the third session. Then we can have that. And throughout that time, I'm assuming they've added you to the slack channel. I will be available in case you have questions. Basically, if you want to ideate or if you think some resources are not clear, we can do that. We can just connect async and I'll be happy to share any other resources you need. What do you think of this plan?
Green Wolf: That sounds good because honestly, it's just getting and doing some of these things and talking through it. I didn't know there was an interviewing IO slack thing.
The Legendary Avenger: She will be able to add you to this channel where you can connect with not just me, but there's actually a bunch of other interviewers there too, who usually share resources. And not just interviews, but also candidates. So you can even get a sense of success stories, what some other people looked at. In case, let's say you're not just interested in Microsoft, you can even ask questions on the Google process, et cetera. So there is a lot of gain to it in that you can even get insight into who's hiring, what the heck was asked, if that's ever posted, and it's just a good place to be in, especially if you're in that zone where you could potentially interview.
Green Wolf: Okay, yeah, it sounds good. All right.
The Legendary Avenger: And then I have a silly because for this one you're going to focus on coding. Do you mind selecting the language you're going to use? That way I can just quickly probe you on this. Let's just do.
Green Wolf: Okay.
The Legendary Avenger: This is literally a presence question because I've always realized this funny thing about my candidates. So I give you two questions. This is question number one. You don't have to solve it yet. That's question number one. And then the second question. Give me 1 second. Do the heck is this? It's fairly straightforward. I just want to get a sense of do you prefer questions with long descriptions, or are you usually the kind who gets stumped when there's too much information there? Or do you prefer quick straight up? This is the prompt in two sentences. Here's an example. Get started.
Green Wolf: I guess I'm indifferent. I don't mind longer ones. I mean I'll sit there and parse it longer. It just depends if the exercise is for me to pick out details. Yeah, makes sense.
The Legendary Avenger: So these are two examples I was essentially adding here. So with this here, you can see it's slightly different, but it's shorter. So the reason I'm asking this is because I've met candidates who are really good, but the moment you do this for them, they're like, freaking hell, what's going on? And so typically, I usually want to know where a candidate is comfortable before we even start. That way we can even look at, let's say, breaking down the problem even before delving into it. But, okay, in your case, because we can do it short in time. So let's try and attempt this second one because I want to also get a sense of how you go through an interview. So let's assume we're in interview mode and I'm going to keep track of some notes and just get a sense of how you go through the typical coding interview. So let's make an attempt to solve this, see how you go through it, and I'll provide some more examples. And then on my side, I'll take some notes and ask questions as we go. Okay?
Green Wolf: Okay. All right, buckle up I guess, already. Okay, so given the head of a linked list, reverse the nodes of the list k at a time, reverse the nodes of list k at a time and return the modified list at a time. K is a positive integer and is less than or equal to the length of the length list. If the number of nodes is not a multiple of k, then left out nodes in the end should remain as it is, may not alter the value of the list nodes. Only the nodes themselves may be changed. Okay, let me try to parse this again. So far we know we're like given a link list. Wow. Caps lock on linked list, reverse the nodes of linked list k. So link list k. Right. So I'm assuming it's called k link list input. Is k a linked list? Is it coming as a head or k equals two? Okay, so given the head of a linked list, reverse the nodes of list k at a time. K at a time. So what do you mean k at a time here? K at a time meaning three, like if k is two. Okay, two at a time. Reverse two at a time meaning. So if it's 123-451-2345. Okay, so you're evaluating k nodes at a time and swapping their positions in place.
The Legendary Avenger: Precisely if you split it into k size chunks, right?
Green Wolf: Yeah. K is a positive venture, less than or equal to the length of the list. So this is a guaranteed k is a positive integer and less than or equal to length of the link list. If the number of nodes is not a multiple of k, then the left out nodes in the end should remain as is. Okay, so if it's not a multiple k, the left out nodes are at the end of the list. You determine what the end is. Right. So in this case, the length of this one was 1235. And so the fifth one stayed in place because it's not a multiple of two in this case. Right, hold on. If the number of nodes is not a multiple of k, then the left out nodes. So what? A left out node.
The Legendary Avenger: If you look at the second example, it might be better for that analysis.
Green Wolf: Constraints and definitions here. Okay, let's just work on definitions for question k is positive. We know that left out nodes in this case are linked list nodes that are not multiple of k. So position of linked list nodes, right? Is that what that means? Is that like number of nodes, not a multiple of k, then the left out nodes. So trying to define left out nodes here, meaning the case or the nth node. Go ahead.
The Legendary Avenger: I was going to look at this. If we look at the example on line 14. So if we just pick, let's say the first three, because our k is three, that's okay. We can easily reverse those now for the next three by virtue of our input not being a multiple of k, it means that we'll always have that residual set of elements which are not really adding up to the count k. And when we have those, and an example is this four five, we just leave them as is. So we will reverse three to one and then leave the four five as is. Do you see that?
Green Wolf: Yes. Got it.
The Legendary Avenger: If we were to generalize this, if we had, let's say, 1234-5678 and our k is three, what will the output for that be, by the way? Assuming I just take a stab at it. Print out the output for me here.
Green Wolf: Oh, you okay? Hello, can you hear me?
The Legendary Avenger: Yes, I can hear you now. Some reason I lost you for a second there.
Green Wolf: So you're saying, tell me what this would be, right. What would the output essentially be exactly? Okay, so k is essentially defining our k. It's defining our window size of what? Our window size for reversal. So K three build a window size three and reverse those and then continue to the next. And once we've reached three, we reverse those and then we kind of reset the window and then go to the next, build another window if we can, so on and so forth. Right. Okay, so this one would be three, two, one, and then six, five, four, and then seven, eight would remain the same because we weren't able to build a window of. What is this right here? This open? Are you talking to me? Was this your example for output? This empty list here?
The Legendary Avenger: Okay, just remove that.
Green Wolf: Yeah.
The Legendary Avenger: Can ignore it.
Green Wolf: So seven and eight would remain in their place because we weren't able to build a window that satisfied the constraint of our window size. Right. So that's kind of the grouping there. So you may not alter the values in the list nodes, only the nodes themselves. And so only the nodes themselves, meaning you can change what they're pointing to and what they're change their order. You're not changing values. I can't assign node ones value three and swap their values in place. I have to be updating the pointers of the linked list to different spots. Okay, so from what I kind of like at a high level, it's going to be establish a window for reversal, reverse elements within window and then continue and then build the next window. And then, so base cases here, like some things we need to think about is start reversal only. Okay, so start a reversal. Once we've established the window size matches. So k is three, k is probably sitting k at a time. So we always know that we're going to have our minimum window sizes has to be k. So we can't start reversal until we've released, we've reached a k. So window size goes k or Min window size. So established window for reversal, list of k nodes, reverse elements within window and then continue to next window building. There's probably a better way to say that. Continue. Okay, reverse elements of endendo window, start, move window, move window to end of reversed or completed window. Start new window after reversed or completed. This one's more established. Window for reversal. List of k nodes, reverse elements within the window and then iterate. Okay, so other things we need to think about. So k, do you want me to worry about like if the k is too long, like if it's greater than the length of the link list? No, if the node nodes is not a multiple of k. So if it's the same length as the list, then we got to reverse the whole list precisely.
The Legendary Avenger: We've highlighted that on line five, right?
Green Wolf: Yeah. And remain as is. Okay, so basically it's a walking, it's a sliding window and we reverse within that window. The question is the head data type, do we want to define a link list like data type class, does it point to the next value? Or what is head here? Is it just a list?
The Legendary Avenger: Yeah. Initially I was going to give you the freedom to define how it looks like, but for now, let's assume we are going to have a class node, right? And here our node will basically be an init and we have self and then val. And then next. And then next can be initialized as none. Same case with the val. And so if you want to define things in the context of this, can do that. And then self dot. What the heck was that? And then self dot. Next. This can be a node. And so if you want to build up a list by the example we have above, what you can do is simply create, let's say head one here and you're going to say node right here. And you can say what's the value for that? That's one, right? And then head one next is equals to node. What? That will be two, et cetera. So you can build them up this way if you want. It's really up to us to decide how we want to go by it. And then from there, just operating with head one should be the first example. So this is the kind of input you might get.
Green Wolf: Okay.
The Legendary Avenger: Alternatively, if this is too much, you can even just use tuples because literally it's an enumerated list. You simply need to know what's next. So, so long as you work around the inputs as lists, that's totally fine. I'll give you the freedom to select how you expect your input.
Green Wolf: Okay, yeah, this sounds good. And so valves is going to be just integers. Okay, input receipt had one equals. Okay, so let's say f and this is going to be head, this is class node. And then k is an integer and we return a node, right, because we're going to just be returning the same list.
The Legendary Avenger: If it makes it easier, you don't have to even do the type checking. I love it, but I know it usually consumes a lot of time.
Green Wolf: We're going to say, okay, so obviously check k versus length. We don't know the length because we don't have a. That's the other thing. We won't know it unless we build it, right, because it's just a link list type. Okay, so a condition to watch out for length of list versus k while we're walking. Okay, so let's do this. So current window, it equals zero. What am I going to have to keep track of when I'm doing this? Probably the node. The current node. Okay, so if not head, return, none it. We know that. Okay, so what do I want to do? I said I got to build a window and I got to essentially walk down this node until I've established the window length. So.
The Legendary Avenger: Maybe a quick suggestion. Rather than thinking of a window, what if you had pointers?
Green Wolf: Yeah, it's like two pointers of the other one. Right. So it's like window beginning. Let's just do window left. Window right equals windows left equals head. Window right equals head. Next to start.
The Legendary Avenger: Is it always going to be two of them only? Or how is it going to be.
Green Wolf: Like if there's only going to be two pointers?
The Legendary Avenger: Yeah, because if you just do window left and window right, you're considering two at a time, right?
Green Wolf: Yes, I'm thinking about if there's a window right. So window is kind of constructed like left and then right, and then there's values inside that window. We point at those. So we want to walk the right pointer until we've reached k and then from there, reverse the link. Man, linkless stuff. It's been a minute. We want to build this window up and then walk. Once we've established the window size, then we start reversing in place. Is that the truth or do we want to keep reverse? Maybe I'm thinking of something differently. So I don't really want to reverse until I know that we have a big enough window. Right? Exactly. That's why I don't want to reverse as we go. But we could. What is the problems with that, though? What were you going to say?
The Legendary Avenger: Because that's a very optimal approach and I really like that you're thinking of that, but let's even start high level. Assuming that you have free range of memory. Do you even have to do it in place? Assuming I give you, let's say, a list here, a list of size k, I give you an auxiliary space of size k, let's say window here. And it's going to be a list and you can only fill it to size k. Can that come in handy, especially when it comes to tracking what you're seeing?
Green Wolf: If we knew that the length of the list ahead of. I'm sorry, if you gave me what.
The Legendary Avenger: I'm going to give you auxiliary space, what you can do is fill it up to size k. So as you go through the window or as you go through the link list, you feel free to make copies or at least to throw some of these nodes into that window. And then as soon as it hits your size k, do something with it and then keep going.
Green Wolf: Yeah, we could fill up the auxiliary window with the nodes we encounter. And when it's size k, then walk through that, right?
The Legendary Avenger: Exactly.
Green Wolf: Okay, I think I agree with that. So let's do. Hmm. I'm just thinking about it. Sorry. So while I see, this is where I start thinking in my head instead of typing it out. So let's just do what you just said. So I'm going to say window left and window right. So if we did it with what you did, I'd say while walk to next and push it onto the window list. So while window, well, while current window length is less than or equal to k. So walk to the right and add. Let's start here. We know we need the first one. So window append head. Okay, start here and then say window append head next or not head. We need to say, should I be tracking this? Let's just say temp. You have window left and window right. Let's say current node equals head. Window right equals head. Why am I doing that? Current node next.
The Legendary Avenger: It.
Green Wolf: So I could say instead of current window length, I'm going to say window length. The length of window is less than or equal to k. Append the next current node is head, window right, window, pen, current node. While the length of wind is less than or equal to k append this next unknown current node equals current node next. Ah.
The Legendary Avenger: Okay, so let's, let's pick up what you're doing here. So you're checking for the length. Let's separate these two out and also do this. So you have current node and you also have the window. Let's actually also bring that up. I'll put the comments at the top. That way we have this code all in one place. So you have the window, and as you go through the window, you're appending the current node next. And what you're doing then is saying, well, length of window is less than or equals to k. You keep performing this action, but as soon as you hit the size k, what's going to happen then? Maybe they may ask, even if we are not doing anything. So at the moment, what we are doing is we are simply adding to the list. And are you familiar with this syntax? Just out of curiosity, like, if I was to do this, because you can dot reverse, but I'll just give you a quick.
Green Wolf: Yeah, we could redo that. We could reverse that node and then step back through and update each pointer. Right, reverse.
The Legendary Avenger: Exactly. Alternatively, you can even just loop from right to left. Right loop right to left. And that should also give you the same result. And quick tip on that, because you're tracking your current node separately from whatever is in the window, you still have the next one after you've done the reversal. So even if you adjust the next, you still have the next node to start with at hand. So you can easily keep going. You see that?
Green Wolf: Yeah. Okay. I'm just trying to wrap it up in my head like I was going to try to do it all with just nodes next and not reverse the list itself. But that's fine too. See, this is what I need to work on too, is me sitting here and getting locked up and listening, not listening, trying to think of the solution while you're talking about it.
The Legendary Avenger: It's okay. And full transparency. Here's the thing. The reason why I even suggested the window thing is it's actually complementary to the same exact approach you have. Because once you have that window approach done, optimizing it to get it to purely working on, what do you call them? To purely working with pointer adjustments, it's pretty straightforward, like combining the reversal as well as the iteration process without needing the window.
Green Wolf: Okay. Yeah. Thinking of here though. Okay, let me start it over again. So, yeah, I like what you suggested. And then let me try to reece my thought here. Let's start both. We know that we're going to start at the head. We have the first one done right? And so we need to keep going until we've reached k essentially. Right. We'll keep this up here. These are not really useful at the moment. So we have temp ahead and then we have a window ahead. And those both equal a node. Well, they both equal. What am I thinking about? Let me head sublist tab. Wait. So here, this is what I can do. Temp head. Window head equals a new node. And we can set it to. What are our constructors up there? We're going to say value of zero, just for now. And then its next is going to be head. Right. The given head that we were given. Okay. We're going to start with a temp head pointing at that given head. Okay. And so now we can do a basic loop and move the sublist head to the right on head next until we've reached five k we don't actually care about. So for whatever in range, start from one because we're already there to k might be k minus one. I have to do the math in my head. We can then say window head. That might not be the best name for this, but equals windowhead. Next. So we're walking to the right until we reach k. Can I print stuff out on this?
The Legendary Avenger: The console on the right, it should allow us to print stuff. So if you want to run, feel free to do that.
Green Wolf: Is it console on the right?
The Legendary Avenger: Yes. So let's say we were to do a print here. So just do print and say test. If you run this, I don't know if it will work.
Green Wolf: Where's the run button at anyway? Oh, there it is.
The Legendary Avenger: Top left. Yes.
Green Wolf: I don't see the consoles.
The Legendary Avenger: I'm actually weirded out for some reason. It's not outputting anything. I don't know what's going on with it.
Green Wolf: Do we mess anything up up here? No. Okay.
The Legendary Avenger: I don't know what's going on with coder, but maybe they disabled running. But I'll ask them after this.
Green Wolf: Okay, let's assume I think it range in k. It's exclusive. So that will still give us the number of steps. So this will have built our window build first window to get started. And once we've now we got to reverse it. Now what do we need to do? Okay, so this built our window and now I need to go back and reverse. Okay. I was kind of on a path, but I've kind of lost it. Did this make sense?
The Legendary Avenger: You are correctly building the window. So the one part maybe I might ask here. You see what you're saying? So we're saying while length of window is k, how about we do this? So I'll just add a simple trick here so we know we have our auxiliary space. And I'm also going to do counter here. Right. And I'm going to initiate counter as zero. And now what I'll say here is while counter is less than Len, in this case, 1 second, for some reason my kid is crying. Let me just tell my wife you're good.
Green Wolf: Take your time. No worries.
The Legendary Avenger: Can you take notice? He's screaming. Sorry for that. Still here with me? Yes, he was panicking. I don't know what was going on. So I just needed to check in on that. All right, so I was saying if we had this counter with us here, and so we use this counter as the size, we don't have to do that. Window check for start. Now what I'm proposing here is we can do a quick scan just to get a sense of how many elements we have because it's not really going to cost us.
Green Wolf: Right.
The Legendary Avenger: So if we want, we can do that quickly. So if you want to measure the size of the. What do you call it the size of the linked list here. The downside is it has also some complexity considerations. But with that, we can leverage this to make sure that. And here we can say ll length, because nothing is preventing us from doing this. So we can do this. Alternatively, even without a counter, we can just say while true, right? So do it as an infinite loop. And then actually we can even say while car node, not even car node. Next. So this tells us that we have a node somewhere in the linked list and our car node is going to be initiated, let's say, as head. And we keep doing this so long as there's something. And then within this you can even then say if len window. If len window is equals to k, that's when we maybe call reverse. Reverse. Reverse, let's say window, and then we pass in our window. Reverse window. We pass in our window. And then maybe we do something else. Window equals to that, we reset it. So reverse, and then reset. Reverse, and then here we reset. So these are two possibilities. I'll still let you keep going with it, but what I'm saying here is if it's equals to this, we basically perform the reversal action, and it's up to you to figure out how it will look like else. We add to the window and we keep moving our car node next.
Green Wolf: So by the same logic, it shows basically that. Yeah, that's right. Exactly. You captured what I said up here earlier. It's like, establish the window and then reverse, and then start. Otherwise keep building the window. Okay. Yeah. And this is me not one practicing. And then I guess I should follow what I wrote out kind of described, because if I describe the pseudocode, it kind of makes sense, right? So it's like build the window. Once we have the window, reverse it. Otherwise we got to keep building the window. And then if we don't get to a window correct size, then we know we can't do it. And then the question is reverse window and then reset. Okay, this is actually better than what? So this one I was like, I built the window and then I need to reverse it, but then I didn't really know how to continue forward, how to keep going.
The Legendary Avenger: All right, and I'll do this. I want to make a note. You see, I have this random function we've not used before. And I know you've done this coding interviews before, so you've had sometimes if you have some functionality that you're not sure yet of how it will work, just use, we call them ghost functions or whatever it is that you can feel later. And so what I usually do actually in interviews is if I need such a function, I usually define either as an internal function. But you can do this and say pass, right?
Green Wolf: Yeah.
The Legendary Avenger: And so keep with the primary logic and then fill it out later. And here we can even say our car node equals to head. Right, just to get us started. So if you do this once, you at least have this section of the logic done, it's easy to come back to fill this in because then I.
Green Wolf: Can go in and work on three versal instead of focusing on that with everything else. Right, so like make some stub functions. Yeah, okay.
The Legendary Avenger: Exactly. Okay. So I think typically, at least with an interview, that's kind of the whole length. I know we have about ten, I'll probably add like five, maybe ten minutes after this. But if you want, we can skip the implementation bit. I feel like I picked up a lot of signal on that, but I also want to get a sense of the analysis side of things. So as you go through this code, we don't have to code now, just pick up that your verbal strength is really strong. I can tell that you're thinking of the correct things. So what's the analysis for this? And if you were to actually optimize this a bit further, how would you do that?
Green Wolf: I'd remove the need to. Yeah, I mean, how would I optimize this further if space wise would be just doing an in place pointer updates like build that window like I was initially, without having to allocate a temporary holding pattern for it, and then reverse and then continue moving forward so we can in place reversal without having to store additional nodes like the temporary head or anything like that, not allocating any of that stuff.
The Legendary Avenger: All right.
Green Wolf: Space optimization would be that, but the other one would be focusing more on effective use of the pointer and avoiding multiple passes on the list. Because right there I was kind of allocating a new node to just temporarily build a window and then go reverse it so I could identify in a single pass, combine the identification of the sublist, reverse it, and then update to the next node. All I'm saying is avoid the extra allocation of extra nodes in a temporary storage area for space complexity. And that also means avoiding the multiple passes on the list. If this list is large and the window k is defined as something extremely large, me doing multiple passes on, it's just throwing iterations out the window. So I still think my establishment of the list node, like building the original window is good, but I don't necessarily like the allocation of a new node. So if I were to package it up, I would say avoid allocating temporary nodes and I would try to traverse the head list link list in one pass of doing it in place. Obviously you can kind of throw out temporary storage like pointers, or you just have aaa link list, but that's not the point.
The Legendary Avenger: I was going to ask you though, do you think we can really avoid doing at least two passive, because we have two things, we have two key operations here where we are going through the main list. So that's an inevitable of, and we have to go from start to end. It's a linked list, so that's kind of inevitable. And then the reversal, the reversal of the pointers, that's also somewhat inevitable. That's exactly what we need from the question, right?
Green Wolf: Yeah.
The Legendary Avenger: By virtue of that, what's the minimum complexity you can get really.
Green Wolf: In terms of traversals over the list minus the k? Like we know when we hit a certain length, we can disregard a list that's longer than or doesn't meet our window size constraints. But I would say how many passes are we going to do here? I would say it's kind of close to on squared. No, that's not true.
The Legendary Avenger: Think about it by your window approach. So if we were to think of it as steps, so it's like we are taking a big k step and then we are looping back through k to make sure they are reversed. And then we take another big k step and then another k step back, of which, you know, k will always be less than n, where n is the size of the array. So it's like a big k step and then a Sip back to reverse them.
Green Wolf: We're going to just go over linear time. I don't know if we can make it much better than that.
The Legendary Avenger: Well.
Green Wolf: Yeah, you could make space complexity improvements, but I don't think time in terms of like we're going to be traversing the whole list because we don't know when the end of the node is because we got to continue to try to build the window. Right.
The Legendary Avenger: Precisely. And to your point on that, another quick tip on this, anytime you really identify the best complexity you have, don't worry about the number of loops through, like in this case, two loops, three loops, so long as it's not going to affect the final complexity of which we know in our case it's going to be all n timewise, then an extra loop really doesn't affect much in terms of final analysis. The one thing your interview will be interested in, though is, are you actually aware of the complexity effects? Are you even aware of the best complexity you can get? And in your case, I can tell you clearly have a sense of where we're going, but don't be afraid of solutions if they don't affect the final complexity. But that said, I think what I want to do with you right now is kind of flip the book here. So if I was to ask you, looking back, I know you can identify areas where you think you did well, and I know you can identify areas where you think you can improve on. Maybe just run me through this and then I'll run you through what I took notes of and then we can come up with an action plan for this.
Green Wolf: Okay.
The Legendary Avenger: So you're going to run me through that. What do you think you did well?
Green Wolf: Oh, okay, sorry, I misheard the ordering. I thought you're going to run me through. Okay, what I think I did well, I do believe I broke down the problem coherently and identified a problem like kind of a pattern, whether or not you want to call it two pointers or a window or what have you. But I did identify the kind of the high level close handed steps that need to be taken and the constraints. So I guess decomposing the problem correctly. We talked about how are we going to represent the data structure itself, but kind of the close handed issues of what we are given and what we are expected to return and establishing, or I guess distilling and revisiting some of the definitions. Like what does it mean by k? Like what is k actually representing and then what is a left out node? Some of those edge cases right there is what I did identify well. What I didn't identify well was actually putting pseudocode into, even at a basic level, like a graduated implementation. Like I liked how you did the stub, but I should have been thinking very similar to that. Like okay, how do I just break it out into discrete steps that I identified in comments like can I do the same thing? My ideas and identification of the constraints and stuff were good. I didn't necessarily think of some test cases. I could have spent a little bit more time on that. Like what if I get write out the return case for something that's the same? I guess I identified it vocally, but a list length of size k that we find, but we don't know the length of the list. So I could have spent a little more time on test cases and examples instead of just taking the given ones to demonstrate that. But with the given ones, I thought I did okay with identifying the problems components, putting it into the language I did not necessarily follow through on.
The Legendary Avenger: Makes sense and so at least to reverse in this case. So let me run you through my feedback so I know you also have a sense of what interviewers will typically be looking for. So communication is one pillar that I'll be focused on. I want to make sure I'm keeping up with you. Then there's the technical skills and then there's the problem solving skills on your side. It was easy to pick up the communication as being extremely strong. I think that's probably your biggest strength. What I went through here so I could easily tell that you know how to speak to your interviewer even during the process of coding. I know a lot of candidates struggle quite a lot when they're coding and they're supposed to speak at the same time. It's usually not really fun. And so in your case, I'm not too worried about that. That said, I have some suggestion strategies because I feel like sometimes you got lost in these rabbit holes and you also identify them where you start doing something and you get lost in your head. And so one pattern that at least I try to use here is if I'm speaking, let's say, at most 1 minute, and my interview has not come interjected or told me to consider another perspective, I bring them in myself. I ask them, does this make sense to you? Are we headed in the right direction? Let's say depending on the context, you can ask them a question. It's more of a filler question, but you want to make sure that they're in the loop. And typically doing this repeatedly also helps you because you avoid going down rabbit holes, especially if they're wrong, because you'll find that occasional evil interviewer who frankly will just not tell you they'll let you go down the wrong path. And then at the end you hear stuck because you're not implementing the correct thing. So maybe just learning how to time box yourself to a degree there would help you because then you just stop yourself and make sure, hey, even before I go on further, does this make sense to you? And if they say yes, then assuming it's wrong, then at least they're confused alongside you, right? And you're not the only one going down a bad rabbit hole.
Green Wolf: Yeah, like don't go down the path without telling them what path I'm going down. Really be more of a guide on my thought process rather than just saying trust me.
The Legendary Avenger: Precisely. So making sure they're in the loop with it. And then the other thing I was thinking about here, at least in terms of communication, there is a lot more strategy we can use in terms of what we are packing into the communication. And an example is how we present initial proposals for the solution. So in your case, you gave me the idea, you wrote it down. And here's the thing. As an engineer, I like writing things down. But my lord, it sucks when it comes to interviews because they take long, and you might find yourself trying to document a very exhaustive approach. And it's taken ten minutes, and then, boom, you have maybe 25 minutes at most to solve the problem. So what I usually advise my candidates is don't write down the step by step process. I realize a lot of candidates tend to want to have that exhaustiveness, but don't do that. Rather, word it out. So for the process, word it out. And then, if you must write, summarize the approach using at most, let's say, one or two lines each. So it's like loop thread or loop list, and then maybe build window, something like that. If you document too much, it takes too long. Now, that the one thing I would advise you do right from the get go is as soon as you proposed a solution, also talk about its complexity, because it's usually fairly clear. So propose a solution, write its complexity next to it, and the reason is you then won't have to do it at the end. You immediately get those points, check, you have some technical details checked. Does this make sense?
Green Wolf: Yeah. So be a little more high level, right out the basics, but not every detailed step. If we look at line 40 through 42, that could have been a lot of what I said, right? Outside of everything else. Yeah. And then identify as I'm doing it right. If we're flying by, go ahead, driven.
The Legendary Avenger: Make it better. If you want to kind of even showcase testing, you can actually talk about your solution in light of one of the examples. So as you propose a solution, if you have to delve deep, test it out with an example. Now, that's the part where if you document, it's totally fine. And that's why I usually advise my candidates. If you, let's say, want to, you can write an example. And on line 45, I'll give an example there. So let's say 123456. I usually advise the use of these things, hats. I don't know if they're hats. So you can say, this is my p one. Right. P one and then p two somewhere else. And then you just move them around. So you can say that maybe this is our p two for the next pointer. And in our case, we know that the window should be a size k. So let's say k is three. So if you just do this, move it so that the explanations are animated so you can tell the interviewer, okay, so in this case, I'm going to do a couple of things. I'm going to build up the window. And so you say, build window. And then from there, the next step would of course entail reverse the window. So reverse if it's size k. So this is kind of the general gist of what I need to do. And then you run through it. So you say, in this case, I'll obviously move p one until I achieve the window size. So if this window size is three, so it's p one, p two, p three. And then as soon as I hit that, it means I have a window size three, which this case would look something like one, two, three. So I just reverse it and say, this will be three, two, one. And then from there I get the p two to the next level while I still have my window handy. And then connect, build it up and then connect it again later on. So kind of using your window as a cache, but also using it to build the rest of the list. So the reason I'm saying this is.
Green Wolf: Not only demonstrating it exactly.
The Legendary Avenger: Here'S the thing. It's also showing. Testing. You want to show you can test, you want to show you can debug. And the beauty of it is you're not debugging code. It's a reverse process where you are literally testing your code even before all your logic, before you write the code. And the beauty of this is, especially with companies that don't ask you to run the code, you're saving yourself the problem or the trouble of catching bugs as you go, which can sometimes dink your performance. So if your logic is sound, implementation details won't really matter as much. They'll only want to see, can you code in each case? CPS, you're totally fine. Makes sense.
Green Wolf: Yeah, that makes sense. All right. Yeah. Last time I did a lot of these interviews, we did it in person on whiteboard. So this is different now when you can write code and tested. So that's also.
The Legendary Avenger: I'm not going to lie. I do prefer the whiteboard days because you didn't have to code everything and nobody expected it, right?
Green Wolf: Yeah. Now they expect it to run like, okay.
The Legendary Avenger: Or with Google, they're going to give you a doc that's going to be funny.
Green Wolf: So obviously, a lot of this is going to come down to me practicing them, talking about it out loud, and illustrating it like you just did correctly in front of them. Because when it's me by myself, I can illustrate it to myself, but I got to think about that for other people.
The Legendary Avenger: Indeed. And I'm trying to think of, like, because at least with my mentorship, so what I usually try to do is work with my candidate to come up with a strategy. So in this case, especially in the communication bit, because I feel as though we both identified that as an area where we need a bit of work. And frankly, it's hard to work on unless you're having practice. But I feel like I'll be doing you a disservice if I just told you, go practice. So we've identified one strategy here where we said, limit yourself for time box. So it's a two way strategy here where you have time box and you say at most 1 minute. If you want, you can even break it down by sentences so you can literally time yourself, see how many sentences you're able to get in in about a minute, and then always monitor for that. So you can even do sentence count. So as you speak through, just evaluate. Have I said, like ten sentences in one go, or is it two? At which point you pause. So this could be another strategy you develop. Can you think of any other strategy here in terms of how you speak? Do you feel like there's something you can. More intuitive? Detroit?
Green Wolf: Yeah. Well, yeah. Being less verbose, I guess, speaking with intention, without. I mean, when you're quiet sometimes, are you there? Are you thinking? You want to demonstrate that you're there talking through all your thoughts? But, yeah, once I'm on a solution, I guess I should drill down. Like, here's the solution at a high level.
The Legendary Avenger: Yes, I hear you. And to actually, to your point, I was going to say you can even develop strategic pillow words. And actually, let's make that a whole category on its own so we can have strategic pillars. And I know this is probably silly to do this kind of analysis, but here's the thing. I'm actually from a country where we speak seven languages, so sometimes when you are speaking English, you have to even develop robotic ways of communicating things. And while it's stupid, especially if English is your first language, sometimes people actually see this and they're like, oh, that's actually helpful. It's good to learn that as a nut rather than just a piece of nature. And my favorite one is, does it make sense? You can tell I use this a lot. Does it make sense? It fits in anywhere, really? Like, I can throw it in anywhere and the interviewer will be involved, and if it makes sense to them, they get involved. Does it make sense to you?
Green Wolf: Yeah, I did like that aspect of demonstrating it in that regard and saying it.
The Legendary Avenger: And there's a lot of phrases you can use.
Green Wolf: Getting buy in. Am I saying the right thing? This is what I'm saying. Track with your expectations here.
The Legendary Avenger: Yeah, exactly. What I'll do here is in the feedback form, I'll give you a list of such pillars. And then of course you can use one, you can use two so that the conversation sounds more natural. But this is just a speech thing. It's like time boxing yourself and then throwing them in there. I feel like that will help you make sure that you're optimally using the time. Now, here's another one that I usually like. It's a bit longer, but is it optimal enough, or should I look to do better? Should I do better or some variant of this? And the reason I really like this one is it usually gets information out of the interviewer. And what's happening here is in case this person let's you proposed an initial approach. It makes sense to them, but in their mind, they know there's a more optimal solution even before going down a rabbit hole. If you explicitly ask them this, if they say we could do better or if they're okay with what you have, they'll say, okay, that makes sense. But if they in mind had a better solution you could take on, it would suck. If they tell you it's fine, yet they know you could do better. And so this is an indirect way of seeing if you're meeting your interviews, Mark. So just explicitly or strategically asking them, is this optimal enough, or should I look to do better? If they say, yeah, we could do better, then you know, okay, there must be another solution. So given what I have here, can I improve it? Or maybe can I think of an alternative approach? And this saves you the trouble of starting to code something that's not going to get you the maximum point on the mark. Makes sense to you?
Green Wolf: Yeah, that does make sense. And it's not like, hey, tell me what to do. It's asking for guidance, and it's also avoiding going down the path and losing that time. If you could have denied that threat of thought ahead of time, you would have saved all that time. So you kind of lost the time if you didn't ask that earlier. Right? So get their input, if possible, without explicitly being like okay, what next.
The Legendary Avenger: Precisely? You can tell I'm focusing a lot on just improving communication, because frankly speaking, I think this bit here, the solution bit, you clearly have a sense of the patterns we need to look out for. So what I'll do here is I'll simply curate a list of questions by pattern. And you don't have to solve all of them, but I would advise you solve at least, let's say, three questions per pattern. And these patterns are like dynamic programming, the likes of graph just to build that comfort. Because once you're, let's say, 1015 20 problems in, typically you realize, okay, in terms of problem solving, I'm in a much better space. And so that's why async practice is more than enough. And then in the interview, it's building the interview skills, not the problem solving skills. Like there's not much that an interviewer can do for the problem solving, which is ironic, because I know a lot of candidates expect that they come out of here, they can code better, but no, it's actually the interview that the interviewer can help you with. I feel as though on your side, it's more or less about building that natural progression throughout the interview. And hopefully these things will help or these strategies will help. Now, I know you only have three sessions. I would like to suggest an alternative resource that you can use because I don't think it will make sense to pay for more. Honestly, I feel for you three, maybe to five at most. Sessions such as this will be good to get to that space because I trust your technical skills. But if you have to practice, either use the platform. I know you've seen the free sessions, right? You can sign up for free sessions either to host them, also to go through them as an interviewee. Have you seen those?
Green Wolf: Yeah.
The Legendary Avenger: Yes, I would advise try and actually run some interviews. Ironically, you can learn a lot by being the interviewer and it's less pressure. Who knows? If you find people who are actually good, you can see what they're doing and maybe pick it up alternatively. So that's one thing I would advise you to do. So use this platform, conduct some interviews, be on the hot seat yourself, try and garner as much insight as possible, and obviously use this as a chance to practice and then do the opposite. Be interviewed. I feel as though once you're maybe three to five such interviews in, you'll be a lot more confident and a lot more comfortable getting from step a to step z where you have the solution. And even if, let's say, there are still weaknesses here and there you'll still have that practice to go through and obviously watch example interviews, which there are a lot out there just to kind of just see what other people are doing, because all these questions are going to be repeated. I'm hoping this is making sense to you.
Green Wolf: It is.
The Legendary Avenger: All right, what I'll do after this. After the session, I'll actually curate a list of resources as well as some other strategic feelers, like things like this. So in terms of communication, I'll basically give very precise feedback on areas where I think you can improve on. And then I'll paste that for you in the feedback form. And then, as I said, please ping Liz. We'll actually add you to the Slack channel. And then we can also connect async from there if you have any questions. But at least before we end, I don't know if you have any other last questions for me or anything else you want to discuss.
Green Wolf: I guess scheduling frequency. I know we have three or something. I put one up for this weekend at some point. I don't know how spacing works. I guess preferences on spacing between these things. Obviously, practicing and stuff in between is my own accord. But what do you think is effective here?
The Legendary Avenger: I was going to advise, let's put at least two weeks between this session and the next session. I feel as though you won't have enough time to have meaningful practice between this and the next one, especially if it's not urgent. If you don't have interviews coming in tomorrow, then let's maximize how much impact you can get from just three sessions. Makes sense.
Green Wolf: Okay, sounds good. I'll go look at the schedule and make adjustments.
The Legendary Avenger: Perfect. Yeah. And I have a fairly open schedule for dedicated coaching. It's my priority, so there will be a lot of time. And if you need more time again, reach out to me and I'll make sure I free up space.
Green Wolf: Okay, that sounds great. I appreciate it. Thank you.
The Legendary Avenger: Absolutely. It was really nice to meet you, James. And I trust you on the right track. Honestly, I'm not too worried about you. It's just refining this because you clearly have what it takes. I usually tell people if you're going to build a huge robot and you're starting from a place where you have everything there, it just needs assembly, then you're good. And that's exactly what we have here. Clearly the technical bits. Clearly you have the engine, you have to build it up, right?
Green Wolf: Yeah. Got to rework that muscle out because it atrophies pretty quickly.
The Legendary Avenger: So. For sure. But I have the confidence in you. You're going to do well after we're done this, but, yeah. All right. Have a good day. I'm going to drop off for now and keep an eye on the feedback form. I'll present all the resources I have for you.
Green Wolf: Okay, great. Sounds great. I appreciate it.
The Legendary Avenger: All right.
Green Wolf: Thank you. Bye.
We know exactly what to do and say to get the company, title, and salary you want.
Interview prep and job hunting are chaos and pain. We can help. Really.
