My Trial and Getting Hired at Delicious Brains

db-trialhiring

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 by fire.

Rookie Onsite!

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…

Meeting the 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

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 var_dump and 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.

Customer Support

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.

Getting Hired

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).

Survival Tips

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.

About the Author

Ian McFarlan

Ian is a PHP and WordPress developer in Ontario, Canada. Coming from an advertising background, he loves to create powerful, easy to use tools. He has a bit of an addiction to learning.

  • mbm

    Reading through this experience, it seems really unbalanced towards the employer, and strips mobility and flexibility from the potential employee… Effectively giving a very low hourly rate for freelance work that should be at least double that. To me, it seems like a way to pay a freelancer 50% of what they should be paid, with an opportunity to transition into a full-pay employee after some grace period. In other traditional industries, this practice isn’t allowed throughout the United States (for instance, in California, paying someone as a “trainee” when they’re contributing work comparable to another full-pay employee is usually illegal). Though, for an industry like software development, I could see how a case could be made that working on issues, bugs, or support could be like any entry level employee who can’t command a higher salary.

    ( edit — sorry hit enter too soon)

    There’s one line that drove me to reply:

    “After roughly 6 weeks of early mornings, evenings, lunch breaks, and weekends spent while on trial…”

    This seems like an unfair work:life balance for only $25/hr. Developers who have full time employment who also freelance know that the early mornings, evenings, and weekends are part of being a freelancer, but it’s also why the rates are typically much higher than $25/hr, especially for someone in a European or North American country. If you were between jobs and didn’t have to do the early mornings/evenings/etc, then paying a fraction of the rate seems like taking advantage of someone who is in a difficult life situation to get quality development out of someone for less pay.

    I’m glad that it worked out for you and seems like a really rewarding opportunity in the end, but for the 3 or 4 developers who didn’t successfully pass their trials, if I were one of them I’d feel like I was contributing to a project and being underpaid for it, as some of the compensation seems to be this vague “opportunity” at the end of the trial, especially when full employment wages were settled on. E.g., “Perform your role for 20 hours, at a fraction of the full-pay, and you may get rewarded with $X salary, at 40 hours, for full pay.” Maybe this is par for the course when looking to work for agencies and small groups in the WordPress community, but I don’t think that reflects well on the community. This sort of practice probably wouldn’t be tolerated if it were scaled up to the corporate software development level.

    That all said, very interesting look at working for Delicious Brains, Automattic, and other potential WordPress agencies. Well written and filled with good tips for other people looking into employment trials. Also, curiously, are there any benefits extended to trial employees?

    • Thanks for the perspective and comments @mbm!

      I had chosen to do a more intense 20-25hrs a week as my personal schedule could accomodate for it. Many trialees opt for closer to 10-15hrs a week as it is more reasonable for most people’s schedules. While on trial, Brad and the team were more than flexible in terms of timing and time commitment. One example that comes to mind was my wife’s birthday – you better believe I wasn’t online that day 🙂

      Typically, most trialees maintain their full-time job while taking part in their work trial due to the safety and security. The process is very flexible and meant to adapt to a potential employee’s time commitment.

      I can understand your concerns of potentially taking advantage of potential employees. The trial aims to mitigate long term issues for both the employer and employee. Using traditional hiring processes, both parties take massive leaps of faith, without much information to go on (other than resumes, job postings, etc). Making use of trials allows both parties to see if it’s a good fit _before_ a long term commitment is made. It’s an added safety net for both.

      While on trial, you are paid contribute but you are mainly paid to learn. I see this as a bonus because as I went through the trial I became a much better programmer and problem solver (due to being surrounded by Delicious Brains). Whether I was hired or not, I was thrilled with the progress I made coupled with the moderate pay associated with it. As I was doing this trial while maintaining a full-time job, the added pay was nice and required (spec work has no place in our industry).

      In terms of scale, some larger companies do make use of this kind of structure. For example, I was hired at Rogers Telecommunications through a similar process a long time ago (during the reign of Ted Rogers) but I am not sure if they still have that setup.

      Benefits were not part of the work trial due to the the timeline involved (6 weeks or so). With trials lasting from 3-6 weeks and insurance companies often taking months to align benefits, I don’t feel benefits would make much sense. As well, with the majority of potential employees having a full-time job while on trial, they would typically already have a benefits package.

  • AC

    I understand that you learned a lot, but you also contributed a lot. Had you been on staff you still would have learned a lot but you would have been paid appropriately for your contributions. You got ripped off. DB should have paid you what you were really worth… what they would have paid you on day one on the job. After reading your article I would not use (buy/subscribe) their products because I now have a very negative opinion of the company. They took advantage of you and I wonder how many others whom they don’t hire that they put through the same (underpaid) system.

    • That should be Ian’s understanding – whether he was underpaid, or not. You should not judge by your personal feelings of how low those $25/h are, as we all have different goals, plans and wishes.
      In my opinion – if person is ok with such terms and agrees on them, nothing wrong with such approach. DB are not the only employer on the market, don’t like the terms – try other companies.

      And linking quality products with agreement between employer (creator of the product) and its employees seems to me quite wrong. There were lots of reports/stories about bad work conditions in Apple, though millions of users buy its products and are happy.

      • I agree – it is a choice and possibly even negotiable depending the work you’d be doing and role.

      • AC

        I’ve been self-employed as a contract programmer and owner of a service business for 40 years which is longer than some of you have been on the planet! I know one thing as a fact. If a company or client will try to take advantage of you before you start with them (i.e. contract-to-hire, or trial-period, etc.) they will take advantage of you after they hire you. A twenty to forty hour trial project is hardly enough time for them to determine your true value. If you are worth $100 /hr. after forty hours you are worth the same before.

        I understand that a probationary period can work to the advantage of the company and the potential employee. But you can’t tell me that someone with Ian’s background, education, and experience is only worth $25/hr. on Monday and worth four times that (counting benefits) on Friday (40 hours later.)

        A company that will exploit people, even if the people let themselves be exploited is a company that has a serious internal cultural problem… and I for one would not (do not) buy their products or services if I have an option. I don’t shop at Walmart because of how they treat their “associates” but I do buy coffee at Starbucks because they help their employees get health insurance and pay college tuition.

        You young(er) people starting out are free to have your own opinions, but you can’t have your own facts… and as you get more experienced in the industry you will find that there is no shortage of companies (especially in “the valley”) that will happily take advantage of you under the guise of “training” or “trial work” or “contract to hire.”

        Bottom line, Ian gave the company a week’s worth of his talent and experience for entry-level wages and the company got top-notch experience and probably excellent code for almost nothing. If that is OK with you, that’s fine. But it is not a corporate culture that I think is moral or ethical or one that I want to be associated with.

  • I think this approach is fair for both parties. While it may be relatively easy to find an employer looking for your skill set – finding one where you can truly excel as a team member can be more challenging. There is risk for both parties. You might leave a position for one that you may find you’re not an ideal fit for later – and the employer risks valuable time to find that out. The trial allows both parties to see if the fit is ideal and whether a move will be beneficial for both.

    Whether or not the hourly rate is fair – or should be equal to the hourly rate you would receive once hired, is debatable.

  • Seems like the main problem people have with our trial process is the hourly rate of $25/hour. Although it comes as a surprise, this is a very interesting discussion. I’m definitely open to having my mind changed on this, but here’s where I am right now…

    As Ian said in the article, our trial is based on Automattic’s trial as reported by Dave Clements, including the hourly rate. Dave reported that Automattic paid him $25/hour during his trial. When I was stumbling my way through hiring, I thought that if it worked for Automattic, it should work just fine for us. And so far it has. Of the dozens of people we’ve had on trial over the past few years, only one person had a problem with the trial rate. That certainly doesn’t mean that the rate is fair, but it definitely does mean that people were willing to accept it without complaint.

    From the company’s perspective there are some reasons for a lower rate:

    – There’s often a steep learning curve for adopting our tools, processes, standards, etc and progress is very slow
    – Having a person on trial takes time away from current employees and slows down work on our products
    – We only hire about 1 in every 5 people we have on trial
    – We often discard all the work that a person did on trial

    This certainly isn’t a case where the company is able to push its products forward by conning developers into a low rate. People on trial usually produce very little and sometimes nothing at all. Those who ramp up quickly and start producing quickly get a job offer quickly. I’ve sent full-time offers as early as 40 hours into a trial.

    I appreciate you folks pushing back on this rate. It’s definitely worth some further consideration.

    I thought I’d also include the exact email I sent to Ian at the very beginning in case anyone is curious…

    Hey Ian,

    We’re now ready to bring you onboard for a trial to see if you’re a fit for us and we’re a fit for you. Then if we both feel like taking the relationship to the next level you can go full time!

    I’d like to follow Automattic’s trial process (20-25 hours per week for 3-6 weeks at $25/hour) as they’ve probably honed it over the years. Can you manage that? If you can, great, if you can just squeeze in 10-15 hours per week, that works too.

    So, assuming you’re still interested…

    1. Does that trial compensation work ok?

    2. How much time can you put in per week on a part-time basis?

    3. When can you start your trial?

    Cheers,
    Brad

    • What if the hourly rate was based off the partially agreed upon salary + the self employment tax?

      So if the salary was $75k, hourly that would be $36. In the US the self employment tax is 15.3%, which would be another ~$5.50, so (rounded up) the hourly rate that the contractor gets paid would be $42. The additional amount for taxes could be flexible based on however each country treats freelance income.

      I feel like thats a decent compromise because that is far under a typical freelancer’s rate (which is good for the employer), but it’s also about as close as you can get to what the employee will actually be paid once they are on payroll (which is good for the employee).

    • Ulrich

      From the company’s perspective there are some reasons for a lower rate:

      – There’s often a steep learning curve for adopting our tools, processes, standards, etc and progress is very slow
      – Having a person on trial takes time away from current employees and slows down work on our products
      – We only hire about 1 in every 5 people we have on trial
      – We often discard all the work that a person did on trial

      I feel this is a cost of doing business. Every business has this issue. I don’t think it is right to pass the cost of onboarding to the empolyee.

      I just went through a trial at a WordPress agency and got hired at the end. I was a paid a lower freelancer rate as I had work the defined number of hours per week. I did not have a job beforehand so it was important I was getting paid a proper sallery.

      The onboarding process can improved by having good documentation. That is what I have been working on. I have seen the issues that I faced when I started and have been working to fix them for the next person that is hired.

      I would ask myself why are only 1 in every 5 people being offered a job and why is the work often discard that a person did on trial.

      Maybe the difference was that I was hired as a freelancer to do certain jobs and was evaluated for my work instead of putting hours in to be evaluated.

    • Normally I wouldn’t comment on articles like this, but because I’m self employed since a year I definitely want to share my opinion after reading this article and comments.

      I totally agree with Ulrich. Every business has these issues. It doesn’t justify the incredibly low hour rate of $25. I think there are many different ways to test if a person fits the company and to test his skillset.

      Of the dozens of people we’ve had on trial over the past few years, only one person had a problem with the trial rate.

      Has this something to do with age? Because I can imagine if you have young people on trials they’re more likely to keep silent than older (more experienced) people.

      Nobody in my network would accept a trial like this. It even feels like Ian is instructed by DB to write this article. I just can’t believe any good developer would like to do an underpaid trial.

  • Brian Rice

    This isn’t something new, so why isn’t it more widely adopted?

    Who is willing to submit to trials? People who lack confidence? Desperate? No kids? No commitments? Hm. Seems like a tool to leverage an employee.

    At the very least I would suggest a provision that says if hired on full-time, they get full compensation for the hours worked during the trial. That seems fair. That way they aren’t “paying” for their training.

    Then it would come across like: “put your money where your mouth is”, not cheap labour.

    Also asking for a salary history should go both ways. Let me know what you pay comparable positions.

    • Thanks for the suggestions, Brian. I like the idea of transparency in salary histories from both parties. Would make for a more balanced relationship at onset.

    • mbm

      Expanding on this related to salary history:

      In Massachusetts, it is now illegal to ask new employees for salary history. The reason for this is largely because salary history has contributed to the gender pay gap, and this is especially prevalent in male-dominated industries like software development.

      This will increasingly spread throughout more states (and countries) in the coming years.