Between 2020 and 2024 I ran the program that took Graduate Engineer Trainees (GETs) at HCLTech from zero-cloud-exposure to deployable L2 cloud engineers. We ran it three times, iterated between cohorts, and shipped 70-plus engineers into billable projects. Here's what worked and what didn't.
What didn't work
Certification-first curricula. Sending someone to a Cloud Practitioner course before they've seen a real AWS account produces someone who can pass an exam and cannot debug an instance that won't boot. Certifications are useful. They are not a training program.
Video courses. Excellent as a reference. Terrible as a curriculum. GETs watched the videos, took notes, and forgot everything in six weeks because they hadn't used any of it.
Shadowing without ownership. Putting a GET next to an experienced engineer to "learn by watching" produces neither confidence nor competence. They learn what a senior person doing routine work looks like, which is not what they'll be doing.
What worked
Real tickets from day three. Each GET was assigned to a project team and given actual (small) tickets by end of week one. Backup verification, log rotation, security group audit. Things that were both real and low-risk.
A mentor pool, not a mentor. Every GET had a "primary" senior engineer but was explicitly encouraged to ping anyone in the pool. This solved the problem where one senior engineer becomes a bottleneck for one GET.
Documented mistakes. Every mistake a GET made — misconfigured security group, accidentally-terminated instance, IAM policy that broke a Lambda — got written up as a one-page post-mortem. Not for blame. For pattern recognition. Cohort 2 read cohort 1's mistakes. Cohort 3 read cohorts 1 and 2's.
A weekly show-and-tell. Each Friday, one GET presented a thing they'd done that week to the rest of the cohort. Ten minutes each. This is where most of the actual peer learning happened.
Explicit "you're allowed to break things in the sandbox." Every GET got a sandbox AWS account with a hard $200/month budget cap. The message was: break things. That is what the sandbox is for. GETs who spent the first month afraid to click deploy were the ones who took the longest to become effective.
The curriculum, honestly
Twelve weeks. Not eight (too short, GETs don't consolidate). Not sixteen (too long, they get bored and their motivation drops).
- Weeks 1–2: AWS console familiarisation, IAM basics, first EC2 launch, first S3 bucket. Everything hands-on. No lectures.
- Weeks 3–4: Networking — VPC, subnets, routing, security groups, NACLs. This is the topic where most GETs stall. Extra time here.
- Weeks 5–6: Compute — EC2 deeply, then ECS, then Lambda. In that order because it maps to increasing abstraction.
- Weeks 7–8: Storage — S3 lifecycle, EBS types, RDS.
- Weeks 9–10: Terraform. This is where the "engineer" part starts to eclipse the "ops" part. Every hands-on exercise is now IaC.
- Weeks 11–12: A capstone project. A small but real production scenario, done end-to-end, defended in a review.
The Cloud Practitioner cert happens at the end, not the beginning. If the program worked, they walk in and pass without additional study.
The hard part
The hard part is not the technical curriculum. It's giving a first-year engineer the confidence to make decisions in an environment full of experienced people. The engineers who succeeded were not the ones with the strongest CS backgrounds — they were the ones who had already learned to ask questions in front of a room.
The intervention that helped most: pairing new GETs with GETs from the previous cohort for the first two weeks. A person who was a beginner four months ago is a much less intimidating question-target than a Deputy General Manager. And it gave the previous cohort ownership over the program's success.
What I'd change if I ran it again
- Start Terraform earlier. Week 4, not week 9. IaC as the primary mode from the start would have short-circuited a lot of "I clicked something in the console and now it doesn't work" issues.
- More explicit teaching of blast-radius reasoning. Not "how do I do X?" but "what happens if X fails?" This is the mental model that separates cloud engineers from cloud users.
- Cross-team rotations. Every GET stayed on one project team. Rotating them across two would have broadened exposure and helped the ones who didn't click with their first team.
Where they went
Most stayed at HCLTech as L2 cloud engineers, moving into project delivery within 6 months of finishing the program. A minority moved to L3 within 18 months, usually driven by their own initiative on top of the program's foundation. A few left for other companies at higher levels, which is a good outcome for the individual and a legitimate one for the program.
Bottom line
Cloud training that works is expensive to run. It requires senior time, sandbox budget, real tickets, and patience through the phase where a GET is more work than they're worth. The return is measured in years — a well-trained L2 in year one is an autonomous L3 by year three and a mentor to the next cohort by year four.
That compounding is the actual return on the investment. The certifications are the visible sign that it worked, not the mechanism by which it works.