Support an Interview-As-Code Model
Submitted By Jenkins User Carlos Rodriguez Lopez
An innovative technical simulation for a new HR approach to assess and interview potential developers for CloudBees.
Organization: CloudBees | www.cloudbees.com
Industry: CD/CI Software Development
Funded by: CloudBees Support Team
Programming Language: Python, Linux Bash Script
Platform: Docker or Kubernetes, Linux
Version Control System: GitHub
Build Tool: Docker
Team: Arnaud Héritier, Manager / Support Tooling | Allan Burdajewicz, Systems / Software Engineer
Community Support: Jenkins.io websites & blogs, Networking at Jenkins event, Spoke with colleagues and peers
Creating a Technical Simulation platform for
interviewing support engineer candidates worldwide
Background: CloudBees provides the leading enterprise DevOps solutions, so developers can focus on delivering great software rather than operational processes. It comes as no surprise that when the engineering set out to build an interview platform to support engineers candidates around the globe, we decided to create a framework using ‘technical-simulation-as-code’ in which our candidates can demonstrate their aptitudes and attitudes in real-world scenarios (labs).
Goals: Create a Technical Simulation framework, coded by Jenkinsfiles and JCasC, for interviewing support engineer candidates worldwide. The framework had to be:
- Remote: Technical-simulation-as-code will help us search for — and interview —the best talent, no matter where they reside.
- Secure: Restricting the inbound traffic (SSH and HTTP) to the interview nodes by the proctor and candidate IPs. Candidate IP does not access the proctor’s resources.
- Resource constraining: The cloud objects are created on-demand and then destroyed after the scheduled time for the simulation, for cost savings.
- Autonomous: To avoid silos of knowledge in this process, team members must be empowered to become proctor.
- Auditable: All proctor and candidate details (emails and IPs) are stored. Timing for deploying, simulation and destroying is tracked.
- Organized: The required information for the candidate (questions and resources) and proctor (answers and follow-up questions) must align with corporate branding and digital look & feel..
Solution & Results: We are able to support an “Interview-as-Code” model consisting of two modules, both orchestrated via Jenkinsfiles: Deployer and Lab Book.
Deployer: The Deployer is a parameterized pipeline job which builds up the required resources into the selected cloud vendor (initially AWS) from the candidate and proctor details (IP and mail account). Once a proctor triggers a manual build, the following sequence of events happen:
- Creating all the required cloud resources: Virtual Machines, Security Groups, Primary Keys.
- Publishing documentation and resources into websites for the candidates (questions and resources) and proctor (answers and follow-up questions). Proctor also has access to the candidate website.
- Packaging and uploading the book of labs to the master node.
- Notifying the proctor that the environment “build up” process has finished, including URL for the candidate and proctor websites.
- Destroying the environment, once the technical simulation is finished.
- Notifying the proctor that the environment is down.
Lab Book: The Lab Book was a pipeline job, using a Kaniko agent, which builds and pushes Jenkins labs from the Jenkins Official Docker image configured via Jenkins Configuration-as-Code per different scenarios.
Having run that build, a book of labs is available. This contains ready-to-launch containerized scenarios used as common threads to establish proctor/candidate conversations about web application troubleshooting and DevOps concepts.
There are two scopes for troubleshooting:
- labs applications that are not able to start up
- labs with failed pipeline builds.
The key Jenkins capabilities utilized were: Jenkins Docker official image, Jenkins Configuration-as-Code, Kubernetes plugin, and parameterized pipelines.
Our project was quite successful. Being a globally distributed team, this Technical Simulation framework eases the interviewing process for support engineer candidates which allows us to increase the talent pool for CloudBees. Jenkins is a well known application across the DevOps industry thus our candidates feel comfortable with troubleshooting the issues we have prepared for them in the troubleshooting labs.
Better still, are the performance results leveraging Jenkins, including:
- Time to create all required resources in AWS is now less than 1 minute
- Time to destroy all required resources in AWS is now less than 2 minutes
- A particular Jenkins troubleshooting lab can be build and push in matter of 1-2 minutes