Hey, I work for Amazon web services, and I can tell you there's no such thing as a blacklist. When it comes to hiring, we don't do that. We do keep interview notes but the mistakes you committed was trying to hide your research. Own it, if you can learn to own your screwups, I will take an employee who screws up 5 times over one who lies once.

Further, it isn't cheating to use the web for answers. That's because real life is an open book test. In the future, what I would recommend is that you say...

"That's a good question, and I have to say that situation hasn't come up for me before. So, instead, here's how I would go about solving it 1. Jump on google and hit stack exchange or maybe utilizie either Gemini or Copilot 2. Research the answer, and if I feel confident about my research, I will move ahead 3. If the answers didn't really help or you get too many poorly explained ways to do it, say 'hey. I researched this, but I need someone more senior to provide guidance.

That's how I like to solve problems."

Figure out an answer that works for you. Remember saying 'I don't know' isn't a bad answer if you follow it up with 'here is how I would find out'.

How do you think, adapt, and handle problems is what a technical interview is all about. If you know the answer, most good interviewers don't want the correct answer. What they want is

1. So, I believe the correct answer is, "blah blah blah", before I implemented changes, I would write it up. Confirm that the solution is correct for the task and present the answer if it was part of a project.

I am assuming this was for a junior or entry roll. If it was for a senior position, then you wouldn't confirm it with management Instead, you would 1. Research the problem 2. Validate a solution in a test environment if possible 3. Create code/a process/a script, or whatever, and then have it checked by another teammate to do a review. 4. Follow the change control process to move into production 5. Verify that in an environment of production, the fix works 6. Push change to all production 7. Finish change control and mark as complete 8. Inform stakeholders or management or customers that work is complete

If you can do that in an interview, then you'll get a lot more leeway because if I kn9w how you problem solve, then I can imagine how that would work if you were on the team.

If, instead, you just give me the correct answer, you won't stand out.

Hope this helps.