DEV Community: Midhun Sundar

AWS Certifications Are Everywhere — Here's What Actually Matters More for Getting Hired

Midhun Sundar — Mon, 31 Aug 2026 05:46:08 +0000

Almost every fresher I train wants an AWS certification before they even understand what a VPC is. And I get why — certifications feel like proof, something concrete to put on a resume when you don't have work experience yet. But I've watched enough hiring conversations to know that the certification itself isn't what's actually getting people hired.

What the certification actually signals

A certification tells an employer you can pass a multiple-choice exam about AWS services. That's not nothing — it shows some baseline familiarity and commitment. But it doesn't tell them you can actually design something that works, debug it when it breaks, or make a sensible cost tradeoff between two approaches. Those are the things that come up in real interviews and real jobs.

What I actually see separate candidates in interviews

Being able to explain a decision, not just name a service. "I'd use S3 for this" is a certification-level answer. "I'd use S3 here because the access pattern is infrequent and cost matters more than latency, versus EBS if this needed to be attached to a single instance with low-latency reads" is the kind of answer that signals real understanding.

Having broken something and fixed it. Anyone who's actually built something on AWS has, at some point, misconfigured a security group, blown through a free-tier limit, or had a Lambda function time out for a non-obvious reason. That scar tissue is worth more than knowing every service name.

Understanding cost, not just capability. A lot of certified candidates can tell you what a service does but have never actually had to think about why a company would choose the cheaper, slightly less elegant option. Cost-awareness is an underrated signal of real-world thinking.

Where this leaves the certification

I'm not saying skip it — certifications still help you get past initial resume screens, and some companies do filter on them. But treat it as a floor, not a ceiling. The certification gets your resume looked at; a small number of genuinely built, broken, and fixed projects is what gets you through the actual interview.

What's worth doing instead of (or alongside) the exam

Build something small end-to-end — even a simple static site on S3 with CloudFront, or a basic Lambda-triggered workflow — and be ready to explain every decision you made
Deliberately break something in a sandbox account and practice diagnosing why
Read a couple of real AWS cost-optimization case studies, not just service documentation
Practice explaining architecture decisions out loud, not just recognizing the right answer on a quiz

The exam proves you studied. The project proves you can think. Interviews test for the second one far more than people expect.

I teach AWS training in Chennai at RedYellow Technologies, and this certification-vs-actual-skill gap is one of the first things I try to reset expectations on with new students. Curious how others weigh certifications vs. hands-on projects when hiring or interviewing.

Manual Testing Isn't Dying — Here's Why Beginners Skip It and Regret It Later

Midhun Sundar — Fri, 28 Aug 2026 05:09:06 +0000

Every fresher I talk to wants to jump straight into automation testing — Selenium, frameworks, CI/CD integration, the whole stack. Manual testing gets treated like a boring prerequisite to rush through, or worse, skip entirely. This is one of the more common mistakes I see, and it usually costs people more than they expect down the line.

Why the instinct makes sense on the surface

Automation is what gets posted about. It's what shows up in job listings as a "skill." It feels more technical, more impressive on a resume. Manual testing, by comparison, looks like clicking through screens and filling out spreadsheets — not exactly what anyone pictures when they imagine a QA career.

What actually happens when you skip it

Automation testing is, fundamentally, automating a process you already understand. If you don't have a solid grasp of how to manually test something well — what edge cases matter, how to think about a user flow, what "done" actually means for a feature — you end up automating the wrong things, or automating them badly. You can write a technically correct Selenium script that tests something nobody cares about, because you never developed the judgment to know what's actually worth testing.

I've seen this play out directly: candidates who jumped straight to automation frameworks can write scripts, but struggle in interviews when asked something like "how would you test this login form" without a script to lean on. The manual testing instinct — thinking through scenarios, edge cases, what could break — is the actual foundation. Automation is just a faster way to execute judgment you should already have.

Where manual testing skill actually shows up

