[HN Gopher] I spent 5 years in DevOps - Solutions engineering ga...
       ___________________________________________________________________
        
       I spent 5 years in DevOps - Solutions engineering gave me what I
       was missing
        
       Author : vmatsiiako
       Score  : 177 points
       Date   : 2026-02-06 16:45 UTC (1 days ago)
        
 (HTM) web link (infisical.com)
 (TXT) w3m dump (infisical.com)
        
       | ikjasdlk2234 wrote:
       | My path went from engineering-aligned (math) to engineering
       | management back to engineering to product to program management
       | to solutions engineering to account executive.
       | 
       | Honestly I had a negative connotation about sales for most of my
       | career, but turns out I really love it. The exposure to different
       | problems every day is awesome and more like a puzzle than work to
       | me. I feel a bit of reverse imposter syndrome though, like I
       | should feel bad that I didn't "make it" as a real engineer. So
       | that's a weird feeling.
       | 
       | One thing I try to do in my company is pull engineers into sales
       | calls and proofs-of-concepts if I can. I think that exposure to
       | both real users and unique environments is important for their
       | growth and novelty in the job.
        
         | esafak wrote:
         | Can you share one such puzzle?
        
           | marcyb5st wrote:
           | I am a solution engineer mostly on the traditional ML side of
           | things but have good knowledge of K8S/GKE. The most fun I had
           | last year was helping a customer serve their models at scale.
           | They thought it was cost prohibitive (500k inferences/second
           | and a hard requirement of 7ms at p99) and so they were
           | basically serving from a cache which was lossy (the
           | combinatorial explosion of features made it so that to have
           | full coverage you needed exabytes of ram) and was stale
           | prone. We focused on the serving first. After their data
           | scientists trained a New pytorch model (small one, 50k
           | parameters more or less) we compiled to onnx (as the model is
           | small and CPU inference is actually faster), grafted the
           | preprocessing layers to the model so that you never leave the
           | ONNX C++ runtime (to avoid python), and deployed it to GKE. A
           | 8 core node using AMD genoa cpus managed to get
           | 25k/inferences per second. After a bit of fiddling with Numa
           | affinity, GKE DNS replication, Triton LRU caches and few
           | other things we managed to hit 30k inferences per second. If
           | you scale up to the traffic it would cost them few thousands
           | per month, which is less than their original cache approach.
           | 
           | Now they are working on continuous learning so that they can
           | roll out new model (it is a very adversarial line of business
           | and the models get stale in O(hours)). For that part I only
           | helped them design the thing, no hands on. It was a super fun
           | engagement TBH
        
             | Apofis wrote:
             | Are they paying you as well as your comment makes it sound?
             | That was a ton of lingo and I'm used to lingo!
        
               | marcyb5st wrote:
               | Yeah :) happy on the money front. I didn't mention this
               | earlier, but I'm a Googler and my role is to make sure
               | that big customers are as happy as possible on GCP. And
               | Google still pays well (talking with my SWE friends my
               | total comp lands around the middle of the pack, perhaps a
               | bit fewer stock grants). I was a SWE (also at Google)
               | before, so maybe they didn't change my comp too much in
               | the new job family. I don't know as those things are
               | mysterious.
               | 
               | Also, not all projects are this fun. Sometimes is solving
               | the same problem over and over or working with customers
               | that aren't tech savvy and there is a bunch of
               | politicking and "fluffy" stuff.
        
         | falloutx wrote:
         | Sales is amazing but if your companies sales people require
         | engineering to build POCs a lot of the times or always have to
         | sell some custom solutions, then it wastes a lot of resources
         | and it usually indicates the company is losing product market
         | fit.
        
           | ikjasdlk2234 wrote:
           | That is true. My current work is in bespoke environments with
           | mainly non-technical buyers who have been burned in the past.
           | Our POCs are pretty minor lifts to build credibility and have
           | worked extremely well.
           | 
           | If you're working in SaaS or commodity products and have to
           | run POCs a lot, you're totally correct.
        
             | mjevans wrote:
             | Your company is selling the 'valet service' more than the
             | products.
             | 
             | There are people willing to pay for convenience AND
             | security at the same time (hire someone else to manage the
             | problem, and they're the 'key').
        
           | virgilp wrote:
           | I'm wondering about that. I think with the advent of AI, we
           | might see a new kind of successful software company - one
           | that doesn't sell a single solution to many customers, but
           | instead has the building blocks, prompts (agents skills etc)
           | & processes to quickly build very custom solutions for each
           | customer - using a new blend of engineers that are not
           | exactly "customer support" nor traditional "sw eng", but more
           | around the emerging "forward-deployed engineer" role.
        
           | jungturk wrote:
           | Sometimes, but if your product is a platform (or anything
           | beyond a niche solution in a broader problem domain) then
           | you're going to spend some time showing people how to make it
           | work best for them.
        
         | grvdrm wrote:
         | I love hearing this.
         | 
         | My story: mostly business analytics (2005-2022), sales
         | engineering, sales (both at same tech start up), and now
         | running a solo consulting business.
         | 
         | I also really liked sales. Updating a CRM, not so much. But
         | sales allowed me to spend my day talking with people about
         | problems. No day the same, and lots of focus on finding
         | different/better ways to communicate.
         | 
         | In what industries did these roles happen? Same industry/domain
         | or have you changed that as well?
        
           | ikjasdlk2234 wrote:
           | Domain is all government, but the tech is different across
           | each of them.
           | 
           | I love talking too, part of why I think pre-sales is a lot of
           | fun. And I actually love my CRM work from a data perspective,
           | but my background is in synthesizing data and optimization.
           | Once I turned my sales process into a network optimizing
           | problem, it became extremely interesting to me and imperative
           | to keep the data current.
        
             | grvdrm wrote:
             | Fair point. I too like the data side of CRM. So many
             | interesting possibilities.
             | 
             | Did you always enjoy talking or did you discover it at some
             | point prior to your current sales role?
        
         | robertcarter wrote:
         | Would you be willing to tell me more about your path to account
         | executive and sales? I am considering such a path myself and it
         | would be wonderful to talk with someone whose done this.
        
           | nunez wrote:
           | I hope you like being on call and having to tell management
           | why you're not hitting your number and "forecasting" your way
           | to close the gap.
           | 
           | I also hope you like golf! And drinking!
           | 
           | There can be UNREAL amounts of drinking as an AE.
           | 
           | You'll also be on a plane A LOT. The folks in suits and
           | sneakers waiting first in line to board with their roller
           | bags? Almost all of them are AEs.
           | 
           | Most of your customers will see you as a walking credit card.
           | 
           | You can also make 6+-figure commission checks and deep
           | friendships if the deals are right, so there's that.
        
         | mancerayder wrote:
         | How do you get to sales from engineering? Must it take place
         | laterally in the same company, or did you sell yourself
         | differently to recruiters, or did you know someone?
        
       | codezero wrote:
       | I really loathe that sales engineers stole the term Solutions
       | Engineer which was previously used to basically mean
       | support/services engineer (technical generalist), a mostly post-
       | sales role. It's pedantic, but I watched it happen in real time,
       | my company's HR even asked if we could change our team titles to
       | help out the sales team since they wanted the more appealing
       | title to use.
       | 
       | The reason it annoys me so much is that it makes it harder to
       | find post-sales technical generalists as the top of the funnel
       | ends up filled with pre-sales people.
       | 
       | Congrats to OP for finding something they like though!
        
         | Melatonic wrote:
         | Use " Solutions architect " maybe instead ?
        
           | codezero wrote:
           | That title has long been used as a post sales analyst (custom
           | work for $)
        
             | raw_anon_1111 wrote:
             | At AWS at least, an SA is free for a client and ci e them
             | advice - not allowed to give a customer code.
             | 
             | ProServe consultants (full time employees) are never called
             | SAs
        
         | cootsnuck wrote:
         | In my experience, it just entirely depends on the company.
         | Different companies will use the same title and they can have
         | wildly different mixtures of pre vs post sales involvement. My
         | career has all been customer/client facing technical roles.
         | Titles range from:
         | 
         | - support engineer
         | 
         | - solutions engineer
         | 
         | - sales engineer
         | 
         | - applied engineer
         | 
         | - forward deployed engineer
         | 
         | - solutions / sales architect
         | 
         | - field engineer
         | 
         | And that's leaving out titles that avoid calling someone an
         | engineer who is still entirely technical, has to code, has to
         | deploy, etc. but deals with clients.
         | 
         | I will say though that roles that want pre-sales focused
         | engineers typically are pretty picky about people who have the
         | sales-facing experience. So it shouldn't be _too_ hard to avoid
         | those roles if you 're wanting a role focused almost entirely
         | on post-sales.
         | 
         | (I say that, but I do know that if a company lacks pre-sales
         | dedicated engs then other engs definitely can get roped into
         | it. I know a guy with a PhD in ChemEng that basically is the
         | director of research at his company and has had to wear a
         | "sales eng" hat quite a bit in his role.)
        
         | raw_anon_1111 wrote:
         | Top of the funnel should be pre-sales. Our sales folks are
         | usually juggling eight or nine opportunities, trying to get
         | contracts signed, in our case working with AWS to help get
         | funding, flying to customers sites, etc.
         | 
         | I am post sales, billable staff consultant who leads projects.
         | I'm "delivery". I focus on one project at a time and dig deep
         | into requirements and the implementation and/or strategy docs.
        
         | bigtones wrote:
         | Agreed - its total sales engineering as he described it.
        
       | axus wrote:
       | It's always nice when the customer wants to improve the
       | process/product, it can overcome internal friction that had
       | prevented making things better.
        
       | maxaw wrote:
       | Wow, I think I'd love this job. Nothing more interesting than
       | learning about lots of different unique problems from different
       | industries. And totally get the fear of losing technical edge
        
         | vmatsiiako wrote:
         | Apply here :) -
         | https://jobs.ashbyhq.com/infisical/2ef2e211-9332-4e68-bd86-e...
         | -
         | https://jobs.ashbyhq.com/infisical/73b79555-8b3f-486b-84fa-8...
        
         | mikeocool wrote:
         | Word of warning: at some companies "solutions engineer" just
         | means "demo monkey." The sales people don't really know how the
         | product works or how to use it, so you are brought in to do the
         | demo and answer questions and that's about it (and you're
         | compensated much less well than the sales people).
        
       | lateral_cloud wrote:
       | Best job in the world.
        
         | jameshush wrote:
         | 1000%. When the sale doesn't go through, it's the salesperson's
         | fault. When the product doesn't work, it's the "real"
         | engineer's fault. When everything works, the client gives you a
         | high five.
         | 
         | If you don't know the answer, you can ask one of the "real"
         | engineers.
         | 
         | As long as you show up with a smile on your face and the demo
         | kinda works during the call, you're 10/10.
         | 
         | At FAANG companies, you generally get paid at a level above
         | your technical role; for example, if you have a mid-level
         | engineer's coding ability but can also talk to customers,
         | you'll generally be paid a senior engineer's salary.
         | 
         | Some days, I don't understand why everyone doesn't want this
         | job. But then I'll talk to the product engineers on my team,
         | and they'll thank me for talking to the customers so they can
         | focus on coding. I think it's really a personality/preference
         | thing.
        
           | cootsnuck wrote:
           | Yup, it is. It's my bread and butter too. So much so I
           | decided to just do it for myself and start my own consulting
           | company.
           | 
           | Being a solutions engineer at the right companies means you
           | get to be one of the few people with full end-to-end
           | visibility of the entire lifecycle of both a client and the
           | technology adoption, deployment, optimization, maintenance,
           | etc. process. And you'll get to see it dozens or hundreds of
           | times for a variety of clients across industries. Again
           | though, totally depends on the company.
        
         | bigtones wrote:
         | Yes... and also it pays pretty damn well if your company sales
         | team is winning. Incentives are aligned.
        
       | pisipisipisi wrote:
       | My experience in a "product company" - Pre-sales solutions
       | engineer - the original problem solver. Professional services -
       | post-sales firefighter :)
        
       | korijn wrote:
       | Inspiring article. Well written. Totally feeling it!
        
       | nickjj wrote:
       | I'd still classify what they're doing as DevOps type of work. It
       | just happens to be a wider spectrum of things vs their usual
       | "write YAML" in that 1 role. Sounds like the original poster
       | found a more enjoyable role with the same title?
       | 
       | I do a ton of different things every day and have been for the
       | last ~10 years, all in the neighborhood of DevOps'ish type of
       | tasks. I've written about 120+ of those tasks at
       | https://nickjanetakis.com/blog/120-skills-i-use-in-an-sre-pl....
       | I do agree, it is fun to mix it up in your day to day (IMO).
        
         | bobanrocky wrote:
         | Nope. Devops != any sort of pre-sales/post-sales/solution
         | engineering.
         | 
         | It requires a more holistic, generalist view, and a degree of
         | customer understanding, empathy, management and conversational
         | skills well beyond typical devops.
        
         | antonvs wrote:
         | > I'd still classify what they're doing as DevOps type of work.
         | 
         | This is very, very wrong. Why do you think that?
        
           | jeron wrote:
           | devops means a lot of different things to different people
        
             | raw_anon_1111 wrote:
             | If you are a "DevOps engineer" - how is what you are doing
             | any different from operations folk 25 years ago if you
             | aren't working with developers and embedded into their
             | teams?
        
               | antonvs wrote:
               | Why are you assuming that devops engineers aren't
               | embedded in development teams?
               | 
               | The problem you're suffering from is assuming that the
               | limited range of situations you're familiar with is the
               | same as what everyone else is doing.
        
               | raw_anon_1111 wrote:
               | Rule #1 is never make assumptions about anyone on the
               | internet...
               | 
               | In the past 8 years I've led the architecture of a
               | startup - cloud + app dev. Then spent almost 4 years
               | working at AWS ProServe involved with large cloud + app
               | dev "cloud application modernization" projects and now 2
               | years doing the same as a staff level consultant at a 3rd
               | party consulting firm. I think I've seen my fair share of
               | how large private companies, startups, government
               | organizations and colleges work.
               | 
               | A lot of my projects pre AI involved bringing modern
               | DevOps practices to an organization - convincing
               | operations to use IAC and best practices and have them
               | more embedded into the dev teams.
        
               | mancerayder wrote:
               | Help me understand this 'embedded in developer teams' in
               | a larger company. Do you have no central infrastructure
               | with centralized tooling, alerting, standards and
               | knowledge?
               | 
               | Team A has a devops engineer, Teams B through F have one,
               | how do they have any capacity to pursue long term
               | strategical projects, save money and operational effort
               | with centralized hosting and tooling, and basically have
               | some autonomy, when they are enslaved to a Scrum Master
               | and some hokey pokey Fibonacci numbers and T Shirt Size
               | nonsense having to argue priorities in every Sprint
               | against people who don't care about operations?
               | 
               | That's what embedded devops is to me - an operational
               | role enslaved to dev leads, the poor guy who has to
               | troubleshoot a failed release while the devs are at the
               | bar.
               | 
               | Unless my straw man is wildly off, no thanks to that
               | embedded stuff.
        
               | raw_anon_1111 wrote:
               | That's exactly what it means , a person who reports to
               | the infrastructure team who decides standards and is
               | embedded with the devs as part of the project.
               | 
               | If you are just throwing things over the fence - you're
               | an "operations" team and get none of the benefits of
               | DevOps
        
               | mancerayder wrote:
               | Understood, but so far what I observed is the embedded
               | devops pressured/saying Yes/beholden to a PM running
               | sprints, and the central infra team management constantly
               | has to intervene to protect the embedded devops engineer
               | politically.
               | 
               | Maybe my experience is a rare example, but my conclusion
               | so far is that it's tricky to prevent this painful
               | situation, and requires vigilance.
        
               | raw_anon_1111 wrote:
               | And once you have the infra team saying no all of the
               | time and being antagonistic - you're back to old school
               | operations and you aren't a DevOps shop.
        
               | mancerayder wrote:
               | But if they never say no, how do you maintain central
               | infrastructure standards?
               | 
               | If you say yes all the time, I feel like that's how you
               | turn devops into Ops monkeys who are reactive, since
               | people are operating on Sprint timelines instead of
               | optimizing for long-term stability.
        
           | nickjj wrote:
           | > Why do you think that?
           | 
           | The OP wrote:
           | 
           | > _As an SE, I 'm exposed to everything. Customers running
           | Kubernetes, ECS, Lambda, bare metal, air-gapped environments.
           | AWS, Azure, GCP, hybrid setups. CI/CD in Jenkins, GitHub
           | Actions, GitLab, CircleCI. I have to understand their
           | environment well enough to actually help them, so the
           | learning is constant. The stagnation I felt in DevOps? Gone._
           | 
           | These are all things I deal with in my day to day as well in
           | a DevOps / Infrastructure / Platform type of role. I mean,
           | not literally everything like air-gapped environments since
           | the companies I work for don't have that but it's all things
           | in that category of line of work.
           | 
           | The only difference is I usually don't interface directly
           | with the company's customers of the services being built.
           | It's more like the company's staff are my customers because
           | I'm working with developers, management and sometimes other
           | parts of the business on ways to help optimize their
           | workflows which all funnel back to helping create a better
           | end customer experience.
        
       | NoSalt wrote:
       | I am a software developer. I went to college to learn software
       | development. Two years ago, they tried to tack DevOps on to my
       | job description. I told them "no thanks", then had to find
       | another job. I found one and am MUCH happier not having to do
       | that DevOps crap. No offense, but it a soul-draining undertaking,
       | and I like writing code ... ONLY!
        
         | jpollock wrote:
         | I have a different opinion. :) DevOps is great feedback to the
         | engineering team.
         | 
         | Too many alarms or alarms at unsocial hours? The engineering
         | team should feel that pain.
         | 
         | Too hard to push? The engineering team should feel that pain.
         | 
         | Strange hard to diagnose alarms? Yep, the engineering team
         | should feel that pain!
         | 
         | The feedback is very important to keeping the opex costs under
         | control.
         | 
         | However, I think the author and I have different opinions on
         | what DevOps is. DevOps isn't a full time role. It's what the
         | engineer does to get their software into production.
        
           | bobanrocky wrote:
           | The only folks who like devops are those that haven't touched
           | anything else, or are scared to move out of that molehill.
           | Try it once .. is my advice
        
             | jpollock wrote:
             | I think there are different definitions of DevOps.
             | 
             | I see a difference between a more definite operations team
             | (SRE) vs an engineering team having responsibility for how
             | their service works in production (DevOps).
             | 
             | DevOps is something that all teams should be doing -
             | there's no point in writing code that spends it's life
             | generating problems for customers or other teams, and
             | having the problems arrive at the owners results in them
             | being properly prioritized.
             | 
             | In smaller orgs, DevOps and SRE might be together, but it
             | should still be a rotation instead of a fulltime role, and
             | everyone should be doing it.
             | 
             | Engineers who don't do devops write code that looks like:
             | if (should_never_happen) {
             | log.error("owner=wombat@example.com it happened again");
             | }
             | 
             | Where the one who does do devops writes code that avoids
             | the error condition entirely (usually possible), or decides
             | what the code should do in that situation (not log).
        
             | esseph wrote:
             | > The only folks who like devops are those that haven't
             | touched anything else, or are scared to move out of that
             | molehill.
             | 
             | IDK I've been called everything from: SysOp, SysAdmin,
             | Network Engineer, Systems Architect, Solutions Engineer,
             | Sales Engineer, Platform Engineer, etc. Half of those at
             | different companies are just "DevOps" depending on the org.
        
             | rirze wrote:
             | It truly depends on the type of DevOps experience. I've
             | avoided firefighting DevOps roles my career and I enjoy it.
             | Having the space to step back and design intelligent
             | dependent systems is satisfying.
        
           | antonvs wrote:
           | This sounds very adversarial to me. I'm glad our devops team
           | doesn't think like you.
        
             | jpollock wrote:
             | In my career, DevOps was never a separate organization. It
             | was a role assumed by the code owners. SRE (is it up, is
             | the hardware working, is the network working?) was
             | separate, and had different metrics.
             | 
             | Having separate teams makes it adversarial because both
             | orgs end up reporting into separate hierarchies with
             | independent goals.
             | 
             | Think about the metrics each team is measured on. Who
             | resolves conflicts between them? How high up the org chart
             | is it necessary to go to resolve the conflict? Can one team
             | make different tradeoffs on code quality vs speed from
             | another, or is it company-wide?
        
             | raw_anon_1111 wrote:
             | If you have a "DevOps team" - they are operations and you
             | aren't getting any of the benefits of a DevOps mindset
        
               | antonvs wrote:
               | Meh, real life is a bit more complicated than a
               | manifesto.
        
               | raw_anon_1111 wrote:
               | It's not about just a manifesto, at the startup I worked
               | for before getting into consulting 6 years ago - cloud +
               | app dev - it was much more affective for the team who did
               | the work, to create their own IAC based on a standard.
               | 
               | What's the difference between a "DevOps team" in 2026
               | than "operations" in 2001?
        
               | antonvs wrote:
               | The difference is what they do. Assisting other teams
               | with creating fully automated build and test pipelines.
               | Managing infrastructure using automated systems.
               | Identifying issues in production systems that other teams
               | should look at, down to a level of granularity that
               | wasn't really possible in 2001.
               | 
               | > affective
               | 
               | You mean "effective".
        
               | raw_anon_1111 wrote:
               | It very much was possible in 2001. In 2001 we automated
               | updating and automating our 15 or so Windows job runners
               | with Perl and the Win32:: module.
               | 
               | No large enterprise by 2001 was walking up to individual
               | PCs and updating computers by walking around and sticking
               | CDs/DVDs in each computer and they were definitely making
               | sure our on prem SQL Server and later MySQL database
               | wasn't having issues using dashboards and alerts.
        
         | Joel_Mckay wrote:
         | DevOps is secretly spiral development.
         | 
         | Great if billing by the hour, and mostly unsustainable for
         | products =3
        
         | booleandilemma wrote:
         | Same thing happened to me at a company several years ago. It
         | felt like they wanted me in two roles but were only paying me
         | for one. Didn't take long for me to jump ship after that.
        
         | raw_anon_1111 wrote:
         | I am first and foremost still a software developer as far as my
         | hands on keyboard job. I absolutely love being able to set up
         | my own infrastructure without depending on glorified system
         | administrators who call themselves "DevOps Engineers". It's all
         | just code at the end of the day - setting up infrastructure
         | involves writing yaml, HCL or actual code (CDk).
        
         | dilyevsky wrote:
         | > I like writing code ... ONLY!
         | 
         | Boy do I have some bad news for you...
        
       | alsetmusic wrote:
       | The part about interacting with people really resonates with me.
       | I went from a support and repair position to a SWE role. It
       | should have been great. But I burned out really quickly because
       | the contributions I was making were going off into a void (from
       | my perspective). I didn't see our customers engaging with what we
       | built so I had almost zero job satisfaction.
       | 
       | I moved into another support role sort of by accident when I
       | really wanted a sysadmin job but didn't have the years of
       | experience needed to get through the door. I found out (again, by
       | accident) that engaging with our customers directly gave me the
       | feedback and sense of accomplishment that I was missing. I now
       | know that it's an essential component for me. I'm much happier
       | having figured that out.
        
         | meken wrote:
         | Can relate a lot. I started off as a SWE but am pursuing a
         | support role for similar reasons.
        
       | meken wrote:
       | > But for me, it was missing something I didn't know how to name
       | until I found it: the chance to be technical and connected.
       | 
       | I genuinely throught this was impossible for a very long time. In
       | my SWE roles I've mostly felt disconnected and isolated.
       | 
       | I resigned from my last dev job and started working in donut and
       | coffee shops. I loved it.
       | 
       | I'm pursuing Support Engineer roles now hoping it will provide
       | the human focus that was missing prior.
        
       | zingar wrote:
       | > answer the same support questions. Repeat.
       | 
       | This is not devops, this is someone managing yaml to allow an org
       | to avoid doing devops.
       | 
       | Devops is practiced by everyone. If there are people asking the
       | same questions over and over there is a feedback loop / education
       | / automation problem and THAT is the part that makes a job
       | devops.
        
       | raw_anon_1111 wrote:
       | > _Part of it was repetition. My days had become predictable:
       | check the dashboards, respond to tickets, debug whatever broke
       | overnight, push some Terraform, go home. Maintain the HashiCorp
       | Vault clusters, manage the secrets pipelines, answer the same
       | support questions. Repeat. The work that used to feel engaging
       | had become routine._
       | 
       | This isn't "DevOps". This is "IT Support".
       | 
       | But honestly, if you aren't embedded into a team where developers
       | and infrastructure folks are working together - you aren't doing
       | anything differently than old school operations people did 25
       | years ago
        
         | k__ wrote:
         | Yeah.
         | 
         | In most companies, IT people just started coding and called it
         | DevOps.
         | 
         | Still better than IT folks who refuse to code.
        
           | raw_anon_1111 wrote:
           | Smart IT people were automating things with Perl and later
           | Powershell since I started professionally working in Windows
           | shops in 2000.
           | 
           | Before that I was working on DEC VAX machines where IT was
           | using DCL.
        
             | k__ wrote:
             | Yeah, but I studied with a bunch of guys who said they'd go
             | into IT, because they hated coding.
        
               | mancerayder wrote:
               | You can hate coding and be an excellent network engineer
               | or even DBA.
               | 
               | I'm an infrastructure guy and I learned to code, but I
               | don't code today. The other poster who talked about good
               | people in the old days using Perl and suchlike tools is
               | right. Competent people care about automation.
               | 
               | But there are all sorts of automation tools that don't
               | require knowing how to write object oriented code or do a
               | ton of code reviews. Terraform is one - it's yaml, and
               | the complexity is one of design patterns. Another is
               | Ansible. GitHub Actions. Many many more.
               | 
               | Let me throw out a grenade. Software developers often
               | over estimate their capabilities in technology. Because a
               | person is an expert in Ruby or Go, and on the weekend
               | they stood up a hosted app on ECS, now magically they're
               | geniuses and understand DevOps.
               | 
               | False. DevOps engineering, network engineering, DBA, and
               | a lot of other non-developer jobs take 5-10 years to get
               | right.
               | 
               | Hopefully I've slammed our Leetcode hiring practices, but
               | really I'm just venting at this point.
        
               | raw_anon_1111 wrote:
               | It's a red flag anytime I see a company with a dedicated
               | "database administrator" usually they want you to put all
               | of your business logic in stored procedures and have a
               | dozen GetCustomer_n copies for versioning.
               | 
               | What can a modern operations person do that can automated
               | anything via coding?
               | 
               | BTW: I am "expert" in cloud by any definition (did at a
               | startup, worked at AWS ProServe, staff consultant at a
               | 3rd party consulting company) and I develop. How hard do
               | you really think it is for someone with a developer
               | mindset to learn how system design works at scale and
               | bring their same developer mindset to infrastructure as
               | code?
               | 
               | It took me exactly 2.5 years from opening the AWS console
               | for the first time to being hired at AWS.
               | 
               | Everyone in my division at my current company at my level
               | can hold their own as either a developer or a "senior
               | cloud engineer". We just find infrastructure babysitting
               | incredibly boring
               | 
               | Half the reason I learned cloud was not because I didn't
               | want to manage servers - I didn't want to deal with
               | server administrations.
        
               | mancerayder wrote:
               | >BTW: I am "expert" in cloud by any definition (did at a
               | startup, worked at AWS ProServe, staff consultant at a
               | 3rd party consulting company) and I develop. How hard do
               | you really think it is for someone with a developer
               | mindset to learn how system design works at scale and
               | bring their same developer mindset to infrastructure as
               | code?
               | 
               | It depends! Do you mean clicking in the AWS console and
               | spinning up infrastructure? It takes a few days.
               | 
               | Learning terraform/CloudFormation so it's repeatable?
               | Probably a few weeks.
               | 
               | Kubernetes design patterns and troubleshooting? I feel
               | like it takes at least a few months of hands on and
               | theoretical.
               | 
               | To build infrastructure that lasts, is monitored with an
               | APM as well as infrastructure specific tooling (not
               | Cloudwatch) has cost dashboards set up to account for
               | workloads across a dozen product lines (not Cost
               | Explorer), has a CI CD pipeline automation for hundreds
               | of repos including automatic onboarding of new ones,
               | understands cloud security enough to have designed a
               | tight perimeter with some automation around detection and
               | remediation, has strong network level knowledge and knows
               | how to deal with external vendor/client connectivity
               | options (since you have to adapt to their limitations or
               | demands)... Instead of server babysitting, you know in
               | advance how to prepare the inevitable situation where
               | workloads need to scale, and already have tooling and
               | horizontal and vertical auto scaling either automated or
               | ready to go...
               | 
               | If you know these things after 2.5 years, and I say this
               | fully seriously, you are in some sort of .5 percent elite
               | in this industry and deserve something like 1M a year, or
               | you should be leading something huge.
               | 
               | Otherwise there's a risk here that you don't know what
               | you don't know, which was my original point about over
               | confidence by software engineers when it comes to
               | infrastructure.
        
               | raw_anon_1111 wrote:
               | You did see the part that I worked at startup for 2.5
               | years, then worked at AWS ProServe for almost 4 and now
               | work at a third party consulting company as a staff
               | consultant leading cloud + app dev hybrid projects?
               | 
               | I turned down a job where the position was going to be
               | created for me by a former coworker at AWS who is now a
               | director at a well known non tech F500 company where I
               | would be responsible for a multi year migration and
               | modernization strategy that would have paid about 30%
               | more than I was making at AWS.
               | 
               | I really _hate_ babysitting infrastructure and lift and
               | shifts so much I turned it down and took a job that paid
               | the same as I was making at AWS. That's just how much
               | more I enjoy the hybrid cloud + app dev roles.
               | 
               | I deal strictly with AWS on the infrastructure side, the
               | minute I'm working on a large assessment (those huge 50
               | page requirement docs) and they mention hybrid, or
               | anything outside of AWS, I bring in someone who actually
               | likes that stuff. As I do when I see it's going to be a
               | migration.
               | 
               | The other side of my job is to actually do hands on app
               | dev + cloud either doing it myself for small projects or
               | leading larger ones.
               | 
               | I'm also not the person who is going to be on call or
               | monitoring, that's for the young folks.
               | 
               | My last three projects were using the CDK, Terraform and
               | CloudFormation respectively
        
       | Hnrobert42 wrote:
       | What in god's name is the meaning of the image on their homepage?
       | It looks like a conceptual, digital rendering of a colonoscopy.
       | 
       | https://infisical.com/_next/image?url=https%3A%2F%2Fimages.c...
        
         | dddw wrote:
         | :D Yes, we demand an explanation!
        
       | solatic wrote:
       | > I started dreading the monotony of it all... My days had become
       | predictable: check the dashboards, respond to tickets, debug
       | whatever broke overnight, push some Terraform, go home. Maintain
       | the HashiCorp Vault clusters, manage the secrets pipelines,
       | answer the same support questions. Repeat. The work that used to
       | feel engaging had become routine.
       | 
       | Why are you checking dashboards (pull/polling) instead of
       | building alerting (push), so that you do not need to check
       | dashboards as a matter of routine? If the tickets are dealing
       | with the same problem again and again, why aren't you building a
       | self-service platform to let your users handle these problems by
       | themselves (especially now that LLMs are making this much more
       | trivial to build)?
       | 
       | Author sounds like he had poor technical management who didn't
       | understand DevOps (let alone DevSecOps) and turned it into an
       | operations role.
       | 
       | Everything that the author likes about Solutions Engineering, I
       | get from a DevOps role, from collaborating with other engineers
       | in my company to make them more agile, productive, and take
       | better ownership in production. Too many engineering teams fall
       | into a trap of not being allowed to focus on any non-functional
       | work (gotta ship revenue-generating features!) and LOVE it when
       | someone like me comes along, who doesn't answer to Product, and
       | can help them out on the non-functional side. I get to talk to
       | "customers" as much as I want, in a role where I can just walk up
       | to them and not need to communicate over Zoom or with significant
       | plane travel.
       | 
       | Author should have considered trying to just find a different
       | Platform Engineering role.
        
       | Roark66 wrote:
       | My path was opposite...
       | 
       | Started in early 200x sysadmining Linux boxes. Moved to an MS
       | gold partner that started with 6 employees and ended up with 45
       | by the time I left. So you can imagine the kind of work and
       | solutions we did, started with mom and pop, ended up doing email
       | systems for a 20k user system, also picked up vmware/sphere, perl
       | scripting a big monitoring system for over a year and hacking old
       | binary only legacy software to extract data, lots of extremely
       | varied short term projects.
       | 
       | Then got onto the "Solutions Architect" career path. Did that for
       | 6 years ending up in a big telco. I ended up being bored out of
       | my mind just doing designs/tech sales/delegating all the "real
       | work".
       | 
       | I decided to go into Devops and switch to contracting at the same
       | time. I now realise that was over 10 years ago now.
       | 
       | I couldn't be happier with my job since then. It's 100% remote,
       | It's hands on troubleshooting when things go horribly wrong, it's
       | solving hard problems with automation and in last 2 years lots of
       | AI when the clients decide to rip out a huge amount of
       | integration and switch clouds/other software and so on every 2
       | years :-)
       | 
       | It pays a little less and definitely has less prestige than
       | "Solutions" for a huge telco (and I no longer wear a suit at
       | work), but I can definitely see myself being happy doing that for
       | next 10 years (if the role still exists then).
        
         | mancerayder wrote:
         | How can I pay you to tell me your secret path to consulting in
         | DevOps?
         | 
         | I'd love to do this or SRE type consulting. However, every
         | organization I've worked with (including finance and
         | government) use big name big business consulting shops,
         | supposedly for liability reasons, and it would be impossible to
         | get a small consulting contract unless you had family members
         | in the C suite.
         | 
         | Moreover, what stops that remote devops from taking place with
         | highly qualified Hungarian or Polish or Portuguese engineers
         | for 40 percent of the rate?
        
       | nunez wrote:
       | I made the jump into SE (sales/solution engineering) three years
       | ago after a long career as a SRE/systems/software engineer (the
       | kind that found any excuse to break out ilspy, windbg, gdb and/or
       | tcpdump on the job) and have a love-hate relationship with it.
       | 
       | This is a long post, but SEs are underrepresented here despite us
       | being a big part of the sky high valuations that many companies
       | on here have gotten, and it's a job that is still somehow not
       | well known or understood.
       | 
       | I LOVE the travel. As someone whose happy place is seat 20F on a
       | United 738 and a rental EV waiting on the other side, the random
       | travel requests give me so much life. I enjoyed the 4 on, 3 off
       | travel life as a consultant as well, but being asked to fly in
       | for a meeting or two and get time to myself the day before is so
       | much better. In fact, this is probably THE reason why I haven't
       | gone back into the FTE world. Travel budgets for engineers are
       | generally pithy.
       | 
       | I LOVE not having to answer to a Jira backlog. I can (and do)
       | still ship PRs back to product if it makes sense for the
       | customers I'm supporting, but my performance comp isn't tied to
       | that. Interestingly enough, we are also not forced to use AI when
       | coding for the same reason (though using it to understand what
       | our customers are being increasingly asked to use is important,
       | so I do sometimes).
       | 
       | Speaking of comp, I LOVE how transparent our comp packages are.
       | The base salary is usually competitive with a high Senior/low
       | Staff SWE, but unlike these roles, we don't get very many RSUs.
       | What we do get is commission. The more we sell, the more we make.
       | No black box bonus pool allocation nonsense. Some SEs can take in
       | Staff+ total comp some years if they and their AE close a whale
       | of a deal because of this. What's better about comp as an SE is
       | that it's usually not regional. This makes the position super
       | lucrative for engineers in LCOL/MCOL cities who don't mind
       | getting on a plane every so often.
       | 
       | We also get a lot of time and space to tinker with the products
       | we're selling when we're not out in the field (since we usually
       | have to know them front to back; it's not uncommon for SEs to
       | know more about a product than engineering or even Product). Most
       | good SE managers will absolutely support you blocking off time to
       | build, which is awesome!
       | 
       | Interviews are also WAY more than chill than those for SWE. No LC
       | grinds. The hardest part is usually the tech panel (which is easy
       | if you're good at presenting and explaining technical things in
       | an accessible way).
       | 
       | So now onto the not so fun parts.
       | 
       | You are usually tied to a non-technical account executive
       | (salesperson). The nature of that role attracts lots
       | of...interesting people. Your entire existence as an SE hinges on
       | how well you get along with your AE. A great relationship makes
       | SE the best job in the world. Anything else makes it somewhere
       | between a slog and hell on earth.
       | 
       | This is also a sales job at the end of the day. There's lots of
       | talking and socializing involved. Not nearly as much as an AE,
       | but doing happy hours and dinners sometimes comes with the job.
       | As a massive introvert who often wants nothing more than to read
       | Hacker News over a nice beer in sweet solitude at the end of an
       | intense workday, you can probably imagine how draining these
       | events can be.
       | 
       | Then there are the demos and POCs: the bread and butter of the
       | role. Depending on where you are, you might be giving the same
       | demo handfuls of times per day. These can be made more fun by
       | working in investigative questions about the customer you're
       | presenting to to learn more about them and why they need what
       | you're selling (also called "discovery"), but some AEs won't give
       | you that space. Feeling like your job is replaceable isn't great
       | (even though it's not replaceable at all!)
       | 
       | There also isn't much upward mobility in this vertical. You can
       | go a lot of places OUTSIDE the SE track given the cross-cutting
       | nature of the job (Product, CTO, AE, and even back into
       | engineering are common paths), but scope as an SE is narrower
       | than the SWE path, as, again, its a sales job. (That said,
       | getting into the Principal SE track usually involves talking at
       | big shows and brand building like writing books, skills that are
       | very useful if you want a heavy hitting job elsewhere or want to
       | be the kind of person that gets paid to keynote conferences).
       | 
       | Many of the thought leaders in the SE space are technical but
       | have lost their edge. Many of them are closer to sales than
       | engineering. Some literally sell their presales methodologies and
       | don't do technical stuff anymore. Great if you want to move away
       | from that career; less so if you don't. More engineering-biased
       | people might feel out of place initially.
       | 
       | Skill atrophy is also very real, counter to OPs observations. You
       | can get away with minimal learning once you know what you're
       | doing and have your demos locked in. It takes a while to get to
       | this point, but once you're there, you can give a demo point
       | blank a any time and are familiar enough with your product to
       | lead a POC start to finish without blinking. This combined with
       | not having time to "deep" learn due to meetings, demos and POCs
       | can lead to skills slipping away.
       | 
       | Finally, that time to tinker can be hard to get if you're in a
       | patch of heavy sales activity. This is felt the hardest when you
       | join a new org and are sent into the field straightaway. This is
       | often why so many SEs are usually former consultants of that
       | product or ex-customers: shorter ramp-up time.
       | 
       | This can make it difficult to get back into a pure engineering
       | role if SE doesn't work out. You won't have enough day to day
       | experience to make hiring managers feel comfortable in bringing
       | you on, which is a massive disadvantage in this market.
       | 
       | All in all, it's an awesome and somewhat safe career path that is
       | a front row seat to how the money comes in, but it's heavily
       | situational and probably not a fit for more introverted folks.
        
         | fuzzythinker wrote:
         | Thank you. Can't upvote you enough for the info.
        
       | chopete3 wrote:
       | Solution Engineering is a highly sought after role in startups
       | and growth companies. It is an important role in established
       | enterprises too but it won't be seen as an IP role. It is a great
       | escape career path for engineers from pay scale change
       | perspective. The author didn't touch upon that part but there was
       | certainly a big salary increase.
        
       | k__ wrote:
       | Some people mentioned to me that going Solutions Engineer was a
       | good way to get more non-technical/business skills.
       | 
       | I saw a few SEs starting their own companies later, seemingly
       | because their SE roles "trained" them for the business side of
       | things.
       | 
       | I considered doing this myself; however, I'm a freelance software
       | engineer and technical writer. More a jack of all trades than
       | someone with major skills in one category of software
       | engineering.
        
         | Nextgrid wrote:
         | A jack of all trades is preferable as a solutions engineer.
        
       | bstsb wrote:
       | side note, i absolutely love Infisical's self-hosted offering.
       | it's really easy to get set up with and aside from a few minor
       | problems with their Universal Auth, i had it working in
       | production in just a few days. it's made secret management a lot
       | easier, especially across different environments!
       | 
       | i'm aware that there are limits on the free plan, but as a single
       | user i haven't hit any crazy restrictions
        
         | vmatsiiako wrote:
         | Really glad to hear that! What problems did you have with
         | Universal Auth?
        
           | bstsb wrote:
           | upon remembering, it was actually just Token Auth - for some
           | reason, when i created a machine identity in my parent
           | organization, tbe CLI would always return a 403 for any
           | project ID, regardless of whether i gave the identity the
           | adequate permissions.
           | 
           | i got around it by just generating an identity for each
           | project, which was probably a better idea anyway for
           | granularity
        
       | raw_anon_1111 wrote:
       | I realized a decade ago at 40 if I wanted to still stay relevant,
       | make more money, not go into management and not still be trying
       | to compete with 25 year olds based on how well I could reverse a
       | b tree on the whiteboard, I had no choice but to get closer to
       | "the business".
       | 
       | I got a job in cloud consulting specializing in app dev -
       | "application modernization" at AWS (mid level L5) in 2020. Took
       | advantage of every opportunity to put myself in front of the
       | customer virtually and physically.
       | 
       | Learned through osmosis how the senior consultants, engagement
       | managers (project managers) and account managers operated.
       | 
       | Got Amazoned almost 4 years later and became a staff consultant
       | at a 3rd party firm (equivalent to a senior at AWS or GCP) and
       | while I lead "delivery" projects, I'm still learning how things
       | work at the next higher level of the funnel - pre sales. The
       | level of ambiguity is high by the time it gets to me. But at
       | least sales has narrowed down what high level business outcomes
       | the customer wants.
       | 
       | My thesis is the closer I get to both the revenue drivers and
       | where people skills matter, the less ageism is a factor and
       | experience is actually rewarded and the harder it is to be
       | outsourced, commoditized or replaced with AI. I've been concerned
       | about commoditization for over a decade and that definitely
       | happened on the enterprise dev side
        
         | mptest wrote:
         | is there anyway you'd be willing to field a few questions from
         | a soon to be cs grad interested deeply in this specific career
         | path after realizing they'd been doing it in a way for free
         | already. good experience, but unconventional experience who
         | aspires to a position similar to yours?
        
           | raw_anon_1111 wrote:
           | Everyone I know who has done it, started out as a developer,
           | moved up to a tech lead position and while doing so learned
           | soft skills and presentations and gut real world experience
           | with designing systems and then moved into consulting.
           | 
           | It's from my seeing the lay of the land in 2026 almost
           | impossible to get a full time job in a consulting company
           | starting out of a college with just an undergrad doing
           | something technical - unless you are in one of the cheaper
           | countries to hire from.
           | 
           | Most besides the WITCH companies use the business models of
           | hire people in the US for the customer facing roles and hire
           | people in cheaper countries for the Lower level roles.
        
         | mancerayder wrote:
         | How would one go from devops or sre management to a customer
         | facing pre sales role like you described?
         | 
         | I thought sales was a separate career path.
         | 
         | I relate 100 percent to your realization about competing with
         | 25 year olds on Leetcode. I'm comfortable, but I realize
         | finding a new job is harder than ever, even though I am as
         | valuable as ever - they want me not only to have proven I can
         | 10x a company managing infra and people (I did and have), but
         | they expect me to spend my weekends coding, and not just coding
         | but coding esoteric algorithms than no one uses outside of
         | academia.
         | 
         | And meanwhile there's an enormous amount of messages here on HN
         | about how managers are useless and mean.
         | 
         | It's a weird spot to be in, so I'm opting for trying to prepay
         | mortgages as quickly as humanly possible before I'm unemployed
         | forever and have to call it retirement (and which might have to
         | take place in a cheaper foreign country).
        
           | raw_anon_1111 wrote:
           | I too am working on my out of the country back up plan. My
           | wife and I are going to one of those countries for 5 weeks in
           | a couple of weeks. We have already looked into residency
           | requirements as a Plan B.
           | 
           | I am just starting to get a peek under the cover for sales.
           | If I understand it correctly.
           | 
           | - "Someone" is hustling to make first contact with the
           | customer or if you are a partner of one of the cloud
           | providers, they send customers your way. I have no clue how
           | this part works.
           | 
           | - The SA talks to the potential client enough to get high
           | level business requirements to shape the contract. I'm not an
           | SA. But there is a certain AWS speciality where I'm usually
           | pulled in at this phase. We are trying to build expertise
           | around this specialty. My former mentee is an SA at AWS so I
           | know how they operate.
           | 
           | - After the contract is designed, I work with sales to
           | understand the opportunity and I am the first person that
           | does a deep requirement analysis - the business case is
           | known, the technical requirements are ambiguous. I am
           | responsible for getting the requirements and doing the
           | design, talking to the technical guys, finance, security and
           | the business folks to make sure their needs are met.
           | 
           | - then I lead the project, before AI, I would have needed a
           | couple of people on the project. Now I can do it myself most
           | of the time. It was never lack of knowledge, there are only
           | so much I can do myself.
           | 
           | To your second question, the last 2016-2024 when I set on
           | this path is a lot different than it is now.
           | 
           | I guess the best way is to work backwards from where you want
           | to be to where you are.
           | 
           | 1. How often do you know the business requirements in advance
           | compared to how often are they given to you?
           | 
           | 2. The money and the opportunities are in leading migrations.
           | There are very few decent paying hands on keyboard "doers"
           | those are easy to outsource. I lucked up that I got my job in
           | a division that does care about "developers who know cloud
           | and can lead implementations"
           | 
           | 3. How are your project management skills? The ugly truth is
           | PMs are useless when it comes to tech projects, you are the
           | one that has to have the proper context to know dependencies,
           | how to break things down, critical paths, etc.
           | 
           | 4. Have you led implementations larger than what you can do
           | yourself? Hands on keyboard folks are a dime a dozen and
           | companies can pay them a fifth of what they pay you.
           | 
           | 5. How are your presentation and communication skills? Can
           | you explain what you did to someone non technical but knows
           | their business, sonrie who understands technology but not
           | what you did and someone who knows the technology and wants
           | to know why you made the decisions you made?
           | 
           | 6. Do you have experience juggling conflicting stakeholder
           | agreements
           | 
           | 7. How is both your small talk and business speak - "adding
           | on to what Becky said", "finding alignment", "a single pane
           | of glass", "taking things to the parking lot", "we aren't
           | solutioning yet, let's talk about your business opportunities
           | and challenges "?
        
       | CuriouslyC wrote:
       | I worked for 7 years employed by a high throughput computing
       | facility at a large university as a combination of solution
       | engineer/software architect. I got paid to network with faculty,
       | listen to their problems, pitch them ideas and implement POCs,
       | then help them iterate and scale.
       | 
       | If the management of the department hadn't been so
       | catastrophically bad, it would have been the ideal job. Working
       | more traditional software engineering roles afterwards was
       | frustrating, I missed the freedom. Even as a tech lead, it just
       | felt like managing plumbers. I love creativity and exploration,
       | nuts and bolts are incidental.
        
       ___________________________________________________________________
       (page generated 2026-02-07 23:02 UTC)