DevOps Automation Engineer
In this role, engineers are responsible for implementing automation solutions that help speed increase the speed of our customer's ability to deliver features to production while working with other DevOps Automation Engineers at Stelligent.
- 2-5+ years of technical experience in either development, operations, or full-stack implementations
- At least 1-2 years of demonstrated programming capability in a high-level programming language such as Ruby, Python, Java, C# or other language
- 0-2 years successful customer engagements providing continuous delivery solutions, preferably employing AWS
- 0-2 years of demonstrated Linux or Windows command-line capability
- Familiar with core suite of AWS Services related to DevOps, with particular depth in those that are heavily used when providing DevOps Automation solutions, including the Management and Deployment services such as AWS CloudFormation, OpsWorks and IAM
- Experience establishing and employing Continuous Integration practices and tools such as Jenkins or other CI tools
- Frequent and comfortable use of configuration management automation tools such as Chef (or other such tools) in creating continuous delivery systems
- AWS Certified Associate (Solutions Architect, Sys Ops, Developer). If you do not already have one or more AWS certifications, we focus on achieving that during a new Stelligentsia's first 100 days on the job.
- You will employ industry leading Continuous Delivery patterns and collaboratively work with other members to execute them to achieve successful continuous delivery solutions for Stelligent’s customers.
- Collaboratively work with Advanced DevOps Automation Engineers and Senior DevOps Automation Engineers
The remainder of this closing summary is the same we share for all engineering postings.
We are seeking engineers who appreciate and have experience with both development as well as operations (hence the current cultural buzz word, DevOps). We prefer engineers who have come from the Development side first, though we value the opposite path, and expect that for every three Dev->Ops types, that we will hire one Ops->dev type. We have found that the former tend to embrace the software engineering and development best practices easier than many people who have come from the latter model. That being said, as we get more and more engaged with established customers, the credibility of the Ops->Dev (both their experience and the burden of production responsibility) tend to carry a LOT of weight and gravitas.
Our engineers need to be ready to invest themselves in hands-on keyboard activity. They will be committing code to the likes of Git repos every day. We do not need “hand waving architect-only” types, though we like engineers who can both knock out code and be comfortable sharing large-scale and abstract concepts to a crowded room. We want hardcore, full-stack-aware engineers who are not afraid to learn the wealth of tools we need to employ and who are comfortable with a constantly changing landscape of tools and techniques.
They absolutely need to be able to communicate both verbally and in writing. A great deal of our communication is done remotely, and requires super clear thought, enunciation, and articulation.
Some - though not all - customers require a richer introduction than others, so engineers bound to engage with them may require secondary levels of vetting (e.g., interviews, projects, and background checks).
Our engineers can live anywhere in the USA. Most of our customers require that we perform deep background checks. You should be willing and able to work for both commercial and government customers.
Engineers tend to work in teams of 2-3 (vs. solo), though once comfortable with the Stelligent way, we are comfortable letting individual engineers be on their own. That being said, it has happened that circumstances have resulted in a new engineer being engaged with a customer in nearly a solo manner (e.g., 1.2 engineers). We “live” in Slack and Sococo, and even though everyone is in different places, we have a culture of open communication and sharing that makes up for the geographic separation and lack of formal office.
We have three books we highly recommend our candidates read/know, if not before knowing us, at least once they are in our pipeline. Those books are:
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Kindle)
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (Kindle)
(And of course) our CTO's own Continuous Integration: Improving Software Quality and Reducing Risk (Kindle)