This summer, I had the chance to get to know and support four interns at Semgrep, and I’m impressed by what they accomplished.
They worked on very different problems. Tanisha improved how our backend scales under load. Isabel built automatic Jira syncing and ended up taking a much deeper detour into product and design work. Solomon brought ideas from programming languages theory into a production codebase. Xavier built memory-profiling tools that helped us track down a customer’s out-of-memory problem all the way to a bug in the OCaml compiler.
They worked on problems important to their teams, ran into the same messy constraints full-time engineers do, and had room to follow and take ownership of interesting problems when they found them.
They each wrote about their projects in much more detail. I want to introduce the four of them, share a little of what they built, and talk about what I saw across their internships.
Cutting Queue Backlogs by 99%
Semgrep runs repository scans as background tasks on Celery queues, and backed-up queues mean developers wait longer for scan results. Tanisha Kholiya’s internship project was to improve how those workers autoscale as scan volume changes.
Our scaling was based on queue depth alone, which caused workers to scale down too far and overcorrect when a backlog formed. At its worst, customers could wait 15 minutes for their requests to be processed. Tanisha helped build a load-testing tool and quickly iterated through several scaling strategies, discarding approaches that made things worse until the team found one that worked. The final configuration reduced average backlog by roughly 99%, while also lowering pod costs by about 30% at the same throughput.
The configuration was rolled out to other teams' queues and was even applied to an unhealthy queue mid-incident to help resolve it. By the end, Tanisha was the person on her team who knew Celery queues best. She documented the approach and ran a knowledge-sharing session on it for the scan platform team.
Throughout Tanisha’s internship, she became integrated with the organization beyond just her project. She joined incident discussions, talked with people across the company, and used things like Donut chats to learn about roles outside her immediate team.
→ Read Tanisha's post: My experience interning at Semgrep
When a Starter Ticket Turns Into a Real Project
Isabel Berny’s main internship project was improving Semgrep’s Jira integration. A Jira ticket created from a Semgrep finding used to stay in “to do” in Jira even when later scans determined that the issue was fixed, leaving developers to reconcile the two systems manually.
She added automatic status syncing, along with subtasks so individual findings grouped under the same rule could be tracked separately. The feature reached beta customers during her internship, and she demoed it directly on a customer call.
One of the more interesting parts of Isabel’s summer came from what was supposed to be a much smaller starter ticket. In Semgrep, some repository tags are tied to policies that determine which security rules run. At the time, those looked just like ordinary tags, so removing one could unintentionally change what got scanned. What started as a small onboarding task grew into a tricky product problem, with Isabel working closely with the design team and iterating on how these controls should behave across the product.
This wasn’t planned as a major part of her internship. She took ownership of a tricky problem and had the room to keep pursuing a solution. It also gave her a chance to collaborate with design much more than she probably would have if she had stayed focused only on the Jira project.
→ Read Isabel's post: My Experience Interning as a Master's Student at Semgrep
When Theory Meets Production
Solomon Graf joined the Semgrep Engine team with a strong interest in doing program analysis work. In his own words, “If there is a programming languages class, I've either taken it, plan on taking it, or am angry because I didn't take it.”
His main project replaced a heuristic with a more principled program analysis. Semgrep Agentic Workflows verifies that a potential vulnerability is reachable in part by tracing a variable back to its origin. The existing pass did that by matching variable names and scopes, which produces both false positives and false negatives. Solomon implemented a reaching definitions analysis over the control-flow graph instead, so agents get a more accurate origin set while reading less code to get it.
It didn't work perfectly on the first try, because there were edge cases to handle for interprocedural analysis. In school he'd have used a more general analysis. In production, after talking it through with his mentor and other engineers, he chose a narrower solution that handled the cases Semgrep actually needed without adding unnecessary complexity. The Workflows team was thrilled to see Solomon's work.
Balancing these tradeoffs is hard to learn in a classroom, where you usually don’t have to decide how much complexity a solution is worth, who will own the code going forward, or how it fits into a larger system.
→ Read Solomon's post: Going With the (Data)flow: My Summer at Semgrep
When Internal Tooling Solves a Customer Problem
Xavier Lien joined the engine team to extend pyro-caml, Semgrep’s continuous OCaml profiler, which supported only CPU profiling at the time, with memory profiling. His project wasn’t a customer-facing feature. It was internal tooling for understanding where memory goes inside the engine. This kind of tooling would become valuable when something goes wrong, which is exactly what happened as he finished the prototype.
A prospective customer was running into an out-of-memory scan, and Xavier used the profiler he had built to investigate it. The data eventually pointed to unexpected garbage-collection behavior and a known bug in the OCaml compiler. Backporting the upstream fix brought the scan’s memory usage down about 10x and helped unblock the customer.
Xavier came in with a strong interest in programming languages and math, and by the end of the internship, he told me how much he also enjoyed performance work. The internship seemed to give him a chance to explore engineering problems he hadn’t expected to find so interesting.
→ Read Xavier's post: OOM: Out of Memory, or Out of Money? Memory Profiling With pyro-caml
What I Saw Across All Four Internships
The four internships were different, but a few things stood out across all of them.
The interns had real ownership. They each had a main project, but that didn’t mean staying inside a tightly defined bubble. Tanisha iterated through approaches that didn’t work before finding one that did. Isabel followed what was supposed to be a small starter ticket into a much larger product and design problem.
They also experienced parts of engineering that are hard to reproduce in school. Solomon had to think about where a theoretically elegant solution made sense and where a simpler production solution was better. Xavier built internal tooling that ended up helping solve a real customer problem and discovered an area of engineering he hadn’t expected to enjoy as much as he did.
Each intern had a dedicated mentor on their team, but they also had plenty of opportunities to work with people outside that immediate circle. Besides standups, kickoffs, retros, and planning, they got involved in design reviews, customer conversations, incident discussions, and informal conversations with people in roles they might not otherwise have encountered.
There were a lot of activities outside the work too! They went to a Giants game, played mini golf, had picnics and dinners, and did an escape room (where the interns beat the full-timers). Solomon told us that those outings were one of the highlights of his summer.
Applications Are Open for Summer 2027
If this sounds like the kind of summer you’d want, we’re accepting applications for our 2027 Software Engineer Internship.
The projects will be different next year, but I'm sure interns will still get interesting problems, room to learn and take ownership, and people around them who want to help them succeed.
→ Apply for the 2027 Software Engineer Internship
