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.

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.

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.

Can you share one such puzzle?

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

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

Apply here :) - https://jobs.ashbyhq.com/infisical/2ef2e211-9332-4e68-bd86-e... - https://jobs.ashbyhq.com/infisical/73b79555-8b3f-486b-84fa-8...

It's always nice when the customer wants to improve the process/product, it can overcome internal friction that had prevented making things better.

My experience in a “product company” - Pre-sales solutions engineer - the original problem solver. Professional services - post-sales firefighter :)

Inspiring article. Well written. Totally feeling it!

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.

Best job in the world.