gears

Today PromptWorks is excited to welcome a new apprentice, Lydia Li, a recent graduate of the MCIT (Master of Computer & Information Technology) program at Penn.

For Lydia, this will be a new chapter in her development as a software engineer, as well as a new chapter for PromptWorks’ hiring process. In order to hire Lydia, we needed a clear plan for mentoring a new developer that aligned with our values as a company and our business model. It’s been eye-opening and we’ve learned a lot.

A look at our office, with staff hard at work
A look at our office, with staff hard at work

For some time, we have been developing an apprenticeship program to open ourselves up to the less-experienced or non-consulting talent that we already see in our hiring pipeline. We hope to establish PromptWorks, and thereby Philadelphia’s thriving tech community, as a great place to start your software consulting career through our apprenticeship program. That being said, we needed to develop a training program that would speak to the specific needs of consulting and would allow our apprentices to quickly ramp up into a standard engineer role.

We needed to develop a training program that would speak to the specific needs of consulting

We started by doing our homework. We talked with local tech firms that had undertaken similar programs to figure out how to screen, select, train, and set goals for newer engineers. We wanted to make sure that we did our best to create an environment in which the apprentice was likely to succeed and that we set reasonable expectations for ourselves. Then, based on external and internal feedback, we developed an apprentice hiring plan that reflected the nature of our work and who we are as a company.

This was a learning experience and we’d like to share some of what we discovered in making the apprenticeship program a reality.

Apprenticeship Programs are Unique

At PromptWorks, we love to learn. We give talks to our peers every Tuesday and regularly host tech meetups.

When we talked with our peers, their reasons for starting an apprenticeship program varied and they structured their programs according to their business model and apprentice skill level. For some consultants we spoke with, that meant taking on candidates with no programming experience and giving them a long time period during which to learn, without the expectation of being billable.

For our purposes, we knew we wanted to get our apprentice into a billable standard engineer role on a tighter schedule (within 3 months). That meant we would have to be disciplined and the program would require careful planning. Fortunately, we already had an office culture in place that worked to our advantage.

Learning

Collection of books in our office

At PromptWorks, we love to learn. We give talks to our peers every Tuesday and regularly host tech meetups. Our blog hosts a variety of topics, ranging from the more technical to the more professional development focus Aside from these talks and events, pairing is part of our workflow in building software. Not only do we feel that this improves software quality, we also get to constantly learn from each other and share our knowledge. That culture of learning is ideal for an apprentice since they can take advantage of it just as our standard engineers do, learning a lot in a short period of time. In addition, apprentices take advantage of dedicated study time where the curriculum is dictated by the project to which they are assigned and their own interests and aspirations.

Mentoring & Support

We value mentoring and were able to extend our existing mentorship structure to the apprentice. For our best chance at a successful apprenticeship, we decided to look for candidates with high technical and analytical ability, good communication skills, and a propensity to learn, as we thought that these fundamental qualities would put them in a position to succeed with the right type of guidance. As such, we considered it important to build some structure and support into the apprenticeship in order to facilitate professional growth. This took the form of bi-weekly check-ins with a coach and regular meetings with a mentor to help reach the goals that we set together with the apprentice.

What mentoring and support may look like for Lydia

Get Company Buy In, Build a Plan

This program started out as a grassroots initiative among the engineering staff. There was a lot of company support at the start, but we were reluctant to look at candidates until we had done our homework. We were left with a lot of questions:

  • How much should we pay them (especially if their work is not yet client-billable)?
  • What is a reasonable timeline?
  • How long should the apprenticeship last?
  • How do you screen candidates that have little professional experience to show or discuss?

We addressed these concerns within the apprenticeship committee and with the entire engineering staff to settle on a process with a viable business model that we felt comfortable with and that was also fair to the apprentice.

Hiring an Apprentice

Sourcing Candidates

We first sourced apprenticeship candidates through personal connections, local bootcamps, and the MCIT program at Penn (the same one Lydia graduated from!). We tried to take full advantage of our network to only consider candidates with a high chance of success.

Transparent Intros

Meeting with prospective apprentices

Since most of our applicants hadn’t consulted before, we invited them to the office for coffee before they began the application process. This gave us a chance to provide the candidates with a clear view of the nature of the consulting business, our hiring process, and our company values before they sunk time into the application process.

Interview Process

We designed a small, take-home coding challenge that reflected the kind of work we do and gave applicants a chance to shine. In our case, we gave candidates wonky code full of bugs, code smells, and anti-patterns that needed new features added to it. It was telling to see how many errors they corrected, and how well they implemented and tested new features. We found it very helpful to anonymize the code samples before reviewing them and would like to adopt similar anonymization strategies at all levels of our hiring process.

Since all of our engineers are client-facing, it was important to us to see how well a candidate could present themselves, as well as the code they wrote.

We did both a pair programming exercise and an interview with each candidate. We are a pair programming shop, so we wanted to assess candidates’ comfort level when pairing and their ability to communicate their ideas. For the interview, we asked the candidates to give a presentation on a technical side project they had worked on that included showing code. Since all of our engineers are client-facing, it was important to us to see how well a candidate could present themselves, as well as the code they wrote.

After our candidates had gone through the whole process, we regrouped as a committee, compared notes, made a choice, and extended an offer.

Working together at the whiteboard

Lessons Learned

One of the most eye-opening things we did was conduct a retro after we hired Lydia with all of the staff who participated in this process. Though we think we are on the right track, we found a few pain points:

  • The whole process was time consuming; it took us a year to go from research to hiring. Getting buy-in required lots of meetings and many people participated in interviewing. We are hoping this is a one-time investment, creating infrastructure that we can reuse in the future.
  • Budgeting is hard. It was difficult to know what a reasonable wage is for an apprentice, even after consulting local industry peers.
  • Hiring is hard. Having to come up with a specialized process for evaluating apprentices made us reevaluate hiring as a whole for the company. In particular, we struggled with designing take-home code challenges and in-person pairing exercises that would reveal candidates’ skills and could be completed in a reasonable amount of time.

We also saw some unexpected benefits:

  • By having so many fingers in the hiring pie, many members of the staff got their first exposure to hiring engineers and participation in making business-level decisions.
  • We identified some tools for testing command line inputs that will make it potentially easier for us to ask a candidate to complete a coding challenge in the language of their choice without relying on us for starter code.
  • Because this was a grassroots effort, many people rose to the occasion and took on leadership roles in the absence of direction. Those folks are now more involved in making business decisions and mentoring our existing staff.

We are looking forward to Lydia joining our team and seeing where the apprenticeship takes us as a company. Stay tuned to the blog for updates about the apprenticeship and Lydia’s experience.

This article was a community effort, but special credit goes to Sarah Gray, Cliff Rodgers, and Peter Caisse in authoring this.