Senior Engineer vs. Claude Code | React.js Interview (useEffect, Suspense, RSC, a11y)

Today, we're going to go to a senior React technical interview. But the catch is that Bogdan will be interviewed by Cloud Code itself. And how are we going to do this? Using the senior dev skill, we just launched. You folks can see the repo over here. But Bogdan, let's go and get the senior dev skill and we're going to use that to interview you on. I think it's 10 questions, right? Yes. So I'm going to copy this. Okay, so I will install the skill now and you can get the command from the public repository. I'll click yes. So, make sure you check this board by pressing space, hit enter, I use Cloud Code and I'm installing it globally as a symlink and with VS. And then you can go into Cloud and yeah, I'm going to click yes, it has that folder. And you get it by typing react senior interview. So basically, we build this with all the react documentation and then react best practices that we learned over the years, like the rules of hooks, state architecture, performance, and the typical flaws. And also then we injected some interview questions, so it looks very similar to what you get in real interviews. Gotcha. So, what is going to do right now? It seems like it's loading everything and it's going to start asking you which which level you're interviewing for, right? Exactly. So I will start on a hard one, I'm going to hit for the senior level. Let's see. And now it's going to ask me what kind of if you want a more focus interview. And I will go for broad, which is a little bit of everything, state management, web performance, accessibility. And now it's good to start asking me the questions and at the end we see how many I got right and what are my gaps. What's funny is that we also offer a senior technical assessment, right, and you folks are going to find the link in comments. And that assessment, it's much more deterministic, right? Because you have a set of questions and you're going to see how you're going to rank against other developers, right? And the outcome, it's always the same is it right or wrong, etc. But in the case of cloud code, the model, it's not so

better at interviewing because it can be kind of confusing. I we're talking about that bug, but it gives you a lot of different questions that you can pick up that that the model has let's say memorized in the weights of the model, right? And that's one of the advantages of using such an and these advantages of using such a using cloud code to interview yourself and using such a skill, right? Exactly, it's non-deterministic, which is a feature and a bug. It's a feature because you get more variability in your questions, but it's a bug because the questions sometimes are just off and they're not really reviewed. You don't really know if you just hallucinated, let's say, or just try to generate the question or the constraints it has even if it doesn't really make sense. So let's go with question one, this is a junior one about state. What is the effect in this component? So we have this profile component. It would be nice if they had some syntax highlighted, but they render everything in markdown and you see the actual markdown. So yeah, function profile and then it says, if idea return empty, so an early return pattern before state. Pretty obvious, hooks. should be at the very top of the component, the first thing in the component according to the rule of hooks. So that is this one, so hooks around after an early return. The other options are obviously made up. So I'm going to hit enter. And it's a correct one. Perfect, so one out of ten correct. Let's keep going. So question number two, middle level, a component holds items in state and one surring total, which approach is correct. Okay, so we have these two items and in an in effect this computer total. This is a classical example of derived state as essential state, so you could derive the total from the items on one go and maybe use a use memo rather than having an effect in another state, which will trigger a lot of re-renders. So, you want to have as little state as necessary. And so there's different options, compute the total doing render. Yes, exactly. Keep the effect, but that total do not deps. No, move the reducing use memo. Yeah, you're fixing the symptom not the sickness. Move both into the use same use state object. Yeah, you're not really fixing anything.

you even making things worse in that case, because then you have extra and as every time any of them changes. So it's definitely this one where that state it's essential. Correct. So two out of ten. Okay. That's a variable box explanation. The single app provider context holds those ones. Okay, so we have an app provider that it's at the top level probably. It has team user card count. Okay. Uh looks okay, but in the mouse position, that's definitely something you don't want to have a a global state. And grab the whole tree mouse position updates on every mouse move and then probably trigger so this render. And they're saying, okay, user memo, again you're fixing the symptom. Not the sickness, use callback another symptom, split the context by update frequency. Yeah, could work. other provider value and use memo. Yeah, it's definitely split the context by update frequency so fast changing mouse position has its own provider and only the components that need that, they can subscribe to that specific provider. So I'm quite confident in this one. Okay, correct. I'm still alive. Three out of ten. Question four, mid-level performance, does the use callback here do anything useful? So we have a component that's functional component, we have handle click as a function, and basically it takes this prop and so it memorize this, so it only changes handle click would only change when on save changes, and then they pass this one so. To be honest, it's obvious that it doesn't do much, right? Because if we change the prop, if this on save actually changes, it triggers a re-render, then handle click will be recomputed and if not, then nothing happens. And then they pass it to the button. So let's see the options. Yes, it stops the button from re-rendering when tool toolbar re-renders and a stable handler keeps the dumb from re-rendering. Yes, but not quite. Okay, let's imagine that toolbar re-renders because toolbar already render if a prop will change. So then the only prop it's on save,

