View From the Ground: Onboarding at Thyme Care

Are you an engineer interested in working at Thyme Care? Or maybe you’ve already gone through the interview process and are wondering what the next few weeks will look like once you’re on the team. Allow us to introduce you to Laura Jeong, one of our talented Front-End Software Engineers. 

Coming by way of Oracle Maxymiser and Warby Parker, Laura is no stranger to the world of startup engineering. Hear from her on how Thyme Care’s team is different and what that looks like during the day-to-day: 

How we got here: First, a little bit of background on my experience in tech 

In 2017, I enrolled at an all women’s coding boot camp called Grace Hopper Academy. I was taught the NERP stack (Node.js, Express.js, React.js, PostgreSQL) with dreams of becoming a Front-End Engineer.

Fresh out of bootcamp, I joined the Oracle Maxymiser team as one of their Solutions Engineers. There, I built out different A/B/n test campaigns for the finance vertical. It was a front-end heavy, client-facing role where I would lead product demos, work with the client development team on setup/debugging, and be the first point of contact for any technical questions. It was certainly not your average engineering role. 

I decided to put myself on the market for a more traditional Front-End Engineer role in 2019. Within a month of interviewing, I secured my dream job at Warby Parker as...you guessed it, a Front-End Engineer. I was heavily involved with a new team called Vision Services, where I implemented features for Optometrists who either partnered with or were employed under Warby Parker. 

Working with the Vision Services team made me realize I wanted to be more involved with how tech can improve a provider or patient’s experience with healthcare. At that time, I felt like I was approaching a ceiling to what I want to accomplish with my career. I wanted to do more for the healthcare industry beyond just vision care, while growing my front-end engineering prowess. I started to casually entertain new opportunities, really zoning in on healthcare/ healthtech companies and their missions. During my search, I came across many different healthtech/healthcare companies but only one of them caught my eye: Thyme Care.


Making the move: A look directly inside the Thyme Care interviewing process 

One of my first conversations was with the Vice President of Engineering at Thyme Care, Rob Rodkey. The talk was one of the most glaring indications that technology was at the forefront of Thyme Care's priorities. Having worked in the healthcare industry previously as a medical assistant, I emphasized my passion to give back to the community through tech and my desire to grow to be a “kick ass Front-End Engineer.” We spoke for almost an hour. Rob highlighted Thyme Care’s mission and what the team was doing to reach milestones for each quarter and how everything would relate back to my own professional development. 

Shortly after, I was invited to a technical interview with Dan, one of the first Software Engineers on the team. I chose to do the interview in JavaScript and was able to quickly run through each prompt as it closely resembled what I was doing on the day-to-day back at Warby Parker. I appreciate when interviews showcase challenges that best reflect what you’d be doing on the day-to-day, so I had a very positive outlook on the company based on this experience.

Next up was a technical design interview with Brian, another founding Software Engineer on the team. This interview was very straightforward and less rigid than the previous coding challenge—as it looked for skills in understanding pros and cons to certain architecture decisions based on a couple of prompts. After getting to know Dan and Brian a bit more, I was certain about everyone’s passion for Thyme Care’s mission, which really motivated me. I was excited to see who else I was going to meet next! 

My next interview was a meeting with Christian, the manager of Clinical Operations and Scott, Vice President of Product. Here, I learned a lot about the member side of things. It gave me good insight as to who the main users of Thyme Care’s systems were and what priorities would be most important to the Care Team. With that, I was able to share my experiences from working with Warby Parker’s Vision Services team. I highlighted my experience working with non-technical team members and how I took their pain points and came up with solutions with my Product Manager. 

Finally, I met with Alphan, Vice President of Data Science, Bobby, Chief Medical Officer, and Robin, CEO of Thyme Care. Every one of these individuals were warm, welcoming, and so easy to talk to. They were excited to talk about Thyme Care’s potential influence on the oncology space within healthcare and shared member stories of how Thyme Care’s services positively impacted their quality of life. Another aspect of the conversation that reassured me was their commitment to ensuring their tech stack as the core foundation to make Thyme Care’s services what it is today. This is something important to me as an engineer and the fact that it was addressed really gave me a lot of hope in Thyme Care’s future. 

