I have about seven years of IT experience, hold an Azure Administrator certification, am an AWS Solutions Architect certified professional, and have a bachelor's degree. I've been working as a cloud administrator for roughly a year and a half, and I'm currently interviewing for a role I'm genuinely interested in.
I struggle with technical interviews because I don't always recall technical details immediately, even when I've encountered related concepts before. In an earlier interview, I was asked about EKS encryption, containers, and IAM. I don't regularly work with containers or encryption, and my IAM experience is mostly limited to assigning built-in or custom roles. Security isn't my primary focus.
I'm concerned the next interview will involve detailed scenario questions or technologies I haven't used directly. I also tend to lose confidence when I'm put on the spot. Has anyone been in a similar situation and still landed the job? How should I handle questions when I don't know the answer?
4 Answers
There isn’t a magic phrase that can replace missing experience, but you can prepare efficiently. Use the job description to identify the main services and responsibilities, then review the fundamentals and practice explaining your reasoning out loud. For unfamiliar tools, focus on transferable concepts such as identity, networking, encryption, logging, availability, least privilege, and safe change management. Don’t assume that not knowing one product makes you unintelligent; it may simply be outside your current role.
Try turning the questions into a conversation. If you have related experience, explain the connection and walk through your assumptions. For something unfamiliar, you could say, “I haven’t administered that service, so I don’t want to pretend otherwise. I’d start by checking the official documentation, reviewing the current configuration, testing the change in a nonproduction environment, and escalating if it affected security or availability.” That demonstrates judgment and a practical troubleshooting process.
Be honest when you don’t know something. Interviewers generally prefer hearing, “I haven’t worked with that directly, but here’s how I’d investigate it,” over a confident-sounding guess. Explain what you do know, describe how you would consult documentation or test safely, and mention when you would involve a teammate. Making things up is usually much more damaging than admitting a gap.
That makes sense. I worry that saying “I don’t know” too many times will end the interview, but I’ll try to explain how I would work toward the answer instead of stopping there.
Technical interviews are partly testing how you respond during an incident, not just whether you can recite facts. IT changes too quickly for anyone to memorize everything. Show that you can learn, research, ask good questions, assess risk, and document the solution. Also review the job description and prepare examples from your own work involving outages, permissions, automation, troubleshooting, and communicating with other teams.
Exactly. I’ve done better when I explain how I would find and validate an answer instead of trying to guess a product-specific detail from memory.