Ever scroll through your LinkedIn feed and come across a connection whose title left you baffled about what they actually do? Or maybe, while scanning the VentureFizz Job Board, you’ve found yourself asking, “What the heck does a [job title] do all day?!”
I know I sure have, and I’m willing to bet I’m not the only one. Even though I spend my days talking to and writing about people from all corners of the Boston tech scene, many of them have roles and hold titles I know little about.
Take engineering, for example. As a marketer, my interaction with engineering is usually pretty limited. Sure, I know that engineers build stuff. But if I was hard-pressed, I probably couldn’t tell you much else, beyond a bunch of buzzwords and jargon.
A LOOK AT OLIVER'S WORLD
The son of a ceramics-turned-software engineer, Chrzan studied computer science at Cornell - but his interest in engineering started way before college. As an elementary school student, Chrzan remembers coding with his brother on their family’s Apple IIe while in elementary school. After graduating from Cornell, he took a systems engineering role at Raytheon, where he worked on the company’s stealth destroyer program.
Chrzan stayed with Raytheon for five years, but ultimately left because of the “bureaucracy and politics” that inevitably come with companies at that size. After a brief stint in D.C. at a consulting company, Chrzan landed back in Boston, ready to pursue an engineering role at an early stage startup.
Enter CarGurus. Chrzan joined the now-Boston tech superstar back in 2008 as employee No. 5. In the early days, he spent eight-plus hours each day coding - a day-to-day that’s very different than his current one.
I recently sat down with Chrzan in CarGurus’ Cambridge office to learn more about his experience, what lead him to the company, and what his present day-to-day looks like. Read more in our interview below.
Kaite Rosa: You landed at CarGurus because you were specifically looking to join an early start startup. What about that attracted you?
Oliver Chrzan: It’s about having control over your own destiny, being able to be inventive, and being able to contribute at a very high level. The main thing you get from a job as an engineer is new skills and abilities. With CarGurus, I figured the worst case scenario was that we go under in two years, and I’d learn a ton. For me, it was a win-win scenario...
Working at an early stage startup is a bit like learning a foreign language at first. There’s constantly new stuff you’ve never done before… You learn a lot about disciplines you’ve never had to deal with, and you have to be much more self reliant.
KR: When you’re hiring an engineer, what are the skills, qualities, and traits you’re looking for?
OC: We try to assess whether you [the candidate] have the ability to do the algorithms and data structures we need. If we gave you a problem and needed you to write something custom, do you have the knowledge and ability to do that? We’re not specific to a particular language. It’s more about a broad knowledge of coding and problem solving skills.
Then we figure out if you can function in our world, where we give you high level guidance on problems. I generally ask a lot of questions that are real problems we’ve had to solve here, and ask how they [candidates] would solve them, and see what they come up with.
KR: Is there a right answer you’re looking for?
OC: There are variances of wrong answers. As long as you come up with a solution that’s scalable, and will work long term, and has some kind of justification on why you think it’s right, that’s fine. We don’t always know the correct answer when we’re building something. But we have to build it in a way that, if it is correct, we can sustain it… All ideas have merit until the data says otherwise.
We have an almost mad scientist type approach to our world. We’ll do very extreme tests, like, “Let’s make this button very big to see what happens,” or “Let’s intentionally slow down the page to see how it affects people’s performance,” just to get some data and feedback on how important it is for speed.
KR: Tell me about the day-to-day of an engineer, and - if you can - explain it to me like you’re talking it to a child. Or to someone who has no idea about what an engineer does.
OC: Most of our software engineers here are full stack type developers. That means they get a project and own all aspects of it. They’re sort of a jack-of-all-trades for building stuff. Think of it like a contractor who can build the entire house themselves...
Software is generally custom almost every time, and almost all the work is during the design and planning phases. There is no actual construction, the code automatically builds the product and puts it out on the web for you. It’s all in how you plan and organize… What we build might be similar to what we built before, but it’s going to be a custom piece of work...
Engineers come in each day and what they do depends on where in the lifecycle their project is.
KR: How long is the average lifecycle of a project?
OC: I’d say maybe a week.
So, in the beginning, there’s a new project and there’s some kind of paragraph-long description of what it is and some kind of vision for it. They will usually grab a lead or a senior engineer and brainstorm. They’ll say, “OK, this is the one paragraph version, let’s go whiteboard out how it will work overall and the ideas we have for making it come to life.”
At that point, they will take the overall vision and slice it down into the smallest version possible that we can get out the door and get some feedback on…That [the feedback] can change the overall vision for things. As we get the data, we change what we think we’re going to build as we go along.
Then the developer will go off and design, code, and test their solution and push it out to the site. We don’t do any defined releases… we have the upfront whiteboarding for the initial design. And if you're a new employee there’s a code review at the end, but other than that, once it’s ready to go, you push it out the door. Everyone on the team can deploy code whenever they want to.
KR: How long is that new employee period?
OC: As soon as the code reviews don’t have much value, we loosen them up… We have people deploying code on their first day of work at this point...
People rotate projects a lot. If you have one week cycles, there’s lots of code reviews after the fact. Someone will come along and say, “I’m changing your code to do this now…” There’s sort of a feedback loop built into that because someone is going to come around and change it and iterate it and come back to you to ask about it...
KR: What about your day-to-day? What’s that like?
OC: My day-to-day is different than most of the engineers… The amount of time I spend coding is much smaller than most people, but I do spend time doing it.
KR: How much? What percentage of your day, would you say?
OC: Probably 10 to 20 percent, depending on the day. Usually, I’m doing a lot more analytics. It’s my own personal need to analyze things to figure out what to do next. If we don't have the data, I won’t wait for someone to give it to me. I will figure it out myself.
A lot of my time early in the day is looking at reports and sifting through data to figure out what’s working, what's not working, and what to do next.
KR: How much of your time do you spend in meetings?
OC: I’d say scheduled meetings are probably five to six hours per week. I probably have another seven to eight hours of ad hoc meetings. I generally like “just in time” type stuff. If we can keep decisions down to a couple of people, we can go grab them and hash it out. A lot of time, if you schedule meetings, the time is just sucked up. Like, “Well, we’re scheduled for an hour, so let’s use the hour,” when it [the meeting] could have been a five minute discussion.
I also spend a good amount of time focusing on how we scale as a team. So that’s code automation, developer operations stuff. Figuring out what the problems are that developers have an a day-to-day basis that eat up time, and how I can remove those to get rid of headaches.
KR: What are some of those problems they have on a day-to-day?
OC: Right now it's server startup time. So how quickly our code goes from nothing to loaded. If you're testing things, you’re constantly reloading stuff. There are tricks you can do in the code to speed up that process...
It’s also trying to figure out what things we need to keep an eye on continuously, so that we can scale up as a team. It used to be a joke that every new developer crashes the site at some point. So this year, I was like, “Well we are gonna hire 24 developers and I’m not willing to crash the site 24 times. So we have to go from one to zero.”
That one to zero step is actually difficult. It’s difficult to put it those controls to make sure that [crashing the site] doesn't happen in the first place. We have a lot of controls through automation, our rollback scripts, and other early monitoring systems…
The big thing I am looking for is when people add on performance problems. So, how do I set up all the monitoring in the code to make it easy to tell if someone introduced something that changed the performance of a big piece of the site….
You have to have better monitoring and understanding of what’s going on. We use a lot of data analytics to do stuff like that that. We look at metrics over time to say, “OK, has something changed over time from where I expected it to be?” That works pretty well as a catchall. If something is serious, it should affect your overall goals. If it’s not serious, it won’t. And I don’t necessarily care to catch all those things…
RAPID FIRE Q&A
KR: What time do you get to the office?
OC: 8:30 a.m.
KR: What time do you leave?
OC: 5 p.m.
KR: Do you ever work from home?
OC: Yes. It’s harder for me to work from home than it is for other engineers. I do a lot of communicating with my team and it’s just easier face to face. Everyone can work from home, but we like people to be here during core hours - about 10 a.m. to 3 p.m. But other than that, they can make their own hours.
KR: Are you a Mac or a PC user?
OC: Neither. A Linux.
KR: Coffee or tea?
KR: And do you drink it at home or when you get here?
OC: When I get here.
KR: What do you tackle first thing in the morning?
OC: I don’t look at my emails. Mornings are the quieter time and less people will be coming in to ask questions. I usually focus on organizing my own day and doing whatever analytical or interesting projects I am working on. When people starting coming in and coming to talk to me, I start checking email.
KR: When do you do the bulk of your responding to emails?
OC: I definitely do a lot of stuff on the couch once my kids are asleep. I probably send the bulk of my emails at 8 o’clock at night or right before lunch time. I probably check my email and respond to stuff two to three times a day.
KR: Do you keep email alerts on your desktop on?
OC: I don’t.
KR: What helps you focus?
OC: I’m generally pretty focused… I don’t mind noise or other distractions. As long as I have a comfortable chair and coffee, I’m good.
KR: How do you organize your day to stay productive? Do you have any hacks?
OC: If someone asks for something that will take me less than two minutes to do, I do it immediately. It will take me just as much time to jot it down to remember it as it will to do it. The easy stuff, I will knock off immediately… I don’t like to delay things.
I try to work “on-demand”, I guess. Part of that means you have to leave a large portion of your time available. As soon as you have too much scheduled, that [working “on-demand”] doesn’t work.
KR: When you’re heads down, do you listen to music or like it quiet?
OC: I don’t listen to music… If I had headphones in, I feel like I’d be telling people to stay away, and I want people to come in and ask questions.
KR: How do you deal with stress?
OC: Mostly exercise. I cycle to work. It’s about eight miles each way, and I try to do it at least three each week. I get to the gym. I like snowboarding in the winter.
KR: Are you a written note taker or do you use an app or something else?
OC: I’m a written note taker... I find once I write it down, I no longer need that piece of paper.