DEV Community: Midhun Sundar

Everyone Wants to Be a Data Scientist — Almost Nobody Wants to Clean Data First

Midhun Sundar — Sat, 12 Sep 2026 07:46:54 +0000

Ask any data science student what they want to work on, and the answer is almost always some version of "build models," "do machine learning," "work with AI." Ask them how they feel about spending 70-80% of a real project cleaning and preparing data before any of that happens, and you get a very different reaction.

This gap between the fantasy and the actual job is one of the most consistent things I see training students moving into data roles.

The part nobody puts in the course trailer

Real datasets are messy in ways that are hard to appreciate until you've dealt with them. Missing values that aren't marked as missing — they're just blank, or zero, or "N/A" typed as text instead of an actual null. Dates stored in four different formats across the same column. Duplicate records that aren't exact duplicates, just close enough to cause problems. Categorical values with inconsistent spelling ("Chennai," "chennai," "CHENNAI," "Chenai") that all mean the same thing but won't group together without cleaning.

None of this is intellectually thrilling. All of it determines whether anything built afterward is trustworthy.

Why this is the actual skill, not a chore before the skill

A sophisticated model trained on messy, unvalidated data produces confident, wrong answers — which is worse than an obviously broken system, because people trust the output. The judgment involved in data cleaning — deciding how to handle a missing value, whether an outlier is a data entry error or a genuine signal, whether two records really represent the same entity — requires as much domain understanding and critical thinking as choosing between algorithms. It's just less visible, and it doesn't photograph well for a portfolio.

What this looks like in a real project

A typical week on a real data project might involve: pulling data from three different sources that don't use the same customer ID format, figuring out why 12% of a column is unexpectedly null, deciding whether to drop or impute those values and being able to justify the choice, and then — only after all of that — actually building and evaluating a model. The modeling step, ironically, is often the fastest part.

Students who've only practiced on pre-cleaned datasets (the kind that come bundled with a tutorial, already tidy and ready for .fit()) are often caught off guard by how much of a real job doesn't look like that at all.

What's worth practicing early

Deliberately work with a messy, real-world dataset instead of a pre-cleaned tutorial one — government open data portals are a good source of genuinely messy data
Practice explaining why you handled a missing value a certain way, not just that you handled it
Get comfortable with the tedious parts of pandas (or your tool of choice) — merging, reshaping, deduplicating — since this is where a huge amount of real time goes
Resist the urge to jump to modeling before you've actually understood what's wrong with your data first

Cleaning data isn't the boring prerequisite to the real work. For most practitioners, most of the time, it is the real work — and treating it that way early is what makes the modeling part, when it finally happens, actually trustworthy.

I teach Data Science and Python training in Chennai at RedYellow Technologies, and this expectation gap is one of the first things I address with new students. Curious how much of this matches what others have experienced moving from coursework into real data work.

Ethical Hacking Courses Teach You to Break In — Nobody Teaches You What Happens After

Midhun Sundar — Thu, 03 Sep 2026 06:26:17 +0000

Every ethical hacking course I've seen follows the same arc: reconnaissance, scanning, exploitation, gaining access. The finish line is always the same moment — you got in. Capture the flag, pop the shell, root the box. That's where the course ends and the applause happens.

Nobody spends much time on what a real cybersecurity job looks like after that moment, which is a problem, because "getting in" is maybe 20% of the actual work.

What the course teaches you to care about

Finding the vulnerability. Exploiting it cleanly. Documenting the exploit path so it's reproducible. All genuinely important skills — but they're the skills that get tested in a CTF competition, not necessarily the skills that get you hired and kept employed.

What the job actually asks for after that moment

Writing a report someone non-technical can act on. Finding a critical vulnerability means nothing if you can't explain its business impact clearly enough that a manager approves the fix over some other priority. A lot of technically brilliant findings die in a report nobody understood or took seriously.

Prioritizing, not just listing. A real engagement often surfaces dozens of findings. Part of the job is telling a client which three actually matter this quarter and which twelve can wait — a skill that has nothing to do with exploitation technique and everything to do with judgment.

Following up. Did the client actually patch it? Is the fix effective, or did it just move the vulnerability somewhere else? Ethical hacking courses rarely simulate this loop, but a huge part of a real security career is verification, not just discovery.

Working inside constraints. In training, you attack a deliberately vulnerable box with no rules. In a real engagement, you operate inside a signed scope agreement, sometimes during a specific maintenance window, sometimes with production systems you genuinely cannot afford to break. Staying inside those lines while still doing thorough work is its own skill.

Why this gap matters for beginners

Students who only trained on "get the flag" often assume a security career is a nonstop stream of exciting exploits. The reality includes a lot of writing, a lot of waiting for approvals, and a lot of politely re-explaining risk to people who don't want to hear it. That's not a lesser version of the job — it's the actual job, and being unprepared for it is a common reason people burn out or underperform in their first security role.

What's worth practicing early

Write up your practice exploits like a real client report — not just "I got root," but why it matters, how bad it could get, and what to do about it
Practice explaining a technical finding to someone non-technical — a parent, a friend, anyone outside the field
Learn to read a scope document, not just a target IP — understanding what you're allowed to touch is as important as knowing how to touch it
Get comfortable with "no" — not every finding gets fixed immediately, and handling that without losing credibility is part of the job

I teach Ethical Hacking and Network Security training in Chennai at RedYellow Technologies, and this gap between "can you hack it" and "can you actually work in security" is one of the first things I try to reset expectations on. Curious if this matches what others in the field have experienced.

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.