Discover more from Big Tech Careers

Land a job at MAANG+ with proven strategies and expert guidance!

Over 17,000 subscribers

Already have an account? Sign in

How I Transitioned from a Developer to a Solutions Architect Role

My journey to a Solutions Architect role at AWS and the skills needed to excel in an SA role

Prasad Rao

Feb 20, 2025

Hey, Prasad here 👋 I'm the voice behind the weekly newsletter "Big Tech Careers."

In this week's article, I share my journey of how I started my career as a .NET developer, the different roles I played over the years, and how they helped me transition into a Solutions Architect role.

I originally published a version of this article as a guest post in Gregor Ojstersek's Engineering Leadership newsletter. If you are looking to grow in your engineering career, check out his newsletter and follow him on LinkedIn. Image credits: Gregor Ojstersek.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

One question that was asked in the first session of the current BeSA (Become a Solutions Architect) Cohort was:

"I'm a developer. Is it possible for me to transition to a Solutions Architect (SA) role?"

The answer is yes, but to fully address the question, I’ll share my story. I started my career as a developer and transitioned to an SA role. While there are certain skills that you need to pick up to become an SA, I will share how I gained those skills as I progressed in my career. Let’s start from the beginning!

Early years as Developer/Engineer

My career began as a .NET Developer, where I gradually progressed to become a Senior Developer and then a Tech Lead. The year I graduated, I interviewed for a couple of Big Tech companies but never got beyond the initial coding rounds. I thought I wasn't made for Big Tech and made peace with it.

After a few initial job switches, I settled into a consulting company and started climbing the ladder. Unlike many others who choose the management track, I wanted to grow as an Individual Contributor (IC). However, many companies do not have a clearly defined IC growth path. The natural progression is to become a manager. I was looking for alternative opportunities.

Even though I was working for a consulting company, I was in a unique position as I was working on building a product for a financial services company. When the product was ready, they needed someone in the field to demo it to potential clients. I took the role, and that opened a whole new world of possibilities for me.

That's when I was first introduced to pre-sales activities. Instead of being an engineer on the product team, I would be part of the field team as a pre-sales engineer.

Pro Tip: Don’t shy away from exploring lateral roles when an opportunity arises. Career growth is never linear.

Growing as a Pre-sales Engineer

Frankly, before I started, I didn't know if such a role existed. As with any new role, there were pros and cons of being a pre-sales engineer. The pros were that I would be working more closely with customers onsite and traveling the world. The cons were that I would work on activities sometimes frowned upon by engineers - stakeholder management, customer interactions, gathering requirements, creating sales presentations, etc.

Frankly, it was stepping out of my comfort zone, but it helped me develop skills that I never knew would be so important in my career growth.

After a couple of years in this role working with multiple customers, I understood the importance of understanding customers' requirements and working backward to achieve them.

Being an engineer, I had mostly focused on completing the tasks assigned to me. I never focused on understanding the real business reasons behind the tasks. Other skills I learned in this role:

Speaking both business and technical languages
Creating stellar technical presentations and product demonstrations
Understanding prospective clients' business needs and designing customized solutions
Collaborating with multiple stakeholders like sales representatives, client executives, business analysts, and product teams

Pro Tip: Spend time with your business stakeholders to understand the WHY behind the tasks you do on a daily basis.

Growing as an Architect

After a few years in the role of Pre-sales engineer, I got an opportunity to consult as a Senior Engineer/Tech Lead for a financial services customer on a digital transformation project. With improved business acumen and communication skills, I quickly became the go-to person for the customer. It was a development project, but my focus shifted to understanding the bigger picture.

As developers, we design and architect components, so we're already doing architecture work without realizing it. A key to transitioning to an architect role is viewing these individual components and systems through a wider lens.

To grow as an architect, you need to learn system design, distributed systems, and integration patterns. You also need to develop the mindset of considering scalability, performance, security, cost, and other factors. But those are technical skills that are relatively easy to pick up. The important thing to develop as an architect is perspective - while developers often focus deeply on specific components, architects maintain a holistic view of the entire system. For that, understanding the business requirements is essential.

A pivotal insight that helped my transition was understanding that architects are essentially developers who view systems through a wider lens. The main difference is scale and perspective - while developers often focus deeply on specific components, architects need to maintain a holistic view of the entire system.

As Gregor Hohpe explains in his talk "Thinking Like an Architect" architects see more dimensions than other people do. Some people see it as a circle and others see it as a rectangle, and all of them are right in their own perspective. Architects, having a holistic view, should be able to see it as a three-dimensional cylindrical figure.

In architecture, there is nothing defined as right or wrong - it's always a trade-off. There is a reason architects start their answers with "It depends." It depends on the requirements. It depends on what you would like to achieve. It depends on what constraints you're working with.

