Support an Interview-As-Code Model

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 proctors.
• 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 that 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, allowing 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 built and pushed in matter of 1-2 minutes