I applied to a hardware engineering consultancy. They build things like bioreactors, brain stimulation systems, and arctic battery packs. A team of about twenty, almost all mechanical or electronic engineers. They needed a software engineer.
I found a Graduate Software Engineer opening that didn't require a CS degree, so I applied. Passed the aptitude test. Got invited to a video interview.
Somewhere near the end, the interviewer described a scenario. A factory makes bolts. They went into some detail about the setup, the production process, what they're looking for. I didn't have the domain knowledge to follow everything, but I caught the core of it.
My first reaction was to rephrase what I understood. "So you want an auto system to check bolts?"
Then I started reaching for what I could see. How big are the bolts? What's the lighting like on the factory floor? I'd want to visit and see the real production line before designing anything. Camera focal length matters. You'd need supplementary lighting, but not too strong. If the bolts are small, the background needs to contrast against them.
When they asked about the software side, I said I'd research first. See if similar projects exist. I don't want to start from zero without knowing what's already out there.
Honest answer. But not the right framing.
What I realised after
I couldn't stop thinking about the question after the call. Not to redeem myself. I just hadn't landed on anything solid enough to feel settled.
The question wasn't testing whether I know how bolt inspection works. Nobody expects a graduate to know that. It was testing whether I could think about it as a software engineer.
The framing I should have used: your hardware team handles the camera and lighting. I receive images. Here's what I'd build on top of that.
Image pipeline. Edge detection for dimensions. Blob detection for surface defects. A classification model if there's enough labelled data. A dashboard tracking yield rate. Alerts when the defect rate spikes. And a question back: how much human oversight do you want?
I didn't say any of that. I answered as a curious person who wandered into an engineering problem, not as the software engineer they were hiring.
The gap
Before this interview, "I don't have an engineering degree" was an abstract fact. Something I put in cover letters as a disclaimer before listing my projects.
After the interview, it became concrete. An EEE grad hears "bolt inspection" and immediately thinks edge detection, blob detection, lighting rig. They've done labs. Written reports. Seen real machines. I have to start from zero every time.
It's not that I got the question wrong. The things I said about lighting and contrast are real considerations. I asked the right clarifying questions. But my angle was narrow. I was reaching for the few things I could see, instead of working from a framework that would show me what to look for.
I looked into it afterwards. The industry has mature solutions for this: glass disc rotary tables with cameras underneath for 360-degree inspection, 3D laser profiling, YOLO models trained on defect images. Thread inspection is the hardest part because laser light scatters in the grooves. I didn't know any of this. Now I do, and it doesn't help, because the next project will be something else I don't know.
That's the real gap. Not one missing answer, but a missing foundation that compounds across every new problem.
Playground
I've been telling myself I'm ready for engineering work. I build tools I use every day. I ship code. I sleep in my car and code in airport parking lots.
But sitting in that interview, I felt like I was still in the playground. The real world was right there, on the other side of the screen, and the distance was bigger than I thought.
I don't think the gap means I can't do it. I think it means this might not be the right starting point. Maybe the first job needs to be somewhere my software skills have immediate value, where I'm not spending the first month of every project learning the domain from scratch. Then build toward the hardware side over time.
I've always been fine with challenges. I've been solving my own problems since I could live independently, and I've been wanting to solve bigger ones for other people. But this is the first time a challenge felt like it could actually break me. Not in a dramatic way. In a quiet way, where I take the job and slowly realise I can't keep up.
What changed
I'm not giving up on engineering real-world problems. I'm accepting that the path there is longer than one application.
This week I put my first project on GitHub. A dispatch bot for my airport pickup job. I started sharing what I build. Those are real. The interview gap is also real. Both things are true at the same time.