Switching jobs can be very stressful. While interviews can provide a glimpse of a company’s inner workings, interviews are not a great way to get a true feel for what a company is like and what would be expected of you when applying. From an employer perspective, interviews aren’t the best tool for measuring competence and work ethic. This is where work trials can help both the employer and applicant.
Recently, I was hired as a Product Developer at Delicious Brains. The job posting does a great job of introducing the hiring process but I thought more details would give some insight and, in particular, demystify the work trial from an applicant perspective.
What’s a Work Trial?
The work trials at Delicious Brains are modeled on those at Automattic, where an applicant works part-time as a member of the team. The work done during a trial is identical to the work you would be doing full-time if hired. What better way to learn than by doing?
Usually, a work trial involves 10-25 hours per week, depending on how much time you can commit. This time is very flexible as well (the team is distributed across timezones). The trial is paid ($25/hr) which is a nice bonus for when you switch between two jobs and two pay cheques. If the trial doesn’t work out, of course you still get paid for the time you put in.
This process provides a great opportunity for the employer to see if you can do the job and for the applicant to see if they enjoy the new job. Generally, work trials are a safe, stable way to find a new job while providing the similar safety for the employer.
A word of warning regarding the time commitment of the trial. I chose to do 20-25 hours per week in addition to working my full-time job. This meant early mornings, lunch breaks, evenings, and weekends (more or less, most waking hours I wasn’t doing my full-time 9-5) would be spent learning and contributing to the team. I was able to do this as my obligations outside work are more limited than others – for example, I don’t have children. Work trials can be limited to even 10 hours per week but would mean the length of the entire trial would be extended.
Getting the Work Trial
Prior to starting the work trial, a fairly detailed job application was required as the first layer of screening. Brad reviews each one personally. It took some time for me to pull together all the needed parts of my job application: my resume, an introduction letter, etc. The job posting provides a pretty detailed list of what is required. One item that stands out is the guided tour of a sample project. The sample project is meant to demonstrate your aptitude for programming, but more so your organizational skills, problem solving approaches, and ability to explain choices made in your codebase.
Earlier this year, I created a WordPress-powered point of sale (POS) system for The Brake Room – complete with memberships, SMS texting, and self-serve pre-ordering. I packaged together my application and prepared a GitHub repo. The codebase of the POS was heavily documented with inline comments, the repo had a complete wiki, brief roadmap for future development, and there were ready-to-install downloads. Also there was one area in the codebase where I described, line-by-line, how the custom membership-based gateway functioned.
Once my application was ready to send in, I did the obvious: procrastinate sending it! I had been aware of the job posting for months, through the Apply Filters podcast, but when I was ready to apply I didn’t due to fear. I had been working in advertising and creative services for 8 years and doubted my own ability. While working on my application, the closer I got to completing it, the more nervous I became.
After about 2 weeks of stewing, my spouse encouraged me to try, as I “would never know if I didn’t apply” and that I would feel far less nervous. And, as usual, she was right. I applied and instantly felt like 20lbs was lifted off my shoulders. If you are in a similar situation, hit the send button.
Not long after, Brad’s reply…
“The team and I love your application but we currently have 3 developers on-trial… A couple of the trials should be done in the next couple of weeks. I’ll reach out to you then.”
I was over the moon to be considered! He followed up a couple of weeks later and we started off by defining the work trial.
Make It Yours
Brad emailed me some details about how they structure work trials. After some discussion, we agreed on the following setup for the trial…
- 20-25 hours per week
- 100% remote
- A start date of June 6th
- Lasting approximately 3-6 weeks
- Taxes and billing for the trial were super easy as Brad is a fellow Canuck 🇨🇦
We agreed upon a ballpark employment package if full-time was offered at the end of the work trial (salary, benefits, holidays, etc.) to ensure we were both in the same neighborhood. If the trial worked out, we would circle back and fine-tune the employment package. With these preliminary details in place I was ready to start my trial
When my first day came around, Brad sent me quite a few pieces of information. Firstly, the keys to the castle were handed over. This included logins, passwords, invites to services, everything, you name it. One of the invites was a Slack invite and I logged on that first morning to a very approachable, kind team…
A bit of a side note: at this point there were already two
Iai?n's on the team, which definitely makes conference calls interesting. To avoid confusion, Ian Jones goes by “Baldy” or “Jonesy” (when he has the choice) and Iain Poulson goes by “Beardy”. I’m sure a nickname will pop up for me going forward (suggestions welcome in the comments).
After introductions were made, I started reading the extensive wiki and documentation that Delicious Brains uses for knowledge sharing and storing. The wiki was essential and the ultimate lifeline during my trial (and still is now that I am full-time). The wiki includes information on git workflows, coding standards, infrastructure setup, customer support workflows, etc. This type of documentation is required when doing work trials, otherwise I would either be wandering around a bit aimlessly or would be pestering my colleagues non-stop about simple questions.
Amongst the pages of the wiki was a document entirely devoted to onboarding for a work trial. This outlined what the next 6 weeks would involve for me. There were three overarching sections:
- Keeping Informed by participating and discussing issues, features, bugs, etc. through various channels (mainly GitHub, Slack, Trello)
- Working with Code by working on WP Migrate DB Pro issues
- Customer Support requests for help
This aspect of the work trial was ongoing throughout the entire process and involved keeping informed of issues and discussions on our GitHub repos, while adding to the conversation. This was a great way to get a good high-level view of our products as a whole, where they are heading, and how we were going to get them there.
My first few days revolved around getting up to speed with the repos and chiming in where I could. I cannot lie, my first day could be summarized as
¯\_(ツ)_/¯. The shear amount of information was an Everest (WP Migrate DB Pro for example had over 150 open issues then) but making use of the wiki and a very responsive team really helped me get to a point where I could start to contribute.
Working with Code
A few days in and I was ready to pick up some code. I got my local environment set up and ready to go, assigned myself my first issue, and pulled down the WP Migrate DB Pro repo. I started working away but quickly found myself in the deep end… with sharks… that had lasers.
As mentioned before, I previously worked in advertising for 8 years and my toolbox was honed to that type of work. I enjoyed a lean, flexible toolbox. This type of setup was fine when working on many client projects at one time (particularly custom themes) but didn’t lend itself well to digging deep into plugin development. Using techniques like
print_r tended to be very time consuming and rarely gave the answers I was looking for. Enter PHPStorm.
Thankfully, we have a
card-carrying PHPStorm evangelist on staff that is always eager to share the Jet Brains KoolAid. Iain Poulson (Beardy) hopped on a Skype call with me to run me through some tips and specific features of PHPStorm that would aid me with WP Migrate DB Pro development. This brief 30 min session was absolutely invaluable and has changed how I develop.
I won’t go through all the pieces of advice Iain imparted but one has been indispensable: xDebug integration with PHPStorm. Right before I started my trial, Iain had published an article outlining some of the features in PHPStorm that stand out, including xDebug integration. If you are unfamiliar with xDebug integration in PHPStorm, Iain’s article is a great place to start. Changing my workflow to use PHPStorm and its robust feature set has changed how I program, test, and gives me more confidence when committing bug fixes and enhancements.
With my new arsenal of tools and tips, I went headstrong into a handful of issues for WP Migrate DB Pro. After opening some pull requests, having them reviewed by teammates, and merged, I was starting to feel a bit more confident with some areas of how WP Migrate DB Pro worked.
Working closely with Jeff and Matt on these initial issues was fantastic. For those of you who don’t know, they have the patience of saints. Each review they did, or question they answered really helped shed light on the inner workings of the plugin.
With a handful of issues fixed and merged, Jeff chimed in…
I think we’d prefer to see some meatier issues from you, so I’d recommend starting with…
This led to me picking up a few issues that required some larger changes that I would be working on for a 3-4 week period. Throughout development, I would push code regularly for review to help answer any questions. This part of the trial was very enlightening and rewarding; it pushed me to become a better developer and equipped me with the knowledge needed to start helping customers.
To ensure customers have good experiences with our products, all developers at Delicious Brains actively take part in support. To me this makes complete sense. Coming from a client services background, it wasn’t uncommon for me to speak with clients and get my hands dirty with PHP within the same day. I love this type of approach as support informs what is important in development. If a repeat issue comes through we can patch it quickly. If a complex issue comes in we have ample diagnostic and test data to correct it.
Back in 2013, Emily Triplett Lentz at 37 Signals (now Basecamp) wrote a great post on this strategy and how it makes for better products and happier customers. Her post is definitely worth the read.
About halfway through the trial, Brad gave the go ahead for me to move onto support. This meant I was still developing (on already active issues only) while climbing into the support saddle. At Delicious Brains we make use of Help Scout for support. It’s a great system for ongoing support requests, integrations with third party services, and keeping a historical backlog of issues. During the first part of my trial, I leaned on the historical backlog of customer requests, which proved to be very helpful when developing (specifically UI elements or making UX decisions).
Using the backlog of customer requests was essential when first starting support. Typically, I’d grab a support request, investigate similar issues that have come in before, and spin up any test environments if I needed to replicate the bug/issue. Once I had drafted up a response, I’d get someone from the team to review it, as the last thing I’d want to do is send out inaccurate advice to a customer. With their review (and potential changes) the request would go out. Lather, rinse, repeat.
After roughly 6 weeks of early mornings, evenings, lunch breaks, and weekends spent while on trial, Brad sent me a brief email…
Good news, you’ve made it through the grueling trial!
If it wasn’t 10am when I read the message, I would have had a drink. I was beyond excited! We reviewed the initial employment package we had worked out earlier and fine-tuned a couple of details.
From there, my duties with Delicious Brains went into hibernation mode where I was still keeping track of day-to-day activities but not picking up any new issues. This helped me focus on providing my previous employer appropriate notice (finish up projects, knowledge share, help find and train replacements, etc).
Some quick survival tips for those taking part in a similar hiring process with work trials.
- Sleep well; a tired brain is slightly better than a drunk brain. Getting enough sleep is paramount.
- Read everything thrice to help it really permeate into those neurons.
- Learn from example by reviewing how others on the team have approached similar issues.
- There is no ceiling to learning and it is quite alright not knowing how to do something. What is more important is knowing how to learn and loving to learn.
- Screwing up will happen, frequently. Instances like this are great for learning.
- The team is there to help you. It’s better to ask than remain ignorant.
- Lean on your inner circle. In my case that was my wife. (Thanks honey!)
If you’re interested in another perspective on this type of hiring process, David Clements has a fantastic article about his time applying and doing a work trial with Automattic in 2014. His post definitely helped me prepare.
How About You?
Work trials are a fantastic method for finding and on-boarding new employees. Through my work trial, I was able to better understand Delicious Brains and the company culture. Also it afforded me a great opportunity to see if I enjoyed doing product development.
Do you work at a company that makes use of work trials? Have you done a work trial in the past (or are currently doing one)? How have you found it has helped you prepare for the job? Let us know in the comments below. Or even better, submit your application. We’re not starting new trials now but we’ll likely be starting them up again in early 2017.