Nerd For Tech
Published in

Nerd For Tech

Trailblazing in an often under-appreciated role

The experience of shattering a glass ceiling

How I got into Engineering Productivity

In the nineties, the software industry at large had Developers (who wrote code) and Testers (who tested the code). Traditionally a Developer role had a higher technical bar and a higher pay, which created an unwritten class system in the industry. There’s still a leftover stigma today.

Should I continue down this path at Amazon?

There is no ‘us’ and ‘them’

Part of a “glass ceiling” is realizing that there’s an array of things X, Y, Z, that the main group is doing and the under-represented group might not be. I started looking at some of the things that SDEs were doing that SDETs weren’t traditionally doing, and decided I should do them too.

  • SDEs filed tons of patents on their work. For whatever reason, SDETs did not file patents very often. Our work is just as valuable and innovative, I told myself. I filed an idea, and it got rejected. I filed another idea, and it got rejected. I stubbornly filed a third idea, and it got approved. Over the course of the next decade I would successfully file 35 patents in software testing and engineering productivity topics on behalf of Amazon.
  • SDEs interviewed SDEs and SDETs interviewed SDETs. If I wanted SDEs to respect me as an engineer, I should be able to interview SDEs just as well as anybody else, I told myself. So I signed up to become a Bar Raiser (“BR”), which is a specially trained and certified Amazon interviewer that among other things has the responsibility for the final Hire/No Hire decision. Training was intensive and demanding, and I flunked out. I stubbornly tried again, a little later, and after months of training and shadowing I was certified. I conducted 813 interviews in my time at Amazon, and yes, most of them for SDEs.

Could I have Principal impact?

One question remained. Could I, as an SDET, create something that was impactful enough that could justify a promotion to Principal Engineer? That was a tall order. I could see why the path to become a Principal SDE was more well-lit. You’re creating customer-facing features and you can simply point at the revenue these create. But as an SDET, you’re focused on engineering productivity. Your job is to help other engineers around you be more efficient. That’s harder to quantify.

The Finish Line

Being a trailblazer was both a blessing and a curse. On one hand, when you’re trying to do something that nobody has done before, you have no clear role models to emulate. Because there’s no frame of reference, it’s unclear when you’re there. You couldn’t stipulate ‘well Chris did X and got promoted, so if I do X I should get promoted too.” On the bright side, I figured, if nobody has done it before, there is no fixed path to follow… I could make my own path!

Final thoughts

I think at some point we all encounter invisible barriers that prevent us from rising beyond a certain level in a hierarchy. I encourage you to challenge that status quo. Sometimes the path-less-traveled is not well lit, and lonely. But there’s unspoken beauty in it and satisfaction at the end of it.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Carlos Arguelles

Hi! I'm a Senior Staff Engineer at Google. Prior to Google, I was a Principal Engineer at Amazon for 11 yrs, and before that, I spent 11 years at Microsoft.