Every architectural decision involves balancing multiple factors: scalability versus simplicity, performance versus maintainability, time-to-market versus perfect technical design, or cost versus capability.

Lastly, to grow as an architect, it is also important to develop a broad understanding of multiple technologies. This enables you to make informed decisions about choosing the right tools for specific problems.

Pro Tip: Shift your focus to look at the big picture and have a holistic view. Architects learn to navigate the ambiguity in requirements and constraints.

Cracking the Solutions Architect role at AWS

With 10+ years in the industry, I had gained enough experience in different roles - developer, tech lead, pre-sales engineer, and architect. I was looking for a new job when one of my seniors suggested I try for AWS.

I was reluctant, thinking that I would have to go through coding exercises. I was pretty hands-on, but solving LeetCode was not my cup of tea. To my surprise, I learned that coding rounds happen only for SDE roles. So if you are a naive person like me thinking that jobs at Big Tech are out of reach because of coding rounds, then please explore other roles.

I browsed through multiple roles to find one that matched my profile - 'Solutions Architect, Microsoft Developer Tools on AWS'. The job role mentioned experience required with .NET and Microsoft workload stack. In the role, I had to help customers migrate and modernize their Microsoft workloads on AWS.

My decade-long career was all in Microsoft technologies, but I had zero experience with AWS. I was pretty candid about that in my call with the recruiter, and still my profile got shortlisted. The entire interview process (8 rounds) was completely based on my experience and my learning ability with new technologies. No coding round whatsoever.

I'm not saying the interviews were easy or that I did not have to prepare. It took a lot of hard work to prepare for the interviews, but the diverse experience I had gained helped me position myself as a good fit for a Solutions Architect role, which requires both technical and consulting skills.

Pro Tip: Don't let coding interviews discourage you from applying at MAANG+ companies. Explore jobs other than SDE roles and you'll be surprised at how different the interview processes are.

The role of a Solutions Architect

Having spent 5 years in the Solutions Architect (SA) role at AWS and being promoted to Principal SA has given me enough insights into what is required to become a successful SA. Ask any experienced SA about what their day-to-day role looks like, and they would answer, "Every day is different." And that's true.

Let me give you a glimpse of the different hats an SA wears in their role. It will not only help you understand what a typical day of an SA looks like but also the skills you should be developing if you aspire to become an SA.

Solutions Architects function as architectural experts by creating reference architectures, designing new architectural patterns, and developing methodologies that establish standardized approaches for solving complex technical challenges.
Solutions Architects serve as technical advisors by analyzing complex business requirements and recommending the most effective technological solutions to meet organizational goals and overcome technical challenges.
Solutions Architects serve as technical demonstrators by building proof of concepts and prototypes that validate proposed solutions, showcase technology capabilities, and provide tangible evidence of how specific technologies can effectively address customer challenges and business requirements.
Solutions Architects act as customer advocates by deeply understanding client needs, representing their interests throughout the implementation process, and providing the required feedback to the product teams for enhancing the products and features.
Solutions Architects function as technical trainers by sharing technical knowledge with teams, conducting training sessions, and helping stakeholders understand the implications and benefits of different architectural decisions.
Solutions Architects act as technology evangelists by promoting innovative solutions, speaking at conferences, sharing success stories and best practices, and inspiring the organization to embrace new technologies and architectural approaches that drive business value.
Solutions Architects serve as strategic planners by developing comprehensive technical roadmaps, evaluating emerging technologies, and ensuring solutions are scalable and future-proof to support long-term business growth.
Solutions Architects work as cross-functional collaborators by bridging the gap between business and technical teams, customers and product teams, facilitating communication between stakeholders and aligning diverse groups.

So, one day I might spend a full day in whiteboarding sessions with customers, understanding their requirements and coming up with solutions using different AWS services.

Another day might find me glued to my computer, creating a proof of concept to showcase the capabilities of AWS services. Then there might be days when I speak at conferences, evangelizing AWS services. Or I might spend a full day conducting workshops and training sessions to upskill customers on AWS.

Pro Tip: As every customer is different and every customer problem is unique, so is each day of a Solutions Architect. And that's what I like about the SA role.

Become a Solution Architect (BeSA Program)

I, along with few other Amazonians, run a FREE mentoring initiative called BeSA (Become a Solutions Architect). The 8-week program focuses on technical and behavioural skills to help you excel in your cloud career.

The cohort started on Feb 15, 2025, and while the first session has already taken place, you can still register! You’ll get access to the previous session recording and all upcoming live sessions.

Sessions are hosted live on BeSA YouTube channel every Saturday at 3 PM GMT.

Topics covered: