I’m a DevOps Engineer working from 2022 in one of the largest IT companies in Pune. I design and manage CI/CD pipelines using Jenkins, build and deploy containers using Docker and Kubernetes, automate infrastructure with Terraform, and work daily with AWS services like EC2, S3, IAM and CloudWatch.
I write automation scripts using Bash, Linux shell scripting, Python, and sometimes Perl. I troubleshoot production issues at 2 AM with a cup of chai in my hand. I’ve broken pipelines, caused outages, fixed them, and learned lessons the hard way.
But here’s something important.
A few months ago, I was also a candidate.
I recently switched my job. I was sitting on the other side of the interview table, preparing, revising fundamentals, thinking about what questions might come. I know the nervousness. I know the pressure. I know that feeling when your mind suddenly goes blank even though you studied everything.
And now, just months later, I’m on the other side as an interviewer.
That shift changed my perspective completely.
When you are a candidate, you focus on “What questions will they ask me?” When you are an interviewer, you focus on “Can this person take responsibility at 2 AM when production is down?”
That difference changes everything.
For the last few months, our project load increased a lot. New deployments, more environments, tighter deadlines, more monitoring, more firefighting. On top of that, I’m also managing part of the team, reviewing work, guiding juniors, attending calls, handling escalations. Ek taraf technical pressure, dusri taraf team management.
Slowly I realized I was handling too much alone. If one more major production issue came at night, things could easily become chaotic. We needed support. Not just someone who knows tools in theory, but someone who can actually take ownership.
So we decided to expand the team.
Some of you might say, “Arey VAP, DevOps me toh log mil jaate hain. Market me bahut candidates hain.”
Yes, candidates bahut hain.
But strong, ready, hands-on engineers? Bahut kam.
I honestly thought hiring would be simple. I believed we would interview five or six people and close it quickly. But when interviews started, reality hit differently.
I screened more than 30 candidates.
On my resume, almost everyone looked strong. Kubernetes, AWS, Docker, Terraform, scripting, everything properly listed. If you just read the resume, you would think this person is perfect.
But once the conversation started, the picture change ho gaya.
Basic questions pe hesitation. Real project explanation per confusion. Practical troubleshooting pe silence.
Some candidates had little potential. You could see they were trying and learning. But they were not fully ready yet. Those profiles went on hold. Some got rejected because the gap was too big. And the hiring process is still going on because I don’t want to hire just to reduce workload temporarily. I want someone who can actually handle production responsibility without constant guidance.
This whole experience made me think deeply.
When I was a candidate recently, I prepared seriously. I revised Linux basics, networking concepts, IAM policies, deployment flow. I practiced explaining my projects clearly. Now when I compare that preparation with what I am seeing in interviews, I can clearly see the gap.
This experience made me think deeply. We often hear that there is unemployment. But what I am seeing from this side is a serious skill gap. Many people are trying to enter DevOps or tech roles, but they are not preparing at the level the industry now expects in 2026.
Let me share what I noticed.
Let me be very clear. Most rejections were not because candidates were “bad.” They were rejected because they were not industry-ready yet. There is a difference.
1. Not Researching the Company (Before the Interview Even Starts)
Many candidates join without knowing what the company actually does. When I ask, “What do you know about our company?”, some say, “Not much.” That immediately shows lack of effort. You don’t need deep research. Just spend 10–15 minutes on the website. Understand the product, services, or domain. It shows seriousness.
2. Not Coming on Time
Interview timing is scheduled carefully. When a candidate joins 10–15 minutes late with excuses, it creates a negative impression from the start. Being early shows professionalism. Late joining shows carelessness.
3. Poor Setup – Internet, Silent Place, Camera Angle
This happens before you even speak. Unstable internet, background noise, TV sound, family talking loudly, or poor camera angle showing ceiling, all of this affects the impression. One candidate was sitting casually on a bed. It looked unprofessional. Sit properly. Keep the camera at eye level. Choose a silent place. These things matter.
4. Weak Introduction or Overlong Introduction
The first minute decides energy. Some candidates spoke for 5–6 minutes about unrelated things. Others finished in 20 seconds without mentioning experience. A strong introduction is simple, name, experience, current role, core strength. Clear and structured. No life story. No confusion.
5. Poor Communication Skills
Communication is one of the biggest deciding factors. Some candidates spoke too fast. Others too slow. Some were not structured in answers. You don’t need complex English. Simple English is enough. But clarity, confidence, and steady pace are very important. If you cannot explain your own project clearly, it creates doubt about your understanding.
6. Lying or Exaggerating in Resume
If you write Kubernetes, I will ask Kubernetes. If you write Terraform, I will ask about state files and modules. Many candidates listed tools they had only watched tutorials about. When basic questions were asked, they struggled. Once trust breaks, the interview becomes very difficult to recover.
7. Only Theoretical Knowledge, No Hands-On Experience
Many candidates could define DevOps perfectly. But when I asked, “Explain your last deployment step by step,” answers became vague. DevOps is practical. I want to know what you did, what failed, how you fixed it. Real experience shows in small details.
8. Weak Fundamentals
Some candidates talked about advanced tools but struggled with Linux basics, networking concepts, HTTP status codes, or simple scripting logic. Without fundamentals, advanced tools don’t help. Strong basics create strong engineers.
9. Not Handling Criticism Properly
When I pointed out flaws in their solution, some candidates became defensive. One even argued continuously. That attitude is risky. In real projects, feedback comes daily. A mature candidate listens, thinks, and improves the answer.
10. Trying to Do Malpractice During Interview
Some candidates clearly tried searching for answers. Eye movement, typing sounds, delayed responses, it becomes obvious. Instead of cheating, it is better to say you don’t know and explain your approach. That shows honesty and a problem-solving mindset.
11. Speaking Without Structure or Losing Control of Pace
Some answers were all over the place. No structure. Jumping between topics. Others rushed answers. Communication is not about speed. It is about clarity. Take a second. Think. Then answer in a structured way.
12. Domain Switching Without Clear Direction
Resumes showing multiple unrelated domains in a short time raised concerns. When asked why they shifted so much, answers were unclear. Early exploration is fine, but after some experience, you must show direction.
13. Switching Jobs Too Frequently Without Strong Reason
Multiple job changes in a short span created doubt about stability. When reasons were weak or unclear, it became risky to hire. If you switched jobs, explain clearly what you learned and why you moved.
14. Acting Over Qualified or Overconfident
Confidence is good. Arrogance is not. Some candidates kept repeating their certifications and tried correcting unnecessarily. Companies need team players who can collaborate, not compete internally.
15. Ending the Interview Poorly
Last impression matters. Many candidates ended with just “okay thank you” and disconnected. No interest shown. A strong candidate thanks the interviewer properly, expresses interest in the role, and asks 1–2 thoughtful questions about the team or challenges. That shows engagement.
16. Not Showing Ownership Mindset Another pattern I noticed was the lack of ownership in answers. Many candidates kept saying, “We deployed this,” “Team handled production,” or “They configured the cluster.” That immediately creates confusion about what the candidate actually did. In interviews, I am not evaluating the team, I am evaluating you. I want to clearly understand your contribution. Say, “I configured the Jenkins pipeline,” “I wrote the deployment script,” “I handled this production incident and performed RCA.” Ownership language builds trust. It shows accountability, confidence, and clarity. In DevOps, especially in production environments, ownership matters more than tool knowledge.
Right now, the interview process for our team is still ongoing. Some candidates have potential but need more hands-on practice. Some were not ready yet. I’m still looking for engineers who are strong in fundamentals, honest about their skills, calm under pressure, and practical in their thinking. My goal is not just to fill a position but to build a team that can reduce workload, handle production responsibly, and grow together.
Let me say something uncomfortable but true. The market is not rejecting people because of a lack of degrees. It is rejecting people because of lack of depth.
If you are preparing for interviews in 2026, understand this clearly: selection is not about knowing every tool in the market. It’s about clarity, fundamentals, real project exposure, professionalism, and attitude.
The competition is high, yes. But the expectations are also clear.
If you avoid these mistakes and prepare seriously, you automatically move ahead of most candidates.
Now I want to ask you something honestly, which of these mistakes have you made before? And what are you doing to improve?
Let’s talk in the comments. Let’s grow properly, not just update resumes.


0 Comments
Please do not enter any spam link in the comment box.