Do You Need a CS Degree? (Qualities of a Successful Startup Engineer)

DC Tech Startup Insights Craig Connell

Craig Connell, CTO at STAQ, shares what to look for when hiring software engineers for high-growth startups 

Finding early technical talent for a startup can be challenging. First, you have to actively find engineers. Then you must vet the candidate to see if they can be a foundational piece at a critical stage of your growth.

How do you find people who will be able to deal with the various needs of a startup?

Are there particular things to look for in an engineer’s resume that signal they will be a good fit?

To learn more about this we talked to Craig Connell, the CTO and senior VP of Engineering at STAQ, a fast-growing startup that focuses on unifying data across the ad ecosystem, allowing companies to easily explore and surface new insights. Operations managers and CFOs at large global brands like AT&T, Warner Brothers, and Turner use STAQ to guide strategic business decisions.

Craig has led engineering teams at over 7 companies. Over time he has found the qualities that are important when trying to find an engineer that will be a good fit for your team.

The conversation below has been edited for length and content.

We talked earlier about engineers vs. developers. What’s the difference between software engineers and software developers? 

I view developers as a subset of engineers. A developer gets a task and accomplishes it as it’s laid out. When they’re asked to do a task, they lock in on it, finish it, and move to the next thing. They may or may not consider the larger view of the system they’re trying to build.

Engineers focus on the larger systems view. When they have a task to do, they consider how their approach might affect other systems and components beyond the process they’re immediately working on.

Developers are good at following directions. Engineers are good at understanding the direction and thinking of how they can execute it to the benefit of the larger system.

Can you tell whether someone is an engineer or a developer by looking at their background? Or is it something you find out through working with them? 

Sometimes you can tease it out on paper depending on how they describe their work.

However, it comes out more in conversation.

If I’m speaking with someone about their previous experience and they tell me about a project they worked on, I like to ask them why they did it that way.

If they come back with “that’s what the manager (or architect) told me,” then I would identify that person as more of a developer.

An engineer might say “That’s what the architect said. I spoke with them and they explained this is why we were doing it. I was able to collaborate.”

In discussions, you begin to hear those key indicators that they understood and participated in what they were doing.  Curiosity goes a long way.

Do you feel that curiosity is something inherent or something you can develop? 

Curiosity is a trait that people carry with them, but might not get an opportunity to exercise.

For example, a government defense contractor might have that curiosity, but it gets squashed in the culture of “we don’t ask those questions here.”

When people are given the opportunity to exercise curiosity, it might not come naturally at first. But ultimately a good software engineer will embrace it.

We see that a lot in DC. Engineers come from the services environment to the product environment where they’re given more flexibility to try and break things.

When I first started at STAQ, a lot of people came out of Betamore programs, which is a great place to learn new skills, but not necessarily where they have an opportunity or the encouragement to show their creativity. They primarily learned how to perform the tasks they were asked to do. That was a struggle for us as a small company because not all the ideas can come from the CEO or the (non-existent at the time) product manager.

I’ve found that as we’ve grown as a company, people have more intellectual curiosity and creativity. Employees are more open about coming up to me and management to offer ideas or suggestions.

You don’t have a C.S. degree. How has that affected your career in managing software engineers? 

It hasn’t held me back in my career. I see value in it, but don’t believe it’s a necessity. However, some people have very strong opinions.

There have been some moments earlier in my career where it would have been nice to be trained on things instead of being completely self-taught.

In one role, we bought another company and someone from the acquired company became my manager. He knew I didn’t have a computer science degree and asked, “why does anyone even listen to you?” He wanted to know what gravitas I had.

But my gravitas is that I’ve done this successfully for over 20 years. That’s what matters.  Real-world experience, especially in an environment where you can be hands-on, and learn by doing, goes as far, or farther than a C.S. degree. That’s something I really value about the culture I’ve developed at STAQ.

We have a handful of people here that have C.S. degrees and we might ask them particular questions. For example, newer graduates might have seen some things the rest of us haven’t.

I don’t care if people have a C.S. degree – or any degree for that matter. A degree can show an ability to learn and process information, which can be an indicator of success. But it’s not the only indicator and it certainly doesn’t guarantee they have the skills they’ll need to succeed on a startup tech team.

There was a young engineer who we hired for DevOps. He came to us as a 20-year-old who didn’t graduate high school. But he had 3 years of experience. He had a capacity to learn and could explain why he did things. He successfully worked with the team to stand up new infrastructure components, get products into production, pitch new ideas, and implement proofs of concepts to make our API more accessible. All while improving the overall process. He was a great hire.

What tech stack does STAQ use? What led you to choose that stack? 

We work in the advertising technology space. We started as a company that looked to make people’s jobs easier. Serving an ad should be an easy thing to do. It’s not. There are hundreds of partners in the middle: ad servers, supply-side platforms, demand-side platforms, verification engines, etc.

Publishers and advertisers used to spend a lot of time and manual resources connecting with all these partners to find out where they’re making money. Now they use STAQ to manage the hundreds of integrations and pull data in instead of going to each individual platform. We normalize and consolidate all of the data in one platform which enables us to provide analytics on that data.

In addition to saving companies time and money, we’re able to help them make money.

Originally, we had a primarily Ruby and Javascript-based stack because that’s what the technical founder understood well. We’re competing with government contractors and companies like Amazon. At the time, the company had the vision of building engineers at STAQ instead of hiring them out of other companies and we felt Ruby was an easier lift than something like Java.

Ruby and Javascript were great early on, particularly for the UI. Since we now work with big data and analytics, we explored other languages such as Java, Python, and Scala.

The transition for our team from Ruby to Python made the most sense since the tooling is there. Today we find ourselves using a much more diverse stack that includes not only Ruby, Python, and Javascript, but technologies such as Apache NiFi, Apache HAWQ, BigQuery, and TensorFlow.

As with other high-growth start-ups sometimes there’s a propensity to build things you don’t need to build. We faced this too.

We had to ask, “what makes STAQ unique?”

Focusing on what we did best enabled us to replace parts of our business that we shouldn’t be building on our own. We’re not going to build a database when we’re surrounded by database vendors.

The software engineering job has changed from what it was 20 years ago.

You used to build a bunch of software. Now there are so many tools and open-sourced resources. It becomes an integration job.  We still write lots of code in house, but now part of being an engineer includes deciding when and how to build new code around an existing tool, or take things and put them together.

How does a company like STAQ find engineers? 

We have a different growth pattern from what most people associate with venture-backed companies. Most people think a company gets $50 million and goes from 15 people to 100.

STAQ has raised $10.6 million over 4 rounds.

We tend to look for full-stack or integration engineers. If we don’t have an official open position, I still have relationships with companies like hatch I.T. They know they can always connect us with candidates they think are fantastic. We can sometimes make room in our budget for someone who can contribute. Even if we just hired a full-stack engineer, someone else might come along who also has key strengths we’re looking for.

When you’re a small to medium-sized company, you have budget constraints, but at STAQ we realize it’s important to always keep your eyes open for top talent.



Want to learn more about STAQ? Check out their company page to learn about their company culture, product, and more!

Interviewer: Aswin John

More Related Insights