What I Look for When Hiring Robotics Engineers (From a Startup Founder)

Over a year ago, I wrote a piece on How to Become a Robotics Engineer. Since then, I’ve reviewed hundreds of applications for robotics roles — and realized there’s often a big gap between what we look for and what candidates bring. Here’s what I’ve learned as a technical founder, and what we now focus on at Black Coffee Robotics.

‍

1. Long-Term Fit Over Short-Term Gains

Compound interest is the most powerful force in the universe.

I often come across profiles of candidates looking to work for 2–3 months to “gain experience” before moving on to a master’s degree or another job. There’s nothing wrong with that — but it’s not what we’re looking for.

We invest significant time and energy in on-boarding and training. We’re not looking for a quick fix or someone who’s just looking for an LoR, and some lines on a resume. We’re looking for future partners — people who want to go deep into robotics and grow alongside us.

‍

2. Initiative and Real Work > Credentials

We’ve hired candidates from a spectrum of engineering colleges —some of the best public and private universities, as well as lesser-known ones. The hits and misses have come from all kinds of backgrounds.

We don’t care about your institute or your GPA — we care about your work.

Ask yourself:

• What have you built?
• What was your role and impact on those projects?
• Is there any code we can see on GitHub?

‍

‍

Not just a raw, undocumented script — but something clean, reproducible, and ideally, used by others. Our team, for example, has been maintaining multiple open-source projects — bcr_bot, the vector_pursuit plugin, and others to name a few. More than the complexity of the code, we care about the usefulness of the code.

We don’t just deliver code — we deliver working solutions. So if your code isn’t readable or testable, it doesn’t help us. Show us your best work — document it, publish it, and share the link!

Another strong signal is initiative. At one of our previous workplaces, my co-founder (then colleague) Zubin noticed the team had no version control system in place. On his own time, he set up a GitLab instance for the entire org — not because anyone asked him to, but because the problem existed, and he decided to solve it. That mindset matters.

‍

3. Clarity Over Jargon

A common pattern in interviews:

I ask someone about their project, and they jump straight into technical jargon — which ROS nodes they wrote, what planner they used, which transformer model they plugged in.

Instead, try this:

• What was the project about?
• Why was it important?
• How did you approach it?

If you can’t explain it simply, you don’t understand it well enough.

That’s it. No buzzwords needed. Sure, it takes some practice. But in our weekly or client meetings, when we discuss individual modules and projects — we need to be able to communicate clearly and effectively. We need to explain our work to each other, and to our clients.

Communication isn’t optional — it’s critical. We need people who can think, talk, and build clearly — so we can move fast and build real systems.

‍

Final Thoughts

While a lot of career guidance focuses on technical skills, the ability to communicate, to work in a team, and to think long-term are just as important.

We’re not hiring for credentials — we’re looking for long-term thinkers, clear communicators, and hands-on builders. If this resonates with you, check out our careers page or drop us a line — we’re always looking to meet sharp minds.