So the logical way to think about this is that it will end up kind of changing handle click, which ends up rendering button, so I don't see any real prevention. Let's see option two, no, the consumer it's a plain down element, so the stable identity buys nothing, it's pure overhead. Not really. So even if the consumer it's a button, playing button, if the prop changed, react will still re-render. So if the reference of the function change, react will re-render, but what prevents here re-rendering is that this component could be memoized when being used. Yes, it prevents the on-safe from being recreated on each render. On-save is not really recreated on each rendered, it only changes if we pass a new value to that function. So the if this re-renders depends more if whatever we pass from the parent is being memoized before being passed. And then yes, it's required because on-save it's in the dependency here, hey, this is definitely wrong. So I'm kind of divided here, it prevents on-safe when it created. Yeah, but still, no, the consumer it's a plain button. So the stable identity buys nothing, it's pure overhead. I think this is kind of misleading because even if handle click, I mean, functions are objects in JavaScript and they are compared by reference. So even if it it it depends more on the parent, if the parent gives us a new on-save, even if that on-save didn't change, if it gets recreated by the parent, then we automatically trigger a re-render. And this use callback doesn't really prevent anything. So the problem is my reason to say no to this is not the model reason. So it says yes, it stops the button from re-rendering where turbo re-render, no, I don't agree with that. Yes, it prevents on-safe from being recreated on each render. What do you think the model? nothing really. pick as the correct option. Seems like you disagree with the model. What do you think will the model will mark as

the good one here. Probably number one? I think Yeah, I think it's probably either between the no, I think it's going to go for the no. Yes, it prevents you safe from being created on this you know. Yes, it stops the bottom for you know. Yeah, it's the number one or two, I think that's what the model would go for. So yes, it stops the bottom from re-rendering when till bar re-renders. Yeah, but like you're memorizing a prop, you're using use callback on a prop.

And so if the prop changes, you're still recreating handle click. So I think it does anything, I'm just going to go for the no. But I am feel like this is kind of confusing in a way. This one the one I'm talking. Okay. Well, so let's stop here for a while. What if you are a junior mid-level dev? You shouldn't do the senior. Because, okay, because you're good at not only understanding what can be like the right and the wrong option, but also understanding what the model might want to tweak you on.

Because if the model sometimes the model doesn't really let's be honest, the model doesn't really understand these questions. This is just kind of a probability distribution, right, this is taking them from, but you do, right? But a mid-level dev, it's like it's going to a quiz where it's not that there is the correct answer might not be there, and everything is confusing. It's like this game of mirrors.

Yes, but it's it did this, it came up with these questions based on the context we gave it and in the context we include context pointers, a reference to all these best practices. And again, language model is pretty good at extracting structure from text. So your alternative would be like reading the docks and maybe imagining what they would ask. So I feel like even if it has all these bugs, you can still derive value out of it if you're interviewing.

Now, if you feel like it's too confusing, then go back a level or you'll see at the end it's kind of give me pointers to what I should look up in the documentation. So don't take this as a replacement for reading the docs. But if you think of the traditional way to prepare, which would be you Google for some interview questions that you don't know if they are real, you know, go to the docs and read them, but the docs are huge.

There's a lot of edge cases there that you never ask about. So, I do think you can get still a lot of value. Even if assume that it's going to be a hit and miss, so 80% of stuff will be good and then 20% will not be that good. And again, it's all about gaps. So the advantage of this is you can get many gaps in. You can do so many of those. And so you will you'll get good at spotting the the blind spots.

So a senior reviewer, so this is question five, a senior reviewer sees product data fetch via use state and use effect across dozen components. Each which is unloading state or bullion, no shared cache, noational style data after amount box. What's the most architectural correct fix? I didn't even need to read the options at this point because it's kind of giving away the answer. And the answer is probably using a specialized state library for data fetching, like the TanStack query, which handles like caching, duplication, rendering, refetching.

