Passing the Test
This post was originally published at tech.greenhouse.io on October 14, 2015. Stay tuned for some updates in a future post!
Greenhouse test automation was born in late 2013. By born I mean we hired a recent Flatiron School grad named Matt Schmaus — over several experienced test engineers — and told him to build our RSpec suite. But that’s not all. A year later, the company promoted Matt to associate software engineer; he now builds features on our full stack engineering team.
Greenhouse Test Automation Engineers (TAEs)
- Hired Nov 2013 from Flatiron School, now a full stack engineer
- Hired July 2014 from General Assembly, now a full stack engineer
- Hired Nov 2014, self taught, now a QA lead
- Hired Dec 2014 from Fullstack Academy, now a full stack engineer
- Hired Apr 2015 from Fullstack Academy, in first year as a TAE
- Hired July 2015 from Fullstack Academy, in first year as a TAE
- Hired Aug 2015 from App Academy, in first year as a TAE
What We Do
Test automation engineers learn our complex Rails app by writing comprehensive RSpec tests, including unit tests, controller specs and feature scripts. You name the team priority — we’re involved. For example, we’re on the home stretch of fully automating the manual regression required to release code; it used to take hours. This huge win enables us to move from weekly releases to multiple feature-based releases a week. We wrote cross-browser specs when we spun off our critical job boards into a service. We’re adding infrastructure specs, and Jasmine tests to cover Angular features. We even hold regular training on how to test at Greenhouse.
How We Hire
Greenhouse finds test automation candidates through bootcamp hiring nights, referrals and applications through our website. Another fruitful source is our full stack engineering pipeline. Sometimes, we’ll spot a candidate with high potential who’s struggled on some parts of our senior interview. We encourage these applicants to interview for test automation engineer — as a path to advancing within our tech team. And want to stand out? Head to the monthly full stack engineering meetup and meet us.
Our process starts with a 30 minute technical phone screen. Pass that and move to a one hour phone interview; we’ll test your tech skills more deeply and talk about your motivations for the job.
Count on questions about:
- Software Architecture
- Data Structures
- The Internet
- Rails (if you have the background)
Last step is coming onsite for a few hours of coding and cultural interviews. Expect live programming, and be ready to walk us through your work and explain your decisions. We value thoughtful planning.
Who We Look For
We like test automation candidates who are:
- Skilled. You have a solid, broad tech grounding — at a level that shows you’ve nailed the bootcamp curriculum and then some.
- High-potential. You are motivated to keep improving.
- Nice. We want to work with you.
- Coachable. You’re receptive to code review and excited to learn from amazing senior programmers.
- Responsible. You’ll roll up your sleeves and fix problems, even if you didn’t introduce them.
How We Mentor
Every test automation engineer is assigned a senior mentor — count on regular 1:1 meetings and ad hoc pair programming. But you have access to the whole engineering team. Stuck on testing Angular? Grab an experienced front-end engineer. Errors deploying to a staging environment? Somebody’s been there. There’s also regular whiteboarding sessions, where we teach each other through books like Ruby Metaprogramming and Clean Code.
10 Months Later
As promised at my interview, I quickly earned responsibility over testing, and am not far from a senior engineer when I have questions. Five months in, I got my first feature card.
Most bootcamps tell grads they’re immediately ready to excel in production. I sure wasn’t. But I’m deeply grateful for my testing foundation. For one, a production code base is more complicated than anything most junior engineers have seen. Writing specs teaches you how to navigate a complex feature’s path across the full stack. Two, an engineer who respects testing is much less likely to introduce bugs. Already, I’ve used tests to catch my own feature bugs before they hit production.
By now, the majority of my cards are features — I’m a full stack engineer.