I had a lot of great conversations with the Thyme Care team. I was able to get a solid birds-eye view of the company and where it was headed in the coming months. Most, if not all, of my questions were answered with reassurance as to how I can meet my goals and make the most of my time at Thyme—and the rest is history.

The first few weeks: Getting acquainted in all of the newness 

I officially joined Thyme Care mid August of 2021. During the first two to three months, I learned a plethora of things, both code and healthcare related. My first week, I started learning a new framework, Vue.js, a similar framework to my good friend React.js. I also quickly realized how much thoughtfulness the team took into account when delving into different projects—how the new work would impact our main users, the Care Team, and how the problems we’re solving would be measured.

My manager, Rob, and teammates made sure I had onboarding tickets lined up that would help me get acquainted with Thyme Care’s app (Thyme Box), the general tech stack, and a bunch of resources, which helped me get me up to speed fairly quickly (< 2 weeks?!). 

Dev-environment setup was by far the easiest and most seamless experience I’ve had. My fellow teammates ensured this by creating a neat tool called Thymesaver (what a great name), which basically runs a list of commands that install all requisites (e.g. Homebrew, Pip, Git, AWS CLI, Postgres tools, etc.) needed to run Thyme Box and the Thyme Box server. This tool definitely saved a lot of time! 

One of the first assignments I was given was to improve a part of Thyme Box that helps our Care Team prioritize and manage what they're working on for our members. As the Care Team onboards more members to our program, we’ll be seeing a lot more activities (like transportation assistance or setting up doctors appointments) per member, which means a search functionality is something that will benefit the day-to-day workflow of our Nurses. I worked with the team to carve out several UI updates that would help with efficiency—pagination, a free text search, and a structured category search to help our Care Team locate any interactions they’ve had with a particular member in the past. Once released, it was so heartwarming to see the immediate impact this small project had when our Care Team began using it. 

For most, if not all, of my initial tickets, I was paired with a Senior Engineer. This was a great way to get to know my seniors, learn about their working styles, and soak in all the learnings. Each engineer I was paired with shed light on a multitude of knowledge about our apps and the decisions that went into the overall infrastructure and architecture we’re using to build our platform. 

I think one of the most exciting things about joining a startup is the opportunity and ability to contribute ideas, processes, and patterns to the overall culture of the company. Some small ideas I pitched and implemented when coming on board were: Adding pull request (PR) templates (see below for our basic PR template) and adding an architectural design record (ADR) section in our codebase for documenting our work and decisions. At my previous company, engineers relied on pull requests to provide context, specific changes, and related work/documents for the work in question—kind of like a history log of changes. Having a PR template in place helps practice these positive behaviors to ensure future engineers joining our team can have a place to start seeing the kinds of work we’ve done in the past and why. I had the same reasoning for adding ADRs to our repo—ADRs help teammates, especially those new to the team, understand what decisions have been made and why (e.g. Implementing Cypress over Nightwatch). 


Six month check: How things are feeling now that I’m settled into my role 

It’s been almost 6 months since joining Thyme Care. I’ve already gotten my hands and feet wet working across the stack and have been leading a non-formal, non-OKR related goals workshop to ensure my teammates and I are continuously learning, growing, and pushing boundaries. I’m super excited to see what’s to come for Thyme Care as we’re already stacking up so many great ideas to improve the oncology healthcare space; there’s only one direction we can go, and that is up!


Our generic .github/pull_request_template.md

Link to ticket (if not automatically linked): [XXXX]

## Main change(s)

* Add some functionality

## Ancillary change(s)


## Best Practice Checklist

- [ ] Added Github labels to this PR (bug/feature/non-user-facing)
- [ ] Created automated tests (unit, Cypress, etc.)
- [ ] Visual changes tested on Chrome
- [ ] Documentation:
  - [ ] Wrote an ADR for relevant architecture decisions
  - [ ] Updated or created READMEs for practical guides
  - [ ] Documented or communicated new/modified dependencies


## Related PRs


## Visuals (Screen-capture Video/Screenshot)


## Steps to test

1) XX (i.e., "Create a new member via the UI")



- [ ] Verified no errors in console during functionality

## WIP Checklist

- [ ] Some TODO
Previous
Previous

Growing with Kubernetes: Implementing Continuous Deployment with ArgoCD

Next
Next

Growing with Kubernetes: Why We Chose to Migrate our Apps to EKS