So you don't need to reinvent the wheel. Because if you just use use state and use effect, that's a very basic approach and there'll be so many edge cases that you don't cover. So let's read the options one by one. Add a boy controller and clean up return to each effect to kill the races. Yes, but TanStack kind of really has that. Again, you're fixing one little problem and reinventing the wheel. Move the fetch data into Global Sushi and Redux.

Obviously, no, like you don't want to put uh fetch data to global state, it usually doesn't belong there. Unless it's something that you need in global state, like a team or user conflict. Adapt the query layer, exactly, this is exactly the question. Um, so it's going to have caching, validation and refetch. And wrap the fetch in the custom use fetch to centralize the effect logic. Again, it's not going to solve the actual problem, which is that you don't have caching, invalidation and all the advanced features that you want from a caching.

uh, from a query library and you can get for free these days, right? So I'm going to hit enter on this one. This one was pretty self-explanatory. Like the problem is sometimes you see like the correct option, it's so obviously correct and different from all the others. But it's still good for you to refresh this before an interview before you jump in. combo box to be shipped across three products.

We're totally different visual designs, but identical keyboard navigation filtering and selection behavior, which pattern best fits? Okay. Which pattern fits best? So it has totally different visual designs. That means they might need to use their own mark down. It says compound components, children's stay share and please still with consumers, okay. Could work. A headless component hook first. Expose behavior via hook and let each product down the mark.

Identical keyboard navigation filtering and selection behavior. The problem there is that a custom hook doesn't really give you any structural advantages, right? If you have a custom hook, you just get this reusable logical state you can use in your component. But you need to bring your own mark down. And if everybody brings their own mark down, we don't really have identical keyboard navigation filtering and selection behavior.

So, it makes me feel like this is not the right option, it makes me feel like compound components are the right option because you give them not only the logic, but also the building pieces. That's what ShadCN does. And then we have a higher component. No, this is not definitely the solution. This is really good for art, or whenever you want to work at the boundary of the component, like you want to add an error boundary or login layer, because you you wrap a component.

And a discriminator varying prop definitely wrong. So, I'm kind of inclined, this is definitely the two options that are like more or less visible. But I feel like a headless component hook first expose behavior via hook, lets this be available because visual design styling isn't the value, could works because it is a headless component. What would be the difference between a compound component now that we are here and a headless component with a hook first behavior.

So, when you have this compound component, yeah, it means that the you give people a combo box and a combo option, and a combo option is using normally a hook into the combo box. So kind of already wired up the state for them and they just need to kind of use this pieces, they could use as many combo boxes as they want, they could maybe change some classes, pass some CSS classes to them. But it's a lot more rigid, whereas a headless component hook first gives them a lot more freedom to assemble these things.

So it says okay, you expose a behavior via a hook, but then they write their own HTML. Uh this is a tricky one. So identical keyboard navigation for filtering and selection behavior. Could you do that with a headless component? Yes, like Radix is a headless framework where you get you get those components that are accessible first and then the CSS. So right now, this one is the one that I'm most divided between, but I probably go with a headless component.

I'll probably go with number one. Because I feel like hooks are about functionality and functionality doesn't change. Well, you got me. It definitely got right there. I got to tell you, talk, I did a several couple times and that kind of question they'd always ask that question in different styles. And then it's usually goes for the answers too. Let's go on. So. Can we just shortly review the explanation because it was a bit the question itself was a bit confusing?

Sure, so headless component hook first, when the behavior is the reusable asset and the styling is not, in fact most developer product, the headless pattern it's exactly right. So this is a principle behind the Radix UI, which is the the child framework, it's used in shadcn for example. So you get this components that you can style. Uh they give you the state and prop getter and let them render whatever dumb they want.

This is what down shift, React area and Radix primitives do. Component components still bake in a dumb structure, which faked totally different visual design. So it's kind of it's too restrictive as I mentioned. So you could make some changes, but it's not so flexible. Question seven, a full screen overlay slides in via request animation frame or adding element style every each frame. It's middle, but that's badly well app does heavy work data parsing logic.

