Dear Recruiters

Hi — I'm Zahir.

If you're reading this, there's a good chance you found my website while looking through my background. Instead of writing another version of my resume, I wanted to share a little more about what I like to work on, how I work with people, and what I've learned along the way.

I update this document every few week, so feel free to come back every now and again to see what I have been up to!

I Like Building Things People Actually Use

A lot of my work has started with a pretty simple question:

"Why are we doing this manually?"

At Gentoro.ai, I'm currently working as an AI Engineer on a recruiting workflow that automates parts of the sourcing and screening process. What started as a small prototype has grown into a production system that sits in front of a client's ATS. The system takes in job postings and candidate data, searches a large résumé corpus, helps draft recruiter outreach, and evaluates candidate responses. Under the hood, it uses a combination of traditional filters, hybrid search, LLMs, and agentic workflows.

I've worked on everything from the ingestion pipeline and API integrations to the retrieval and evaluation systems. As the project grew, I also started working more closely with teammates and clients — figuring out what was actually useful, what wasn't, and what we should build next.

That last part has probably been one of my favorite parts of the job.

It's easy to get excited about a new model or framework. It's harder, and usually more useful, to sit down with someone who will actually use the software and figure out what they need.

You can read more about the project in my Bullhorn Agentic Dashboard post, or try the live demo.

I Like Working With the People Behind the Problem

One of the things I've learned from working on real projects is that the technical problem is rarely the whole problem.

During my internship at Onto Innovation, I worked with optical engineers who were analyzing interferometer data for lens comparisons. Their existing process involved manually comparing datasets and could take more than two hours for a single analysis.

I built a visualization tool that brought the process down to about five minutes.

The technical part was fun, but what made the project work was spending time with the engineers who would actually use it. I had to understand what information they cared about, what they were looking for when comparing results, and what would make the tool useful rather than just technically impressive.

After presenting it to senior engineers and leadership, the framework was approved for broader use across engineering teams.

That experience stuck with me. I like building software, but I especially like building software with the people who are going to use it and think "Man am I glad we have this!"

I Enjoy Explaining Things

Before I started working full-time as an engineer, I spent a lot of time teaching.

While studying Computer Science at Occidental College, I worked as a CS tutor and instructor. Across those roles, I worked with more than 100 students and spent 150+ hours teaching Python, Java, C++, algorithms, and debugging.

Teaching is probably one of the best things I've done for my communication skills.

You quickly learn that knowing how something works isn't the same as being able to explain it. Sometimes you need to start with the big picture. Sometimes you need to draw it out. Sometimes the person you're helping just needs someone to sit with them while they work through the problem themselves, and I try to bring that same approach to engineering.

If I'm working with another engineer, a recruiter, a client, or someone who doesn't write code, I try to meet them where they are rather than assuming everyone sees the problem the same way I do. I feel like teaching otheres has taught me that sometimes having less domain knowledge allows you to approach problems from different views that others may have not been able to see.

I Like Being Around People Who Build Things

I'm at my best on teams where people are comfortable asking questions, bouncing ideas around, and figuring things out together.

I don't expect to have the right answer immediately. I'd much rather have someone challenge an idea early than discover six weeks later that we built the wrong thing.

I've been luck to have the opportunity to work closely with teammates and clients across the various jobs I have had. Those conversations that we had in team huddles and product demos have changed the direction of things I've built more than once. I've learned to appreciate that.

A good engineering team isn't just a group of people who can write good code. It's a group where people communicate, help each other, disagree constructively, and care about the outcome.

That's the kind of team I'm looking for.

I Still Like Getting Into the Technical Details

The people side is important to me, but I wouldn't be doing this if I didn't enjoy the technical work. I like taking a messy problem and figuring out how the pieces should fit together. That might mean designing a FastAPI backend, figuring out how to structure a LangGraph workflow, debugging an API integration, tuning retrieval, or figuring out why something that worked locally is suddenly unhappy inside a Docker container.

I've learned a lot by building things that didn't work the first time.

I usually start simple, get something working, and then figure out where the real problems are. From there, I'll worry about things like performance, reliability, observability, and scaling. I don't think every project needs a complicated architecture. Sometimes the best solution is the boring one.

Some Things I've Built

Bullhorn Agentic Dashboard

This is the project I work on at Gentoro. It started as a prototype and has grown into a larger agentic workflow for recruiting. It handles candidate sourcing, résumé matching, outreach drafting, and candidate reply evaluation while keeping a recruiter in control of communications. I built the first version end-to-end and later worked with teammates as the project grew. There's a live demo with fictional candidates and the source is available on GitHub.

Candidate Database

This one started with a conversation. A friend working at a local VC firm mentioned that his team regularly met strong candidates who didn't have an immediate role available. Those candidates could easily get lost once the conversation was over. I thought it would be interesting to build something that could help solve that. The result was a small candidate database with a React frontend, FastAPI backend, Postgres + pgvector, traditional filters, and a chatbot that lets you search candidates using natural language.

The interesting part wasn't really the technology. It was taking something someone mentioned in conversation and turning it into a working prototype.There's no word yet on whether they'll actually use it, but that's part of the fun of building things outside of work.

What I'm Looking For

I'm interested in roles involving:

AI engineering
Backend systems
Applied machine learning
Developer platforms
Infrastructure for intelligent systems

More than a specific title, I'm looking for a team where I can build, learn, and work with good people. I want to be around engineers who care about doing good work, people who are willing to teach each other, and teammates who don't take themselves too seriously. I'm still early in my career, so I'm looking for somewhere I can take on real responsibility while continuing to learn from people who are better than me.

If You're Hiring

Thanks for making it this far. If you think I could be a good fit for your team, I'd be happy to talk. You can reach me through the contact tab on this site.

And if you're not hiring right now, that's okay too. I'm always happy to meet people working on interesting problems.