Eleven years ago, I was staring at the AWS console for the first time, completely overwhelmed. There were dozens of services I’d never heard of, acronyms that meant nothing to me, and a nagging voice in my head saying I wasn’t smart enough to figure this out.
Today, I work with cloud infrastructure daily. I’ve built serverless applications, designed architectures for production workloads, and helped others navigate the same confusion I once felt.
Looking back, I realize the technical skills were the easy part. The harder lessons were about mindset, consistency, and understanding how careers actually work. The things nobody tells you when you’re starting out.
If I could sit down with my past self on Day 1, here’s what I’d say.
1. Stop Waiting to Feel Ready
You will never feel ready.
I spent months telling myself I needed to finish one more course before I could start building. I needed to understand networking better before I touched AWS. I needed to be more comfortable with Linux before I could deploy anything.
This is a trap. Readiness is a feeling that comes after you start, not before.
The first time I tried to deploy a simple web application to EC2, I had no idea what I was doing. I didn’t understand security groups. I couldn’t figure out why my instance wasn’t reachable. I spent an entire weekend troubleshooting something that should have taken an hour.
But here’s what happened: by Monday, I understood security groups. Not because I read about them, but because I had broken something and needed to fix it.
Your first project will confuse you. Your second will frustrate you. Your third will still have problems. But by your fifth project, something shifts. You start recognizing patterns. Error messages that once looked like gibberish begin making sense. You develop instincts.
That confidence you’re waiting for? It’s on the other side of starting.
The course you’re watching right now is valuable. But it becomes ten times more valuable when you pause it, open your AWS console, and try to build what you just learned. Understanding and doing are completely different skills. You need both, and you can only get the second one by starting before you’re ready.
2. Projects Matter More Than Everything Else
Let me be direct: not one certification, not one course, not one bootcamp did more for my career than building real projects.
I’m not saying certifications are worthless. They have their place. They give you structured learning paths, validate your knowledge to employers who use them as filters, and force you to learn topics you might otherwise skip.
But here’s what certifications can’t do: they can’t teach you what happens when things break in unexpected ways. They can’t give you the experience of debugging a problem for three hours only to discover it was a typo in an environment variable. They can’t simulate the feeling of deploying something to production and watching real users interact with it.
Projects give you stories to tell in interviews. When someone asks about a challenging problem you solved, you need a real answer. “I studied this topic in a course” doesn’t compare to “I built an application that processed user uploads, and when it started failing at scale, I had to redesign the architecture to handle the load.”
Here’s my framework for learning through projects:
Build something. It doesn’t need to be original or impressive. Clone an existing idea. Build a to-do app, a URL shortener, a simple API. The goal isn’t to create something the world has never seen, it’s to learn by doing.
Break it. Intentionally push your project to its limits. What happens when you send a thousand requests at once? What happens when the database goes down? What happens when you feed it unexpected input? Breaking things teaches you how they work.
Fix it. This is where the real learning happens. Debugging forces you to understand systems at a deeper level than building ever does. Every error you resolve adds to your mental library of solutions.
Repeat. Each project should be slightly more ambitious than the last. Add a new service you haven’t used. Implement a pattern you read about. Increase the complexity gradually.
Document everything as you go. Take screenshots. Write notes about what you tried and what worked. This documentation becomes portfolio material, blog content, and interview preparation all at once.
3. Your Future Network Matters More Than Your Current Skills
When I started in tech, I thought success was purely about technical ability. Learn enough skills, pass enough certifications, and opportunities would appear.
I was wrong.
The opportunities that changed my career came through people. A former colleague mentioned my name when their company was hiring. Someone I’d interacted with on LinkedIn sent me a message about a role they thought I’d be perfect for. A connection I’d helped with a technical question months earlier returned the favor with an introduction.
Your network isn’t just about who you know, it’s about who knows what you’re capable of.
This doesn’t mean you need to become a networking expert or attend every meetup in your city. It means being visible and helpful in small, consistent ways.
Comment on posts. When someone shares something interesting, add a thoughtful comment. Not “Great post!” but something that shows you actually read and thought about it. Ask a follow-up question. Share a related experience. This puts you on people’s radar.
Post your progress. You don’t need to be an expert to share what you’re learning. “Today I finally understood how IAM policies work” is valuable content. Someone else is struggling with the same thing and will appreciate your explanation. Someone more experienced might offer additional insights. Both outcomes benefit you.
Ask questions publicly. Many people are afraid to ask questions because they don’t want to look uninformed. But asking good questions demonstrates curiosity and engagement. It also invites helpful people into your orbit.
Help others. Answer questions when you can. Share resources you’ve found useful. Celebrate other people’s wins. Generosity in professional communities compounds over time in ways that are hard to predict but impossible to ignore.
The cloud community is remarkably welcoming to beginners. People remember what it was like to start out and genuinely want to help. But they can only help you if they know you exist.
4. LinkedIn Isn’t Optional
I resisted LinkedIn for years. It felt performative. Self-promotional. Uncomfortable.
Then I realized something: LinkedIn isn’t social media in the traditional sense. It’s infrastructure for your career.
Think about what LinkedIn actually is. It’s your resume, but dynamic and always accessible. It’s your portfolio, where you can showcase projects and share your work. It’s your reputation, built through your posts, comments, and endorsements. It’s your discoverability, where recruiters and hiring managers search for candidates.
When a recruiter searches for “Cloud Engineer,” they’re not searching your personal website. They’re searching LinkedIn. When a hiring manager wants to learn more about you before an interview, they’re checking LinkedIn. When someone you met at a conference wants to stay in touch, they’re connecting on LinkedIn.
You don’t need to become a LinkedIn influencer. You don’t need to post every day or chase viral content. But you do need to:
Complete your profile. A professional photo, a headline that describes what you do, and a summary that tells your story. List your projects, certifications, and relevant experience. Make it easy for people to understand who you are and what you’re looking for.
Show your work. When you complete a project, write about it. When you pass a certification, share what you learned. When you solve an interesting problem, explain your approach. These posts serve as evidence of your capabilities.
Engage consistently. Even ten minutes a day makes a difference. Comment on a few posts. Congratulate people on their achievements. Share an article you found valuable. Consistency matters more than volume.
People can’t help you if they can’t see you. LinkedIn makes you visible.
5. Momentum Beats Perfection
You’re going to overthink your first GitHub repository. You’ll worry the code isn’t clean enough, the documentation isn’t thorough enough, the project isn’t impressive enough.
You’re going to overthink your first LinkedIn post. You’ll rewrite it five times, wonder if anyone will care, and debate whether you should even hit publish.
You’re going to overthink your first job application. You’ll convince yourself you’re not qualified, that you’ll embarrass yourself in the interview, that you should wait until you’re more prepared.
Here’s what I wish someone had told me: done is better than perfect, and published is better than polished.
The first version of anything is supposed to be rough. That’s not a flaw, it’s the process. You can’t edit something that doesn’t exist. You can’t improve a project you never built. You can’t get feedback on a post you never published.
Every expert you admire has a graveyard of mediocre first attempts. The difference between them and people who never made it isn’t talent, it’s that they kept going.
Momentum has a compounding effect. Your first repository teaches you how Git works. Your second teaches you about documentation. Your third teaches you about code organization. Each iteration improves because you’re learning by doing, not waiting to learn everything before you start.
The same applies to content. Your first LinkedIn post might get three likes. Your tenth will be better because you’ve learned what resonates with your audience. Your fiftieth will feel natural because you’ve developed your voice through practice.
Perfection is a form of procrastination. It feels productive because you’re “working on” something, but nothing is actually shipping. Momentum gets you results.
Still hit publish. Still apply. Still show up.
6. Interviews Aren’t Exams - They’re Conversations
I failed my first cloud interview badly. I treated it like a certification exam, trying to recall memorized facts about AWS services. When the interviewer asked about my experience with a service I’d never used, I froze. I didn’t know the “right answer.”
Here’s what I didn’t understand: interviews aren’t about having all the answers. They’re about demonstrating how you think.
Hiring managers know you won’t have experience with every service. They know you’ll encounter problems you’ve never seen before. What they want to know is how you’ll handle those situations.
When you don’t know something, the worst response is pretending you do. The best response is showing your thought process: “I haven’t used that service directly, but based on what I know about similar services, I’d approach it by...”
Interviewers are evaluating several things at once:
How you think. Can you break down complex problems? Do you ask clarifying questions? Can you reason through unfamiliar territory?
How you communicate. Can you explain technical concepts clearly? Do you listen to questions carefully? Can you admit when you don’t know something?
How you solve problems. What’s your approach when you’re stuck? How do you prioritize when there are multiple possible solutions? How do you validate that your solution actually works?
How you’d be to work with. Are you collaborative? Do you seem coachable? Would the team enjoy having you in meetings and Slack channels?
Prepare for interviews by practicing how you talk about your experience, not just what you know. Use the STAR method (Situation, Task, Action, Result) to structure stories about projects you’ve worked on. Practice explaining technical decisions you’ve made and why you made them.
The interview is a conversation about whether you and the company are a good fit for each other. You’re evaluating them just as much as they’re evaluating you. That mindset shift alone will make you more relaxed and more authentic.
7. The Cloud Isn’t Hard - It’s Unfamiliar
When I first opened the AWS console, I was genuinely intimidated. There were over two hundred services. The documentation was dense. Every tutorial seemed to assume knowledge I didn’t have.
I thought the problem was that cloud computing was inherently difficult and maybe I wasn’t cut out for it.
I was wrong. The problem wasn’t difficulty, it was unfamiliarity.
There’s an enormous difference between hard and unfamiliar. Hard means something is objectively complex, requiring exceptional intelligence or talent to understand. Unfamiliar just means you haven’t been exposed to it yet.
Most of cloud computing is unfamiliar, not hard.
When you first learn about VPCs, subnets, and routing tables, it feels overwhelming. Six months later, you set them up without thinking. The concepts didn’t get easier, you got familiar with them.
When you first deploy a Lambda function, you don’t understand cold starts, execution environments, or IAM roles. After you’ve deployed fifty functions, these concepts are second nature.
This reframe matters because it changes your emotional response to confusion. If you believe cloud is hard and you’re confused, you might conclude you’re not smart enough. If you believe cloud is unfamiliar and you’re confused, you know you just need more exposure.
Give yourself thirty days of consistent learning and building. Not passive learning where you watch videos and nod along, but active learning where you’re hands-on in the console, making mistakes, and fixing them.
What feels impossible today becomes your new normal tomorrow. Every expert you admire went through the same process of confusion becoming clarity. The only difference is they stuck with it long enough.
8. The Fastest Way to Stand Out Is Going Deep
When you’re starting out, it’s tempting to learn a little bit of everything. You want to be well-rounded. You want to have an answer for any question that might come up in an interview.
This is a mistake.
The market doesn’t reward generalists who are mediocre at everything. It rewards specialists who are exceptional at something.
Think about it from a hiring manager’s perspective. They have a specific problem to solve. Maybe they need someone to build serverless applications. Maybe they need someone to secure their AWS environment. Maybe they need someone to build CI/CD pipelines.
When they’re hiring, they want someone who has gone deep in that specific area. Someone who has encountered the edge cases, understands the tradeoffs, and can hit the ground running.
“I have experience with Lambda, EC2, S3, RDS, DynamoDB, CloudFront, Route 53, IAM, VPC, ECS, EKS, and Step Functions” sounds impressive but says nothing about your actual expertise.
“I specialize in serverless architectures. I’ve built event-driven systems with Lambda, designed APIs with API Gateway, and optimized costs for high-throughput workloads” tells a story. It positions you as the go-to person for a specific type of problem.
Pick a lane:
Serverless if you’re drawn to event-driven architectures and want to minimize operational overhead.
Security if you’re detail-oriented and interested in protecting systems from threats.
DevOps/Platform Engineering if you enjoy building tools and processes that help other developers move faster.
Data Engineering if you’re interested in building pipelines that move and transform large amounts of data.
Networking if you want to understand the foundational infrastructure that everything else runs on.
You can always expand later. But early in your career, depth beats breadth. Master one lane first, then broaden from a position of strength.
9. You Don’t Need to Be the Smartest - Just the One Who Doesn’t Quit
I’ve watched people who were more naturally talented than me quit because they got frustrated. I’ve watched people who started after me give up because they weren’t seeing results fast enough.
The people who succeed in cloud aren’t necessarily the smartest or most talented. They’re the ones who keep showing up.
This career path has a high dropout rate because the early stages are uncomfortable. You feel confused constantly. Progress seems slow. Imposter syndrome tells you everyone else is figuring this out faster than you are.
What you don’t see is that everyone else feels the same way. The difference between those who make it and those who don’t isn’t intelligence, it’s persistence.
Some practical strategies for not quitting:
Set small, achievable goals. “Become a cloud engineer” is overwhelming. “Complete one hands-on tutorial this week” is manageable. Stack enough small wins and you’ll look up to find you’ve made massive progress.
Track your progress visibly. Keep a learning journal. Save screenshots of things you’ve built. Document problems you’ve solved. When you’re feeling discouraged, look back at where you started. You’ve come further than you think.
Find a community. Learning alone is hard. Find a Discord server, a study group, or even one other person who’s on the same journey. Accountability and encouragement make a huge difference.
Expect plateaus. Progress isn’t linear. You’ll have weeks where everything clicks and weeks where nothing makes sense. The plateaus are normal. Keep going through them.
Remember your why. On the hard days, reconnect with the reason you started. Financial security for your family. A more fulfilling career. The ability to build things that matter. Whatever it is, keep it visible.
The cloud industry is full of people who aren’t geniuses. They’re just people who refused to quit.
10. Your Life Can Look Completely Different in 6-12 Months
This isn’t motivational fluff. I’ve seen it happen repeatedly.
I’ve seen people go from help desk to cloud engineer in eight months. I’ve seen people with no technical background land their first AWS role in a year. I’ve seen people double their salaries by gaining cloud skills and changing companies.
Six to twelve months is not a long time. But it’s enough time to completely transform your career if you’re consistent.
Think about where you were a year ago. Think about what you’ve learned since then, even without focused effort. Now imagine what would happen if you spent the next year intentionally building cloud skills, creating projects, growing your network, and positioning yourself for opportunities.
The compound effect of daily effort is staggering. One hour a day for a year is 365 hours, more than many college courses. Fifteen minutes a day engaging on LinkedIn builds a network of hundreds of relevant connections. One project a month gives you a portfolio of twelve things you’ve built.
Most people overestimate what they can do in a week and underestimate what they can do in a year.
Your future self will thank you or blame you for the decisions you make today. A year from now, you’ll have either made progress or made excuses. The time will pass regardless.
It starts with one decision: committing to this.
Not “I’ll try to learn cloud when I have time.” Not “I’ll start seriously studying after this busy period.” Not “I’ll build projects once I feel more confident.”
A real commitment. A non-negotiable decision that you’re going to do this, that you’re going to keep showing up even when it’s hard, and that you’re going to trust the process even when progress feels slow.
Make that decision today.
The Journey Ahead
Starting in cloud is challenging. You’ll face confusion, frustration, and self-doubt. There will be days when you question whether you’re on the right path.
But you’re also starting at the best possible time. Cloud adoption is accelerating. The demand for cloud skills continues to grow. Companies are struggling to find qualified people. The opportunity is real and it’s not going away.
The only question is whether you’ll position yourself to capture it.
Everything I’ve shared in this article comes down to a few core principles: start before you’re ready, learn by building, make yourself visible, choose depth over breadth, and don’t quit.
None of this requires exceptional talent. It requires consistency, patience, and the willingness to be uncomfortable while you’re learning.
You have everything you need to start. The resources are available. The community is welcoming. The opportunity is waiting.
Now it’s on you.
I started learning about the cloud last year, I actually started with Huawei( they have an academy at my university) but this year I started reading about AWS.your writeup have given me answers to some questions I've had in mind.