As an independent interviewer,¹ the most impactful thing I do is write actionable feedback. After 35 interviews with my Event Queue question, I started to notice patterns — candidates kept making the same mistakes. So I went through every piece of feedback I'd written and distilled it here. Learn from their mistakes so you don't have to make your own.

You are coding far too slow. You are moving at the pace of a Java engineer despite using JavaScript. Even if you "dot your Is and cross your Ts," it won't matter if you don't get far enough in the problem. The interviewer won't have enough evidence to pass you.

Java is less forgiving with syntax. Keep running the code frequently to spot any such errors and keep moving faster. Having to go back and fix a syntax issue or an import issue from 15 lines of code will slow you down.

Speed is critically important. You did well on part 1 and had a good start to part 2. But we barely moved on from that part. An interviewer will have a harder time making the case that this is a good engineer when there is less code and problem solving progress to rate off of.

If you're going to interview in Python, make sure you know the language really well, not just being able to solve LeetCode problems. Your ability to move quickly in a language is paramount. That matters more than the conveniences a certain language might bring.

Before googling for answers, formulate a debugging strategy first. Think about what the root cause might be and share those thoughts with your interviewer — they may give you suggestions.

Write better, more intentional print statements. Consider what information is actually relevant, add annotations to your logs (e.g. print('Queue size:', len(self.queue))), and read them carefully. Don't log entire response objects when the status code is all you need. The answer is almost always in the logs the first time — read them before reaching for Google.

Test as you go without the interviewer prompting. Test each individual function. This will help you move faster because you'll fix bugs right after they are made, not 15 lines of code later.

Be careful when running any recursive or looped code. Take an extra second to rubber duck those lines before executing to ensure you won't crash the coding environment and waste interview time.

Break your code into small functions and abstract out constants as you go — do it incrementally, not at the end. This prevents bugs, makes them easier to spot, and helps you rubber duck more effectively. Always think about separating concerns; for example, abstracting out retry logic like processBatchWithRetries(batch, attempt = 1) keeps that concern away from the code that calls it. Badly organized code cost you real debugging time during the interview.

Don't forget to indent your code. After you've finished an interview, other engineers will read it and make decisions on your candidacy based on it. If it's not clean and easy to read, it will be harder for those engineers to judge you favorably.

Be intentional about naming. "getMessage" doesn't make much sense for a function that adds messages to the queue — "get" implies it would return something. Names should reflect what the function actually does.

A good interview is a conversation. It's you and the interviewer working together to get you to the right solution. When the interviewer asks you for ideas, give your thoughts and listen for their feedback. Don't get caught up in your own ideas.

You should be communicating with the interviewer in such a way that you are pulling clues out of the interviewer and asking questions about their expectations. Ideally, the interviewer doesn't have to feed you so many clues.

Consider your audience when speaking: Why is it that they are asking me this question? What is it they are trying to get out of me? If applicable, how can I make my answer a conversation to ensure my interviewer is engaged?

If you need to pause and explain before you code, great! If you want to pseudocode your thoughts to explain, great! Find an approach that works for you. Much of what live coding interviews are testing are your communication skills. You need to make sure the interviewer understands what you are thinking when or before you start coding.

Read deeply into the problem. Try to understand what it's asking. I highly recommend buying or utilizing teaching resources to teach you how to analyze problems (CTCI for example). Find the right one for you and practice problems without AI's help.

LeetCode is an effective practice tool, but don't mistake it for how real software is written. Think about the context of the problem you're solving. I was satisfied with the end solution, but ideally we could have gotten further in the question. We lost too much time at the beginning properly understanding the problem.

You have the right instincts to pseudocode and gather requirements before you start coding. Make sure that practice continues as the problem gets more complex like it did in part 2.

Senior engineers are very good at thinking about what will go wrong with their code. You ultimately spend more time handling error cases than success cases in the real world. Always think about how your code might break and figure out what the best action is to fix. Get feedback from your users in the real world and your interviewer during an interview.

Good candidates identify potential issues, share their opinions on how to address it, and listen to my feedback.

Generally, you want to think about the execution of async code as being completely separate from regular code. Cloning the array and passing that into your async code is one of the cleanest ways to avoid race conditions impacting the original queue. This is a fairly common pattern and a very easy way to solve that problem.

Consider the promise as a completely different scope (though technically it is not). You struggled with this when you tried to make an async context to test your code, which wasn't necessary.

Broadly, just practice more with promises. Most JS engineers don't have a deep understanding of how they work. It's a bit cliche, but try implementing one from scratch. It's a good exercise if you've never done it.

Add your async/await with a bit more care. When I see candidates who just make every function async, it's generally a sign they don't really understand what async/await does.

Get faster using documentation. I don't expect you to have the python request API memorized. I do expect you to find and utilize the documentation efficiently considering this is a package you were previously familiar with.

I don't mind copy-pasting code found via google or stack overflow, but this introduced bugs into your solution. Take some time to understand the code examples you find online before using them.

Use the official documentation. You were using Gemini generated code or from another not-great source. This slowed you down. Typically, the official documentation is best; default to using that.

Skilled juniors can debug new syntax / problem environments very effectively with a combination of coding quickly and using documentation effectively.

After running your network request code you asked: "is everything ok?"

I know what is going on, I've seen this problem solved 30 times. But why don't you know what's going on? It's your code! Test and log it accordingly! You asked this question as if you were scared of my answer. You should see the interviewer as a collaborator, not a judge (even though they are a judge).

Who is a company more likely to hire? Someone who can lead the charge during an interview? Or someone who is timid? Assuming the performance on the question is the same, I want a hire an engineer who I can trust to take on a ticket and get as far as they can independently before asking for my help.

As an interviewer, I only have an hour. I can often tell when someone is a good engineer despite their poor performance. But since I don't have clear evidence of their problem solving and code, I can't pass them on to the next step. So you have to practice interview problems in an artificial environment and get comfortable with default tools like debugging with print statements.

When you are receiving feedback, do not make excuses. Companies do not often share feedback because it is a headache for reasons like this. It does not reflect well and it will worsen their impression of you. You may not asked to be come back to interview again.

I don't really care, I'm an agency recruiter, I'm here to help you get better. But it doesn't make me think you have a growth mindset. I want engineers to come back and interview again after they receive their feedback and do more practice.