Exploratory testing — genuinely understanding a feature well enough to find bugs nobody thought to write a test case for
Interviews — a huge chunk of QA interview questions are scenario-based ("how would you test X"), not "write me a script"
Working with product/dev teams — being able to clearly describe a bug, its impact, and how to reproduce it is a skill automation doesn't teach you
Knowing what NOT to automate — some things are genuinely faster and more reliable to check manually, and knowing the difference is part of the job

The realistic path

Manual testing and automation aren't really competing skills — one is the foundation the other builds on. Spending real time on manual testing fundamentals (SDLC, STLC, test case design, bug reporting) before rushing to Selenium isn't a delay in becoming a "real" QA professional. It's what makes the automation skills actually useful once you get there.

I teach both manual and automation testing training in Chennai at RedYellow Technologies, and this sequencing question comes up constantly with new students. Curious if others in QA roles feel the same, or if you went straight to automation and it worked out fine.

What Working in DevOps Actually Looks Like Day-to-Day (Not What Courses Promise)

Midhun Sundar — Tue, 25 Aug 2026 07:50:00 +0000

"DevOps" shows up in almost every job description right now, and almost every course promises to teach it. But ask ten people who actually work in DevOps roles what their day looks like, and you'll get ten different answers — because the marketing version of DevOps and the actual job are often two different things.

What the course pitch usually sounds like

Automate everything. Deploy with one click. CI/CD pipelines that just work. Infrastructure as Code that eliminates manual errors forever. All true in principle — but presented like DevOps is a tool you learn once and then everything runs itself.

What the job actually looks like most days

A lot of debugging pipelines, not building them. Once a CI/CD pipeline exists, most day-to-day work is figuring out why a specific build failed at 2am, not designing a new one from scratch. Reading logs is a bigger daily skill than writing YAML.

Constant negotiation between "fast" and "safe." Developers want to ship quickly. Security and ops want stability. A huge part of the actual job is sitting in that tension — deciding what gets automated, what still needs a human gate, and where the tradeoffs are worth it for this specific team.

More conversations than you'd expect. DevOps sits between development, operations, and often security — which means a lot of the job is translating between teams who don't naturally speak the same language. Someone who's only comfortable heads-down in a terminal often struggles here more than someone who's a decent communicator with solid fundamentals.

Incremental fixes, not big rebuilds. Most real DevOps work is improving an existing, messy, half-automated system one piece at a time — not architecting a clean pipeline from a blank slate, which is what most course projects simulate.

Why this gap matters for beginners

When the job doesn't match the pitch, new hires often assume something's wrong with them rather than recognizing the mismatch was in the expectation, not their skill. That's a fixable problem — but only if someone tells you upfront what the role actually involves.

What's actually worth learning first

If you're starting out, prioritize:

Reading and interpreting logs and error output over memorizing every tool's command syntax
Understanding the "why" behind a pipeline stage, not just copying a working YAML file
Basic Linux fundamentals and networking — these come up constantly and get skipped in a lot of fast-track courses
Communication habits — writing clear incident notes, explaining a tradeoff to a non-technical stakeholder

The tools (Jenkins, Docker, Kubernetes, Terraform) matter, but they're the easier part to pick up. The harder, more valuable skill is the judgment to know when and why to use them.

I teach DevOps training in Chennai at RedYellow Technologies, and this gap between the course pitch and the actual job is one of the first things I try to reset expectations on. Curious if this matches what others here have experienced, especially anyone who moved from a DevOps course straight into a role.

Java vs Python for Freshers: What Actually Gets You Hired Faster in 2026

Midhun Sundar — Mon, 17 Aug 2026 05:46:39 +0000

Every fresher I talk to eventually asks some version of the same question: should I learn Java or Python first? It's usually framed as a technical question, but the real answer has almost nothing to do with syntax.

The wrong way to decide

Most comparisons online focus on things like "Python is easier to read" or "Java is more verbose" — true, but not actually useful for deciding what gets you hired. Syntax difficulty stops mattering within your first few weeks of learning either language. What matters is which door it opens first.

What each one actually gets you, in practice