was the kind of seeing fix. Before getting the options, we see that it it's not it's started to slow down when the main thread it's busy and it's just a style kind of animation which you could push to the compositor thread. And so the compositor thread will do the work meanwhile the main thread it's empty or idle or you can do something else like running things in event loop. And it's not even react specific, this is more of how the browser architecture actually works.

So probably the solution here would be to push that to make this overlay work with the CSS transition because they get pushed directly to the compositor thread and done directly at CPU level because the CPU can run like visual transformations without going to the main thread, so you don't need your main thread to do some work and then push that to the CPU. It's a way to bypass the main thread. So throttle the AAF loop, probably a bad idea.

It didn't do sort of fixes, you don't want in any kind of application. Animate transform, we have CSS transition key frames. Exactly, it runs on a compositor thread, that's where the keyword. To be able to have you working use transition, you're still going to the main thread because you're running react code. So that as long as you do this with JavaScript, you're going to get in trouble. Add will change to promote element on its own layer, layer promotion, uploads the left animation from the main thread.

Okay, this is tricky, right? Because we know that what the the main thread will do is to decompose the UI in different layers. Mhm. But promoting layers yourself sounds like a lot a big hack. And usually the your browser has its own criteria for that. So it definitely feels like a hack. And if you move it to a different layer, yeah, you could move it off from the main tread because the compositor layer could work do a layer level transformation, but still, I feel like the cleanest option would be to just let the browser do what it does best and use the best way to do this, which is the way they actually design it,

which is to use CSS transitions. Now, for the developers watching us. doesn't really know the difference between the compositor thread and the main thread. And if I already understood correctly, JavaScript runs on the main thread and then there is the compositor thread, which runs all the CSS stuff. But where would you point them? What would you point them towards if they want to learn more about this or if they've never been exposed to this kind of depth.

So the information about the browser architecture is usually in the Chromium engine documentation, which is very hard to go through, but they do explain it pretty well there. Maybe you can use Claude to guide them through and kind of use that as a rag, right? You can answer this question based on Chromium architecture. Or that's a bit about it on MDN, but that it's very superficial. They didn't go too much in depth because it's mainly the Chromium team that developed this knowledge.

We do have an in-depth video about key concepts in the front end on the channel. So make sure you subscribe and look for that one and if you want us to go even more in depth, we can make a follow-up where we go even more in depth. I think I skipped a lot of those details because it was just too much for the scope of a single video in that one. So let's let's see. I'm going to hit enter. So it was correct, animate transform translates yes, via CSS, it runs on the compositor thread directly.

So the animation is driven by JS and the main thread, so it competes with parsing rendering and starts the frames, but it also competes with the event loop. So that areas layout every frame, moving it to CSS fixes both. And so they go off the main thread and it keeps running smoothly even through the long main thread even if the main thread it's is busy. So, just to simplify this. The problem that the team browsers teams were trying to solve is, imagine you are re-rendering or doing some JavaScript work, but at the same time the user will scroll.

And what happens is when you scroll, you need to recompute the frame. But you kind of know what's already there, you don't need to go to JavaScript and rebuild the DOM to kind of predict what is the next part of the DOM. So it's a lot these, we have a parallel way to do like simple transformations. By simple transformation is imagine you have a div which was computed at the GPU level, you have all those pixels and you just want to move it to the right, to rotate it a bit.

That's you can do like in video games, you do that state in the GPU. So that did this compositor thread where you can push those things. And so what you what happens is whenever you have one of those transformations, like you scroll down, if there's no JavaScript attached to your scroll event, what the main thread will look at it and be like, oh, there's no JavaScript here, let me push it to the other thread that's busy. That's that's that's the compositor thread.

And that goes straight to the GPU and it's like a fast track to do this kind of transformations. Question eight, mid level accessibility. Reusable list row renders as div class name row, and then we have an on click navigator items ID. This is a reusable list and then it has a label. So the problem is, I'm not going to need the options, right? We always want to read the problem statement. Well, what is the most significant problem seen in your flags? Okay, there's definitely some accessibility problems with this, but let's read the options.

If they're asking about the accessibility, then div, it's a non-semantic HTML tag, we should probably use a list item, li tag. Uh wrapped in a UL or you know, OL or UL. It's a it's a list. So what's the most significant problem? The inline arrow allocates a new function for each render, hurting performance. Yes, we are creating this on each render. But is that really the most significant problem? It navigates, so it should be in an A href.

