When Kye Lindholm started researching coding bootcamps, he was drawn to our Intermediate Coding Bootcamp for its efficiency. It’s our shortest program, just 12 weeks, and our most immersive in terms of schedule. But he wasn’t intimidated by the prospect of long hours. Coming from the world of fine dining, he was used to long shifts that required high-level focus on every last detail.
In this Q&A, read about Kye’s experience in the program, the advice he has for incoming bootcamp students, and what he’s up to now as a Site Reliability Engineer at the background check company Checkr.
What inspired you to make a career change to software engineering?
Before I enrolled at Hack Reactor, software engineering, and programming in general, were things I had been interested in. I grew up playing video games and I guess that’s what initially spurred the interest. Through high school, I took programming classes and even went into college intending to major in computer science, which I ultimately didn’t complete. Eventually, I used Hack Reactor as a pivot point into the world of tech.
That’s all to say, although software engineering wasn’t my career path until pretty recently, I’ve been interested in the world of programming and software engineering for a good while.
Why did you choose the Intermediate program specifically?
I came from the world of fine dining and restaurants, so the long hours of the Intermediate program weren’t a deterrent for me. I know that was a hurdle that a lot of others had to overcome and get used to, but for me, it was a transition from 14 hours on your feet in the kitchen to 12 hours in the chair. It wasn’t too bad.
Ultimately, I chose the program because I wanted a quick turnover. I wanted to pivot into the industry, start the job search, and get all that started quickly.
What did you get out of your time in the program?
Definitely a good number of technical skills. As I mentioned, I had something of a background in programming before enrolling, but it was buried under years of not practicing, so it was definitely good to dust off those skills and build upon them. I hadn’t had a ton of explicit experience with the particular languages and frameworks and tools that we used in the program, so I had a lot of technical learning.
I also got some insight into working on a team in a tech, programming, and software engineering context. It was a useful experience to undergo such a rigorous program with a bunch of other people who were doing the same thing, as we’re all making presumably big pivots in our lives together. It built a lot of comradery and trust, and we could lean on each other.
You’re now at Checkr, working as a Site Reliability Engineer. What’s your role like and what types of things are you working on?
A Site Reliability Engineer (SRE) was not a job title that I knew existed when I started my job search, so it definitely wasn’t something I was explicitly looking for. But it aligns well in terms of there being a good amount of software engineering that goes into the role’s day-to-day. We code, to an extent, but the role also draws in a lot of DevOps principles. We really focus on observing the product and ensuring everything’s running smoothly, rather than building the product itself. At Checkr specifically, an SRE also runs incident command, so when something breaks, we orchestrate the fixes.
My personal day-to-day involves a lot of scripting and automation, not for the product, but for internal processes, which I love. It’s a lot of smaller but potentially very impactful projects. As a whole, SRE was a really wide entry point into the industry because there’s one SRE team at Checkr, and we have access to the whole product. We can look at everything and contribute across the board, and we work with every engineering team within the organization.
You mentioned aspects of the role you enjoy. Anything else to mention? And then, what about any challenges you’ve faced on the job so far?
Overall, I like what SRE offers, because we have such a wide span of influence within the company. You can pick projects or things to work on from different parts of the company. I focus on automation, but some people are more focused on things like observability or CICD pipelines. Our responsibilities run the gamut, so you can pick and choose what you want to do, or maybe your manager will, depending on the quarterly goals. There’s a wide variety of things to do in my role. Also, I love the team I’m on. I love working with the people I work with.
As for challenges, or things that were hard to adjust to, this is definitely a role that I hadn’t even known existed before getting the job. It comes with a wide array of responsibilities, so I guess that’s both a plus, as well as a growing pain, especially at the start.
Do you work on-site, remote, or some combination? How’s the work environment for you?
I work entirely remotely. Checkr has two offices, one in Denver and one in San Francisco. I’ve been to both, which is nice. Usually twice a year, we have on-site events with our team, and then maybe some bigger company-wide events, which are good for team building and just pal-ing around, but we also get some work in, too. In a way, I’ve experienced the in-office work culture a little bit, but my day-to-day is entirely remote.
You mentioned your experience in the food industry. Has there been anything from your former career that you’ve been able to pull into software engineering?
Yes, there’s actually a ton of overlap. The technicalities of the industries are different, obviously – I’m not chopping onions for a living at this job. But many things, aside from the technicalities, are very similar. Both industries are super problem-solving and decision-making oriented. Both industries place a high level of importance on efficiency and not wasting things, like time or resources. I was super pleased to find out that there’s a ton of overlap between these two industries.
Do you have any advice for incoming students who are about to start day one of the bootcamp?
I think the people who are deciding to make this transition are people who are obviously willing to learn, and I think everyone knows themselves best. It’s good to take any advice you get to heart and to consider everything you’re told from people who have more experience than you. But at the end of the day, you know yourself best, you know how you learn best and most efficiently. So I’d say be sure to trust yourself as you go through this process.
