Tandem’s apprenticeship program is a core part of our culture of continuous improvement and learning. Our most recent cohort of engineering apprentices, Jess and Caleb, joined us this January; in today’s roundtable, they chatted with our latest apprenticeship graduates, Meo and Dominic, about the coding challenge and interview process.
Why does Tandem include a code challenge in the apprenticeship application process?
Meo: A coding challenge is a key part of our hiring process, for apprentices and for all levels of our software engineer positions. It’s ingrained in Tandem’s culture to have a code challenge instead of a whiteboard assessment to evaluate each candidate’s technical ability.
Jess: The problem with whiteboarding in an interview setting is that it doesn’t replicate the conditions of an actual programming job. It just demonstrates how you would program without a computer — which is a waste of time, because when you’re actually programming, of course you use a computer and a code editor. It would be like if a culinary school application asked you to make a chocolate mousse without using a mixing bowl.
Meo: Whiteboarding is just against our mindset. It seems like cruel and unusual punishment, precisely because of what Jess said. With a code challenge, we give people a week to complete it because some people might have other responsibilities like jobs, childcare, etc. So that was one of our main criteria when we wrote the apprenticeship challenge: it had to be doable within an eight-hour timespan.
Dominic: That’s one of the benefits of doing a code challenge instead of whiteboarding: candidates feel more comfortable completing it on their own time, instead of coding in front of people.
What goes into creating the challenge?
Dominic: We brainstormed with Shamyle — who is also an apprenticeship graduate — and we brainstormed multiple challenges. We wanted the challenge to be fun and allow people to be creative, something that people would enjoy solving.
Meo: We also wanted it to be Tandem-themed. We decided to create a trivia application challenge because at the time, we were very involved with Tandem’s #trivia Slack channel. We also considered a pet walker app challenge, or an office scheduler challenge since we are currently working remotely. We ended up deciding on the trivia challenge because we thought it would be accessible and open to anyone. We also wanted to design a challenge where any programming language could be used.
Jess: I’ve done a few technical challenges and pairing interviews at different companies. I think that Tandem is unusual in that it actually is aware of where apprentices are going to be, level-wise. It seems like the hiring process is unusually thoughtful.
Caleb: That should be the standard: be thoughtful and caring. The thoughtfulness came through in the code challenge itself because I knew that even if I didn’t get the job I could use it in my portfolio.
Meo: That was also something we wanted when designing the challenge, that candidates could create something that would be useful in their portfolio even if they didn’t get the job.
How did you approach the code challenge?
Caleb: At first, I was so shocked at how vague it was, like a choose-your-own-adventure, and I felt a little overwhelmed by that because I wanted to put my best foot forward — but I had to decide which foot that was! I was excited, but nervous.
Jess: I didn’t notice at first that you had provided the trivia questions in the challenge materials, so I got excited to come up with a quiz myself. I was going to call it ‘Whodunnit?’ and it would give potential culprits as multiple choices — like, ‘the elderly dowager’ or ‘the butler’ — so the user could figure out who dunnit. But, then I saw that you had provided the questions.
Meo: We wanted to constrain the questions in case people went too off the rails!
Jess: One of the first things I learned in bootcamp is that having to come up with your own data is a pain, so it’s good that you provided the trivia questions.
The challenge itself seemed similar to some portfolio apps I had already built, so I felt confident that I could build in Rails and React. Taking user input, storing variables, creating game logic and user flow logic were all things I had done before, so I felt confident. I was mostly thinking about how I’d stand out and make it special. Tandem’s culture seemed cute and friendly, so I came up with a pumpkin spice theme.
Caleb: I really wanted mine to stand out technically. I saw how Tandem emphasizes testing, so I wanted to include an error boundary in my main game component and a 404 page to show that I think about the user experience, so if the user does something wrong they don’t see ugly errors. Though I do think code is cute! And, I also focused on providing good documentation to be sure you could get the code running.
Dominic: Caleb’s documentation was one of the highlights for me.
Caleb: I did all this work to create the challenge, so I wanted to showcase it through documentation! I even took pictures of the app and included a diagram of which component each part of my app was rendering.
I am not a designer, but I wanted users to feel good when they looked at it — so choosing between the font choices and colors was hard. It wasn’t a big issue but I was overthinking it. I was thinking “if it’s blue, will it seem sad? If it’s brown, will it seem dull?”
Jess: I also wanted to make sure the design on the front-end was watertight with no problems. I used React Bootstrap for that since it doesn’t blow up on mobile and I’ve had problems with other CSS frameworks where you have to hand-design breakpoints, and it can look awful on different screen sizes.
My biggest challenge was designing organic userflow. How would I design the logic of the game so that each time the user chooses an answer, it would move forward to the next question? Some of that I did using Hooks to manage different user logic, like a progress bar tied to a function in Hooks. I was thinking about how I might build it up in the future, so I wanted to find a way to design user logic that wouldn’t be too rigid for scalability.
What part of your completed challenge are you most proud of?
Caleb: My documentation. I love the satisfaction of wrapping up a project: I love that engineering cycle of planning, executing, then talking about what you did. It was my first time using React Hooks, so using them in this project made me feel so confident in my React skills. I was proud that I figured it out myself while looking at the React documentation.
Jess: I also developed a much greater facility with Hooks when I was doing the project. The coolest thing about moving from class components to Hooks is that class components are a much more elaborate, picky way of accessing dynamic data in the application. Hooks are more straightforward: you can set and reset the value using simple syntax. It was really gratifying to know the syntax off the top of my head and understand intuitively what I was referencing — I realized that I had been picking up this understanding over time, so I didn’t feel confused.
When the apprenticeship hiring team started reviewing code challenges, what stood out?
Dominic: As someone who is reviewing code challenges, the first thing that I look at is their documentation so that I can see how to get their applications up and running. That’s what stood out right away to me about Caleb’s code challenge: Caleb’s documentation was very clear and straightforward which made getting his application working really easy, and it was well-designed.
Meo: Both of them sought to try and learn something new with their application and documented the process in their respective READMEs: Caleb approached accessibility and error boundaries and Jess tried out unit testing. They both had amazing documentation! For Jess’ repo, they had insight on why they made the technical choices they did and provided detailed resources that helped them. That’s my jam!
Jess: I did want to make sure you could deploy it locally if you wanted to, and I wanted to include resources so any confusion was addressed. If there was something in my challenge that the reviewers didn’t understand, I wanted to provide places they could go to learn. Tutorials can be frustrating because they don’t tell you the why of each step, so if there’s a problem, you’re stuck. I wanted to give users the ability to customize their code.
Dominic: When I Interviewed Caleb, we paired together with another dev here at Tandem, Mercedes, and Caleb mentioned some of the flaws in his challenge.
Caleb: There were so many.
Dominic: Mercedes asked if Caleb wanted to pair on fixing it, so we worked on it together. That shows Caleb’s bravery and courage. It’s terrifying, on an interview call, to jump in and start pairing with people who you don’t know.
Caleb: My heart dropped! I consider myself extroverted, but I was so nervous.
Dominic: With Jess, we paired together during another phase of the interview process. When we ran into problems with something, we just Googled it like you would in a normal day as a programmer which made the interview feel very natural.
Jess: That was a little easier because it was my second pair programming session. By the time I got to the second one I couldn’t be scared anymore. Having us talk through our actual code during the interviews showed that you actually paid attention to what we were doing, were thinking about this in an in-depth way, and also it helped me analyze my process.
What advice would you give to future apprenticeship applicants?
Caleb: Think about future implementations for your challenge. I didn’t expect to actually create them, maybe just to talk about them during the interview — but Mercedes and I ended up pairing to complete one. I was the driver and Mercedes navigated, so it was nice to ask questions and she led me through how to search for things on Google and how to implement with collaboration. I felt good after we got it working during the interview.
Also, re-read the instructions before you submit your application. I had completed my challenge, I was so proud, I was about to submit, but then my spirit told me to read the instructions again. I had missed this, but I needed to add a ‘reset quiz’ button, which was a challenge requirement. So I went back and included it, but I was minutes away from submitting! I’m glad I went back and re-read the instructions and paid closer attention to the details.
Dominic: Don’t overcomplicate it. It’s cool to have all sorts of different advanced features, but sometimes our computers can have issues installing all these packages and trying to get a database running before we even run the app. There might be issues in your configurations where we can’t even get your code running.
Jess: I reviewed my existing portfolio to see what I could pull from and what features I was already familiar with. I had previously created an app that pulled from IMDB using RapidAPI to show movie info to the user and allow the user to rate movies — so that helped me think about how to approach this challenge.
Caleb: I did the same thing; I looked over my portfolio for similar projects. Super early in bootcamp I did a Vanilla JavaScript app. That code was so old and so not cute that I wanted to completely redo it, and try React Hooks. So as far as advice, it’s important to take a moment to appreciate how far you’ve come. Then go with that confidence to try new things.
Meo: At Tandem we value documentation and testing and while those things aren’t the main part of the application, we tend to look into them and they help make an app stand out. Being sincere and meaningful in your application questions, too, helps us see that you are human.
Dominic: One of our core values is Ship Quality Work, so documentation and testing shows that you share our core values.
Meo: For any job application, you should research the company, learn their mission and core values and see if they align with your own — then let that show!
Want to know when our next apprenticeship cohort is open for applications? Follow Tandem on Twitter, LinkedIn, or Instagram to stay in the loop.