A div onclick isn't keyboard operable or announced as a link. It could be, it's a non-semantic interactive element. Now focuses now enter key no role for assistive tech and there's no area label on it. Navigate should run in his effect. Now that I don't know the handle. No, that's false. And the class row, it's a valuable selector. Now, these two are obviously false. this one, it could look Now, that's you could have a you could have that one as the global selector. But they are not telling us what is the most important problem regarding to accessibility or styling and so this this is kind of true, right? Number four, it's kind of true. But you need more context to really answer it. Number three is definitely wrong. And then we are in between this one, which is a performance issue and this one, which is a huge accessibility issue. So I'll probably be more inclined towards number two as the most critical issue. because it's an accessibility question, right? Yes, and it breaks behavior in a very bad and unpredictable way, it breaks accessibility thing, whereas this is just a detail. Like having this performance detail, it's it's not so critical. Especially unless you have something that's very performance critical, you won't even notice it. I'm going to go for this one. Let's see. Maybe it's the CSS part. Boof. Correct. Okay. I I have to be honest with you. I always get a bit nervous when I do this cuz it's kind of you against the machine in a way. Well now it's still looking pretty good. It do. Great. Yeah. Question nine. A multi-step checkout flow with steps that can advance, go back, skip conditionally, and retry on payment failure, certain transitions are illegal, can reach confirmation without successful payment, and the back track is full of impossible state reports. Which pattern is the senior call? Before we read the options, it's kind of obvious. You can do this with share state, but if you have this kind of conditions, they added the magic word, which is certain transitions are illegal. And there'll probably leak the answer. Because whenever we talk about transition outside of CSS, it's usually a state transition that happens in a state machine. So the answer is probably to have a proper state machine for this component. Not just components straight. Okay, now let's get the options. A final state machine that makes illegal transition representable exactly what I was talking about. A handful of booleans, bad solution, you're going to run into race conditions, state conditions, a single use state holding everything. Again, this is obviously bad. And a global store slice.

you instead updated from its state component, centralizing the step to let any component they had the flow. Kind of confusing and made up. It's pretty obvious that the find state machine with this solution. Yeah, again, this this kind of questions they give away the answer in a subtle way sometimes, but they could do it. Yeah. And so the right answer, it's a finite state machine that makes legal transitions are representable. Yeah.

And then you have the whole wall of text explaining why. And finally, last but not least, question number 10. A page component holds 14 year state calls at the top. One of them, it's Ho, ID is get by single table row deep into tree and it changes on every row hoover. Hoovering cause the whole page to re-render, re-render. Okay, what's the right fix? So let me think about this before I get the options. We have 14 year state calls at the top and one of them has the Hoover ID.

Okay. Number one, wrap the page body in React Memo to stop Hoover re-render. Now, React memo only works to memorize your props and then you stop re-rendering, but it doesn't stop re-renders from your state. Push Hoover row ID down, let each table row it sound Hoover state locally. It depends why why you use the state for right? This could be right. Because state lives closest to its consumer, but it didn't told us why do we need this state.

So that's the problem with the model sometimes. Any interviews they do the same, okay? Like it's a very little question that you that doesn't make any sense. So I would much. Move Hoover ID into use ref. So updating it doesn't trigger a re-render. I'll still run the re-render. Combine all the 14 new state calls into one use reducer. to batch updates. Yeah, but still you still have a state change, a tablet.

Well, it still triggers a re-render. So I don't feel like this is going to work this combining 14 state. So probably I in this case, I'm very confused to be honest, but I'll probably go to pushing it down and have the state. Yeah, have the state living this state. Cuz ideally, state should live as as low as you can possibly. But the reason why you usually have to lift it is because you have sibling components needing it and that's when you start having problems.

So they they didn't gave us enough context to make this decision. In in my opinion, but I'm going to go with number two. before we answer this, I was oh let's see what comes up, what comes out of it. But a bunch of ideas that popped into my head. Number one, the future of interviewing might involve an LLM, right, maybe in this shape or another shape. But this could be part of the next interview you will be getting in the next couple of months or years.

Right, I think could even like if we were to hire a senior engineer, right, you could tell them, hey, just install the skill, let's have a call together, install the skill and go through the senior questions. And we're going to go through them together and you're going to explain me. It doesn't matter whether you get them right or wrong. I want to see how you think and that's the problem. A lot of developers are just delegating their thinking to LLMs, right, but the way you went to these questions was through your own understanding of the fundamentals because the model is confusing.

