After more than 20 years supporting on-premises infrastructure for a large Fortune 100 company, I was recently displaced through no fault of my own. For many of the technical roles I'm applying to, I meet roughly 80% of the listed requirements. For the remaining skills, I usually understand the concepts at a high level but lack extensive hands-on experience.
Before interviews, I've been trying to cram as much as possible about those weaker areas. Often they never come up, and the preparation is becoming exhausting. I know from experience that I can learn new technologies quickly, solve difficult problems, and put in the effort required to become productive.
How can I communicate that effectively without pretending to be an expert or sounding uncertain? If an interviewer asks about a technology I haven't used much, what's the best way to explain what I do know, acknowledge the gap, and show that I can learn it quickly?
5 Answers
Use specific stories from your career. If you haven’t worked with a particular tool, connect it to a time when you had to learn a new platform from scratch, implement unfamiliar technology, or troubleshoot under pressure. Explain the situation, what you did, and the result. That gives the interviewer evidence of adaptability instead of just asking them to take your word for it.
Your track record is the strongest proof. Decades of supporting production systems, solving incidents, learning new platforms, and taking responsibility matter more than memorizing every current buzzword. Prepare a few concise examples that demonstrate troubleshooting, learning quickly, handling change, and collaborating with others. Those stories can answer many interview questions without requiring you to cram every missing keyword.
Be straightforward about your level of experience. You can say, “I’ve had limited hands-on work with that technology, so I wouldn’t call myself an expert, but I understand the general concepts and know how to get up to speed.” Then explain how you normally find answers—documentation, vendor knowledge bases, testing, internal references, or asking experienced teammates. Showing that you can learn methodically is more convincing than bluffing.
Don’t try to project confidence about things you don’t know. Project honesty, sound judgment, and a clear learning process instead. A confident answer can be, “I don’t know that well enough to give you a reliable answer, but here’s what I do know, here’s how I’d investigate it, and here’s a comparable problem I’ve handled.” For senior infrastructure roles, recognizing uncertainty is much safer than confidently giving an answer that could cause an outage.
Hiring managers generally don’t expect a perfect match for every line in a job description. A useful answer is: “I haven’t worked directly with X, but I’ve solved similar problems with Y, and the way I would approach this would be…” Then walk through your reasoning. Be confident about your transferable knowledge, but don’t claim certainty where you don’t have it.
It also helps to remember that the interview goes both ways. You’re evaluating whether the team can support reasonable onboarding and whether that technology is actually central to the job. That mindset can make the conversation feel less like a test.