Skip to content
Log in
Team Handshake

Employee Spotlight: Spencer Miskoviak, Student Engineering

Spencer Miskoviak, an engineer at Handshake, discusses why he made the decision — just a few weeks before the beginning of fall semester — to spend a few months in California helping build Handshake’s early product.

I’m currently a third year Student at Michigan Technological University studying Software Engineering and am a Full Stack Engineer Intern at Handshake. The past two summers I interned at two different corporate companies and had positive experiences. However, throughout both I felt limited in what I could contribute and my actual impact.

The Opportunity

At the end of this past summer I was offered a co-op for a semester in Silicon Valley and the opportunity to experience the startup life at Handshake. This is something I’ve been very interested in the past few years but never had the opportunity to experience. Here was my opportunity to verify that this is, in fact, what I wanted to do and something that I would enjoy. I only had a few weeks before Fall Semester started and I already had all of my classes scheduled, a house rented and everything planned. It was a difficult decision weighing between going back to school full-time or taking a semester off and doing a co-op. I realized this was a unique opportunity and I could easily pick up school where I left off. This was a one-of-a-kind experience, and I couldn’t pass it up.

The First Week

A few hours after I was on the ground in Palo Alto I already had my first project and was investigating how to approach it. There wasn’t an elaborate orientation like my previous internships. On the contrary, it was an immediate “dig in and get dirty.” I liked it. Within a few days I had my first Pull Request open, merged and pushed to production for the main app. The projects I worked on for months in my earlier internships never saw the light of production. The culture and atmosphere were drastically different from what I also previously experienced. It was over a dozen people eating, sleeping, and working under the same roof.


I’ve had the ability to work on a large variety of projects ranging from one-off customer integrations to quality assurance to recruiting.

Handshake Specs

This started as a simple script I used locally to find flakey tests that were running on CircleCI in an attempt to cut down on flake that was in the test suite. I discussed it with Scott Ringwelski and he suggested ways to improve upon it and create an internal tool to assist all of the Engineers in cutting down on the number of flakey tests. It was an exciting project for me because it was my first full Rails app and I got to experiment with new technologies. I decided to try out React and had a positive experience. In addition to analyzing the tests in the UI, when a test failed (and still hasn’t passed) it will send a notification to a Slack channel until it gets resolved. “Handshake Specs” is now used by the team for several internal repositories that have test suites running on CircleCI.

What I learned: Rails (and many gems), React, CircleCI API, Slack API

Quality Assurance

Whenever an application continues to grow with multiple hands working on it and a user base in the thousands, quality is a big concern. I was assigned the task of quality assurance and related tasks. This includes validating new features and bug fixes before they get deployed, as well as reproducing bug reports and determining the cause so it can be moved into the development pipeline.

Reproducing bugs has been one of the most rewarding and frustrating tasks I’ve worked on. They are often very obscure and only occur in a specific scenario. I use almost every internal tool to get to the bottom of some of the more difficult bugs. I try to reproduce the bug on the Handshake Staging app by searching Bugsnag logs, browsing the audit logs, watching Fullstory if I’m lucky, open the corresponding code, accessing the staging console to directly manipulate data to setup the scenario and discussing it with Engineers. Many times the answer isn’t obvious using just one of these methods but rather a combination to stitch together the specific scenario created by the user and finding a way to make it reproducible.

What I learned: Critical Thinking, Debugging

Marketing Website

The website that was live a few months ago was a Wordpress template with outdated content and poor call-to-actions. The product and design team mocked-up a full new marketing website. I was tasked with taking the designs and creating the website. I was given very few specifications other than the mocks so I got to decide what to do for much of it. Since the website was completely static I decided to go with Jekyll after doing an earlier implementation in React. This offered the flexibility to dynamically generate the website but still host it nearly anywhere. It was even hosted using GitHub Pages for a while (but they unfortunately don’t fully support SSL). This was by far the largest website I’ve worked on from start to finish with several hundred visitors per day. I am currently still making changes on a daily basis tweaking content, adding blog posts or adding pages for different teams. Additionally, I’ve started exploring basic SEO to help improve the ranking, how the website is displayed when shared on Facebook and basic Ad Retargeting.

What I learned: Jekyll, Basic SEO, Ad Retargeting, Open Graph


Deciding to take a semester off of school and experience what it’s like to work at a startup, specifically Handshake, was one of the best decisions I have made. I’ve learned a large variety of new technologies (Rails, Jekyll, React) in addition to growing personal skills (critical thinking, problem solving, and balancing projects). Over the past few months the amount I’ve learned drastically exceeds what I would have learned in the classroom. I would highly recommend this same experience to anyone interested in startups and technology.

After all, I’ve had so much fun I’m staying for another semester.

Find the right jobs for you. Get hired.