Java still dominates enterprise hiring — banking, insurance, large-scale backend systems, and most Tier 1/2 IT services companies run on it. If you're targeting a large, stable company with structured onboarding and a long career ladder, Java is usually the faster path in.

Python dominates a different set of doors — data roles, automation, AI/ML-adjacent positions, startups, and increasingly, backend work at product companies. If you're aiming at a smaller company, a data-flavored role, or anything AI-adjacent, Python tends to open that door faster.

Neither is objectively "better." They're optimized for different hiring pipelines.

The mistake freshers make

The biggest mistake isn't picking the "wrong" language — it's trying to learn both at a surface level instead of going deep on one first. A fresher who can genuinely reason about Java's memory model, object-oriented design, and how Spring Boot wires things together is more hireable than one who's dabbled in five languages but can't explain why any of their code works.

Depth beats breadth in your first job search. You can always pick up the second language once you're employed — companies are far more forgiving about learning a new language on the job than they are about hiring someone who can't demonstrate real fundamentals in any one language.

How to actually decide

If you don't have a strong pull toward data/AI work, default to Java — the sheer volume of enterprise hiring means more entry-level openings, especially in India's IT services market. If you're specifically drawn to data, automation, or AI-adjacent roles, Python is worth the focus, even though the fresher job market for pure Python roles is somewhat smaller and more competitive.

Either way, pick one, go deep, and resist the urge to hedge by learning both shallowly. That hedge feels safer but usually produces a weaker interview candidate than committing to one.

I see this exact question come up almost every week teaching Java and Python training in Chennai at RedYellow Technologies. Curious which way others here landed, and whether it worked out the way you expected.

What AI Coding Tools Are Actually Changing About Technical Interviews

Midhun Sundar — Tue, 11 Aug 2026 06:34:42 +0000

A few years ago, a technical interview mostly tested one thing: can you write correct code, from memory, under pressure. That bar has quietly shifted — and a lot of developers preparing for interviews right now haven't fully clocked it.

AI coding assistants are part of daily work at most companies now, from big IT services firms to small product teams. Interview panels have adjusted to that reality faster than most prep guides have.

What's actually different now

Interviewers care less about whether you can produce a function from scratch, and more about whether you understand what code is doing and why. It's increasingly common to be handed a piece of AI-generated code and asked to find the bug, justify a design decision, or optimize it — instead of writing something from zero on a whiteboard.

Some companies go further and let you use AI tools during the technical round, then evaluate how well you direct the tool, verify its output, and catch its mistakes. The skill being tested has moved from "can you write code" to "can you reason clearly with code as your material."

Three things I keep seeing candidates get wrong

Treating a finished course or degree as the finish line.
Completing a syllabus tells an employer you were exposed to concepts. It doesn't tell them you can apply those concepts to a messy, real-world problem — which is exactly what open-ended interview scenarios are designed to expose.
Leaning on AI tools without understanding the output.
Using an AI assistant while practicing at home is fine. The problem shows up when that habit surfaces in a live interview as an inability to explain your own solution. If you can't walk through why a piece of code works, a couple of follow-up questions will make that obvious fast.
Underrating communication and debugging skills.
As AI tools take on more initial code-writing, the human value shifts toward reviewing, debugging, and explaining decisions to teammates. Candidates who only practiced writing code — and never practiced talking through their reasoning out loud — often struggle here, even with solid technical knowledge.

What's actually worth practicing

If you're prepping for interviews right now, a few adjustments make a real difference:

Practice reading and debugging other people's code, not just writing your own — it mirrors what the job looks like today
Get comfortable explaining your reasoning out loud — more interviews are structured as conversations, not silent coding tests
Spend time on the"why" behind core concepts — data structures, system design basics, how a query actually behaves — since that's the judgment an AI tool can't substitute for you

Fundamentals still matter — arguably more than before, because they're what separates someone who can direct and verify an AI tool from someone who's just along for the ride.

I train aspiring developers at RedYellow Technologies in Chennai, teaching Java, Python, AWS, DevOps, Data Science, and AI. Curious how this matches what others are seeing in interviews right now — drop a comment if your experience looks different.