Right, we might see a future where number one, fundamentals matter a lot more. And number two, you need to get used to think in a world where a lot of less developers are using their brain, like honestly and their knowledge because AI can do everything, right? I think not too much changed in the terms of the mentality that gives results in engineering and you should always apply the good old principle of the why matters more than the what.

So, whenever you if you get the skill and start asking questions and you get the right or wrong, uh I would even if you get a question right that you don't understand why or what's the underlying principle, I wouldn't be too happy about it. So, don't focus too much on my score or the answer to the question. You always want to trace that back to, okay, why is the principle behind this? So I can use deductive reasoning, not to answer this specific question, but to solve problems in this knowledge domain, which in this case is React.

tify. And folks, if you want to practice your deductive reasoning skill, then check out the free assessment in the comments. also on the Senior Dev Channel, Bergen has been publishing great videos that contain and where he talks and reasons about these concepts, which you need to learn specifically for at a senior level, whether it's front end or full stack. Exactly. So, yeah, let's look at the results.

I see I got a 10 out of 10. I will be honest with you, I did this three or four times before and I got a nine out of 10. So this is the first 10 out of 10 I get and it's live, which is very surprising, and I feel very lucky, too. Let's see what it tells me about the strengths: got state architecture, perfect, performance and path selection, none of the gaps were surfaced. Um, so recommended next steps, it kind of coverage dimension, so it's telling me to go deep into each single dimension.

And I do think it would be interesting to go deep into the one about the, you remember that question about the compound pattern versus the headless hook? That's the one that I got right, but I do feel like there's some nuances that it would be worth kind of dipping dive. So that's what I would do next in my case, so take this as a next step, and I'll definitely kind of use it to go deep into this dimensions that we embedded into it.

And that's pretty much it. What I would definitely add to that, right? I would advise people to number one, go to the repo, install the skill. We're going to keep up updating this skill based on your feedback as well. If you want us to, if you see any kind of improvement, just let us know in the comments bar. We cannot answer all the comments, but we do read all of them. Also use the skill, do it a few times.

Also, if you get a low score, right? Bagon, you got 10 out of 10. Sometimes you got nine out of 10. Maximum probably the lowest score you've got in these assessments. I know it was like a nacked out of 10. Uh, but most of you watching us are not at that level yet, right? They're trying to get to that level. What if they get a one out of 10? What would you tell them? Go and do the mid level one first, refresh your knowledge.

What would be the best way to deal with that? Well, if you get a very low score and you are a senior, like uh, you're going for a front end engineering position, I would work my way up, junior, all the way to mid level and senior. And at least make sure you understand high level the concepts. Of course, everything I showed you is because I built things with those concepts. So it's not only about knowing how to explain them, but also like can you go into the browser and see where they compositor thread is or what are the compositor layers? I promise you 99% of developers cannot find the composition layers, but they are visible and you can find them in the Chrome developer tools.

So, it's one thing is knowing it, one thing is doing it. And if you do get the 10 out of 10, I would go for a more holistic approach, because we see a lot of interviews moving away from just plain react to even if you are a react developer or software engineer, they go for the full stack. As I always mentioned, do the technical assessment because in that technical assessment we do evaluate you on pretty much the whole full stack and the AI side of things, which is kind of new, the AI engineering. Two more ideas I would add.

Number one, you can also if you want if you want a structured way to senior and if you want personal feedback from Bogdan and I, as you get there with a clear path with much more in-depth technical assessments, then you can check the link below, also see if you qualify for the kind of mentorship we offer. And on top of that, I would say, go to the assessment and time yourself because this is a simulation of an interview, right?

You don't have infinite time. I would actually give myself a minute and a half and even record yourself with the loom, make a video and record yourself as you are verbalizing just like Bogdan does. Because the more you practice that, this is exactly what's going to happen in interviews or a subset of what you've been doing, right? And the more you can use this skill to practice that, the better you will get.

With that being said, Bogdan, thank you so much. 10 out of 10. Maybe we make a video where we tell cloud specifically to challenge you so we see how far you go. And folks, let us know what you believe about the format of this video if you want us to do more videos like that, if you want us to improve the skill, and we will see you in the next one.