bacon Photo by Michelle @Shelly Captures It on Unsplash

It’s fair to say that the primary toolset used by our private-cloud engineers (vRealize Automation and vRealize Orchestrator) are not widely used, and we historically have not had have a large pool of experienced local talent from which to draw. We therefore tended to hire general IT people with a knack for solving technical problems. These people tend to be infrastructure engineers with a flair for automation.

This gave us a problem when it came to designing a technical test which would allow us to fairly judge a candidate’s potential competence on a piece of software which they were unlikely to have had any prior experience.

To solve this problem, we came up with The Bacon Test. This is a take-home test normally issued after the first interview. The test is as follows…

In publishing and graphic design, Lorem ipsum is a filler text or greeking commonly used to demonstrate the textual elements of a graphic document or visual presentation. Replacing meaningful content with placeholder text allows designers to design the form of the content before the content itself has been produced. However, it’s very boring. What we’d like is the tasty functionality from https://baconipsum.com/json-api/ in a PowerShell, Python or Bash script, so that the output can be used in other scripts.

The question is deliberately vague as we want to know how you approach the problem (and even how you provide the answer). However, don’t feel like you need to engineer an entire solution; this shouldn’t take more than a couple of hours.

The lack of instructions gives people a lot of scope for answering the question. Someone at the start of their career, may provide a simple bash script. Someone with slightly more experience, a more comprehensive Python script. Someone more senior might provide an elegant, modular solution alongside some design documentation.

We’ve found that this has worked very well for us. It’s quick enough that people are more inclined to do it. It’s also obviously not real work that we’re trying to get done for free (we’re not Brewdog!).

Reviewing the submission is more of an art than a science, and generally gives us some good discussion points for the second interview.

If they supplied code

  • Did it work?
  • Is it commented?
  • Is it of sufficient quality?
  • How did they approach the problem?
  • Which tools did they choose to solve the problem?

Also, how did they submit the response?

  • Was it shared via their GitHub profile?
  • E-mailed as an attachment?
  • Pasted into the e-mail?
  • Did they over-engineer the solution? Or under-engineer?
  • Most importantly … did they enjoy it? This is after all a flavour of the work they will be required to do most days!

We don’t judge people on how long they took to complete the exercise. So long as the candidate communicated any potential delays (“I’m moving house” / “I’m going on holiday” / “I have a sick cat”), we try to respect people’s free time, and their personal circumstances.

Over the years we have been using the bacon test; we’ve found that it has proven to be a fairly accurate barometer of - not just someone’s technical ability - but their approach to solving a problem.

And yes, we do also offer a vegetarian option!