To-do list for new age Software Engineers

Tripti — Thu, 08 Oct 2026 18:08:22 +0000

AI era is here and most software engineers like me are probably not ready.
Before continuing with this blog I recommend the readers to watch these two videos and read this one blog for context:

AI tools can now write a lot of code. So if you are a new grad, it is fair to ask: what should I actually learn? Should I still solve LeetCode problems? How much should I depend on AI? Do I need system design this early?

This post answers those questions. It is based on a HackerRank blog post called The New Technical Hiring Bar: CS Fundamentals, AI Fluency, and Judgment (August 2026). That post is written for hiring teams. Here it is turned into a plan for candidates.

What the article says

The old technical interview asked one question: can this person write correct code alone, under time pressure?

That made sense when writing code was the hard part. With AI coding assistants, writing code is no longer the rare skill. The rare skill is knowing what to ask the AI to build, when to trust what it gives back, and when to reject it.

HackerRank's CEO, Vivek Ravisankar, says LeetCode scores alone do not show whether someone can work alongside AI or handle a real codebase. He is not saying fundamentals are useless. He is saying fundamentals alone do not predict enough.

So the article describes a new bar with three layers. All three matter. One cannot replace another.

CS fundamentals. Complexity analysis, data structures, and knowing why a solution is correct, not only that it passed the tests. This is the floor. Without it, you cannot tell when the AI is wrong.
AI fluency. This is more than "I have used ChatGPT". It means writing prompts that get useful output, reading AI code with a critical eye, catching the small bugs that models introduce, and knowing which tasks to give to an AI agent and which to do yourself. Knowing the tools is the minimum. The real skill is directing them to a correct result.
Judgment. Decisions that have no textbook answer. When to accept technical debt and when to refactor. When a "good enough" AI solution really is good enough. The article also calls this care and taste: the difference between shipping something that works and shipping something that is right for the situation.

Three takeaways for new grads

1. Problem solving still matters, but only if it is real

Solving problems on LeetCode, CodeChef, and similar sites is still important. But the value comes from the struggle, not from the number of problems solved.

Watching a YouTube solution and typing it out teaches very little. Watching a solution is fine after you have been stuck for 30 to 40 minutes, as long as you solve the same problem again from scratch a few days later. If you skip the stuck part, the practice is worthless.

2. Use AI, but understand what you ship

A simple test: could you explain this code, debug it, and defend it in a code review?

For core logic, data handling, and anything related to security, this means understanding it line by line.
For boilerplate and config, it is enough to know what it does and how to check that it works.

While you are still learning, stay on the strict side. If you cannot reason about the basics, you will not notice when the AI's suggestion is wrong.

3. Learn system design, but do not try to "master" it yet

The article does not mention system design. It talks about judgment in tradeoff decisions. System design is a good place to build that judgment, but nobody expects a new grad to design a large distributed system.

Low-level design matters more right now. Structuring classes, modelling data, designing clean APIs, and writing code that is easy to change. You will do these from your first day, and they are commonly tested for entry-level roles.
For high-level design, aim for working knowledge. Know what databases, caches, queues, and load balancers are for, and be able to say why you would pick one option over another.

Being able to say "I chose X over Y because of Z, and I would switch if W" is more valuable than memorising standard architectures. That sentence is the judgment layer in action.

The action plan

Start this week

Audit yourself. Take some code you recently wrote with AI help. Explain every line, its complexity, and one input that breaks it. Do this out loud and without AI. Whatever you cannot explain becomes your study list.
Split your time into two modes. Fundamentals practice is AI-off. Project work is AI-on. Mixing the two is how people end up weak at both.
Start a decision log. Keep a file in your project repo. For every non-trivial choice, write three lines: the options you had, what you picked and why, and what would change your mind.

Layer 1: Fundamentals (daily, 45 to 60 minutes, AI-off)

Solve one problem a day without help. Then write two sentences: why your solution is correct, and what its time and space complexity is. Ask AI to critique it only after you are done.
Pick one core subject each month: databases, operating systems, or networking. Build something small by hand in each one, such as a key-value store, a shell, or an HTTP server.
When you hit a bug, debug without AI for the first 20 minutes. Reading stack traces and forming your own guesses is the skill that fades fastest.

Layer 2: AI fluency (during project work)

Write the spec before the prompt. Note the inputs, outputs, constraints, and edge cases first.
Review every AI change like a junior developer's pull request. Never merge code you could not have written or cannot explain.
Own the tests. Write them yourself or review them carefully. Good tests are what make it safe to hand work to AI.
Do a weekly bug hunt. Ask AI to generate something non-trivial, then find what is wrong with it: missed edge cases, invented APIs, security holes, concurrency problems. Write down the patterns you see.
Predict before you delegate. Before each task, decide whether it should go to the AI agent or to you. Afterwards, check whether you were right.

Layer 3: Judgment

Judgment only grows through real consequences and feedback.

Ship one project to real users, even if it is only five people, and maintain it for a couple of months.
Get code review from humans. Contribute to open source, or exchange reviews with friends.
Read one engineering postmortem or design document every week. Before you read the conclusion, decide what you would have done.

Getting hired

Go deep on one project instead of building five tutorial apps. Use the README to explain your decisions: what you gave to AI, what you overrode, and what you would do differently.
Prepare for three interview formats:
- coding without AI
- coding with AI, where you say out loud what you accept and what you reject
- tradeoff discussions

Ask each recruiter which format they use.

Use your decision log as your answer bank. The article says judgment is tested with real tradeoff scenarios and follow-up questions, not rehearsed stories. Real decisions hold up when the interviewer keeps digging. Rehearsed stories do not.

One caveat

HackerRank sells an AI interviewer called Chakra that is built around this same three-layer idea, and the post does not give any data. Treat it as one company's view, not as proven fact.

The article also admits that most hiring processes still do not test AI fluency at all. That means classic coding rounds without AI are still the gate at many companies. Do not drop your daily problem practice.

Quick checklist

Every day

One problem solved without help, with two sentences on correctness and complexity
20 minutes of debugging on your own before asking AI

Every week

One AI bug hunt
One postmortem or design document
New entries in your decision log

Every month

One core subject (databases, operating systems, or networking) with one small hand-built project

Ongoing

One deep project, shipped to real users and maintained
Human code reviews
Low-level design practice, plus working knowledge of high-level design

Final thought

Fundamentals let you catch the AI when it is wrong. AI fluency lets you move fast. Judgment decides whether what you built is the right thing. Build all three, and you will be ready for both the interview and the job.

DEV Community: Tripti