Software Engineering Internship at a Private Equity Firm – No Tech Team? No Problem

A note from TFP:This dossier is a submission from one of our subscribers, who shared their own journey into this software engineering internship. We've edited and re-organized their original piece to make it easier to follow and a better guide, while keeping their experiences, opinions, and voice intact. It's June 2026. I've just accepted an internship at a private equity firm calledSamara Capital. I tell my friends about it and they nod politely, the way you nod when someone tells you they're doing something with 'capital markets,' which is a phrase that makes everyone's brain immediately go into airplane mode. And look, I get it. 'Investment firm' sounds like a place where people in slightly-too-tight suits yell 'SELL, SELL, SELL' into three phones at once, veryWolf of the Wall Street. Instead, on day one, I found out something that changed my entire trajectory of my summer. Well, it turns out that Samara Capital did not have a tech team. At all. Not 'a small tech team.' Zero people whose job was to build software. Which meant that for a few months,I was the tech team.A tech team of one girl who, three weeks earlier, did not know what a 'cap table' was, in a private equity firm. Subscribe now I found this listing the way every opportunity in the modern world is found now — on LinkedIn, at 11pm, while scrolling past 17 posts from people announcing they werehumbled and gratefulto be joining so many cool companies (yay!). Although I think this applies to any job application in general, having relevant projects and experiences in your resume is the biggest help. I already had experience as an AI Intern and had projects in that same space. Of course, you don't have to make sure it matches the job requirements/the company's work ditto. Ideally, you've done the work that catches their attention because, well, that's why you applied. I had no projects related to the kind of work the company primarily does, but some of the tech stack matched, and my previous role matched to a good extent. I think for a relatively smaller company, a resume like mine would get noticed without a referral/perfect ATS tuning (now if you were applying to a company witha lot ofemployees, it's a different story). I went through a few rounds of interviews, and they were a mix of technical and non-technical conversations. There was no traditional 'engineering interview loop' because, well, there was no engineering team to run one. There was a coding component, but it wasn't just the usualLeetCode pass the test cases type.They wanted to understand how I approached problems, how I thought through a solution, and whether I could actually write code rather than just list technologies on my resume. When you're the only technical person in a company, being able to build something is only half the job. You also need to be able to explain what you're building to someone who isn't going to review your pull request later. And that brings up the obvious question: if Samara didn't have a tech team, who was actually judging whether I was technically good enough to hire? The answer was the people who would ultimately have to trust me with their problems. The interview process involved people from the business side of the firm, including the people who understood the workflows I would eventually be working on. They were trying to figure out whether I could take an ambiguous problem, understand it, break it down, and build something useful without needing someone to tell me exactly what to do at every step. That changed how I thought about the interview. I had spent most of college preparing for the idea that engineering interviews were about proving I was technically strong enough. This one was partly about that, but it was also about proving that I could be trusted with technical ownership of an entire firm. When you're interviewing for a software engineering role at a company with a large engineering organization, you have a predictable pattern. You know there will be coding questions, system design maybe, some resume grilling, and maybe some behavioral rounds. You can spend weeks preparing specifically for that company's interview process. I didn't have that luxury here. Samara wasn't a tech company, and this wasn't a standard software engineering role. There wasn't a huge archive of interview experiences online telling me exactly what to expect. So I prepared in the only way that made sense: I focused on understanding my own resume extremely well I revisited the projects I'd built I made sure I could explain not justwhatI'd built butwhyI'd made the decisions I had. I also spent time understanding Samara itself and getting a basic sense of private equity, (because I figured there was no point walking into an investment firm and talking exclusively about React and Python). That last part turned out to be, in fact, very important. I just needed to know enough to understand what kind of company I was talking to, what private equity actually does, and why a firm like this might want someone with a technical background in the first place. In retrospect, the preparation was more about getting comfortable with uncertainty. I knew the technical questions would be manageable. What I couldn't predict was the question behind the question: If we give you a problem that nobody here has already solved, what are you going to do? What they actually asked me, over and over, in slightly different phrasing each round, was some version of: How do you feel about working on hard problems by yourself? And then, right after that: How do you feel about a fast-paced environment? In hindsight, I understood why those were the only two questions that mattered. They were hiring someone tobethe safety net, alone, at a pace that doesn't wait for you to feel ready. Every other interview question is basically a proxy for 'can you do the job.' These two questions just skipped the proxy and asked directly. I was hired because someone at Samara looked at the firm and thought, 'we have a lot of manual, repetitive, error-prone work happening in Excel and email, and we probably should not be doing that in 2026.' So the pitch, essentially, was: come build the internal tech stack that doesn't exist yet. If you are enjoying reading this dossier, you can show your appreciation and help keep the work going. Support TFP Before I explain what I actually did all day, there's probably a more basic question worth answering: Why does a private equity firm need a technical person in the first place? A private equity firm invests in companies, which means deciding where to invest, figuring out whether a company is actually performing well, and keeping track of what happens after the investment is made. Financial models. MIS reports. Due diligence documents. Market research. Internal reports. The list goes on…… And a surprising amount of that information lives in places that were never designed to work together. An investment team might have one set of numbers in an Excel file, another set in a monthly report, supporting information buried in a PDF, and some crucial context sitting in someone's email inbox. None of this is inherently a problem, people have been running businesses this way for years. But it creates a pretty obvious opportunity for technology. The goal was to take workflows that involved a lot of repetitive searching, reading, copying, comparing, checking, and reporting, and figure out where software could make those workflows faster, more reliable, or simply less painful. Sometimes that meant AI. Sometimes it meant building a dashboard. Sometimes it meant automation. Sometimes it was just writing the piece of code that meant someone no longer had to do the same thing manually every Monday morning. And that distinction became one of the biggest lessons of the internship: Being a 'tech person' didn't mean putting AI everywhere. It meant understanding a problem well enough to know whether it needed AI at all, or something completely different. That also meant my work could touch pretty much every part of the investment lifecycle, from sourcing and evaluating potential deals, to diligence, to monitoring companies already in the portfolio, to internal reporting and day-to-day operations. (Spoiler: There Was No 'Typical Day') Someone might tell me that a particular process is taking too much time. Or that a team is manually putting together the same report every month. Or that information is scattered across several places and people keep having to look for it. Or that there should be 'an AI agent' for something. The common template was:figure out what needs to exist, and then build it.Here's roughly what that turned into: AI-powered tools and dashboardsto support the investment team, including automating parts of portfolio monitoring that were previously manual. Prototypes and AI agentsfor sourcing, diligence, reporting, and internal knowledge management. Basically, handling the 'read a lot of dense material and extract the important thing' work so a human doesn't have to start from zero every time.The first pass, hehe. Internal platforms and automationsfor the firm's day-to-day operations, like collecting information, updating records, preparing reports, and moving work between teams without endless email chains. The boring stuff that becomes very noticeable once it stops being boring. The company website and internal digital platforms, because it turns out 'the tech guy' also becomes 'the website guy' by default, and I have made peace with that. One of the more interesting problems I worked on started with something that sounds deceptively simple: reviewing financial models. For context, financial models are a huge part of how investment teams work. They're usually complex Excel workbooks with interconnected sheets, assumptions, formulas, historical data, projections, and a lot of numbers that need to make sense together. Reviewing one manually can mean going through the workbook, checking formulas and assumptions, comparing figures across sheets, and trying to spot inconsistencies or things that deserve a second look. The problem it was time-consuming, repetitive, and very easy to miss something when you're staring at hundreds of cells. The goal was to: Inspect the model Identify things that looked unusual or potentially problematic Surface them in a way that made the human review process easier The important part was that I wasn't trying to build a machine that declared a financial model 'correct' or 'incorrect.' That would be both unrealistic and a terrible idea. The tool was there to surface things worth investigating, and let the investment professional make the final call. It was a good example of where technology actually fits into finance: not replacing the person with the domain expertise, but taking away some of the work that prevents that person from spending their time on the parts that actually require judgment. Another thing I worked on was tracking what was actually happening inside the internal platform. Once a platform starts handling different workflows, automations, dashboards, and AI-powered features, there's an obvious question that becomes increasingly important:when something happens, how do you know what happened, when it happened, and what caused it? I worked on building an audit trail and activity tracking system. The idea was to create a useful record of important actions enough that someone could look back and understand what happened without having to reconstruct the story from application logs, emails, or memory. I had to spend time deciding what was actually worth tracking and how to make the system consistent across different parts of the platform. An activity from one module shouldn't look completely different from an activity in another, and the information had to remain useful even as new features were added. A major learning for me here was that software isn't finished when the feature works. You also have to think about what happens when something goes wrong, how someone investigates it, and how you make the system trustworthy enough for people to rely on. The interesting problems weren't always the ones that sounded impressive when you described them. Sometimes they were the problems that made everything else work a little better. The amount of ownership here was, frankly, a little absurd for an internship. If something I built was bad, it stayed bad until I noticed and fixed it. If something I built was good, it went straight into how the firm actually operated. I did have people I could go to, though. The investment and operating team members I was building for became my de facto product managers: they helped me understand why a workflow existed, what actually mattered to them, and perhaps most importantly, whatnotto automate. That distinction turned out to matter a lot. I could figure out how to build something; they could tell me whether it was worth building in the first place. There wasn't a formal technical manager telling me exactly how to approach every problem, so a lot of the mentorship came from learning to ask better questions and getting feedback directly from the people who would actually use what I built. Found this dossier useful? Share it with someone who will benefit Share To actually do any of this, I had to learn thebusinessside fast. Samara gave me resources to get up to speed on investing and private equity fundamentals before I could even understand what problems I was supposed to be solving. Which was its own kind of whiplash: most tech internships hand you a codebase and a Jira board. Mine handed me a reading list on deal structuring and said 'come back when you understand what a due diligence process is, then we'll talk about what to automate.' Another piece of learning: you cannot build a good tool for a process you don't understand. Every one of these posts eventually stops being funny for a second, so let's get that part out of the way. No tech team meant there was no ceiling on scope, because nobody had told me where the boundaries were yet. If something was manual, inefficient, or unnecessarily complicated, it was potentially something I could try to fix. That could mean a small automation one day and something much bigger the next. When you're working without an established technical team, that becomes even more important. There isn't someone maintaining a perfectly prioritised backlog of every technical problem in the company. You start noticing patterns yourself: the same manual step appearing in three workflows, the same piece of information being entered in multiple places, the same person answering the same question repeatedly. Which part of the process is actually slow? What information does the user need? What should be automated? What shouldn't be automated? What happens when the data is incomplete? How do you know whether the thing you built is actually better than what people were doing before? Those aren't really coding questions. They're product questions, business questions, and sometimes just common-sense.And I had to learn to be comfortable not knowing the answer immediately. There was definitely a version of me at the beginning that thought,I'm a computer science student. What am I doing in a private equity firm? I wasn't an investment person. I didn't come into the internship knowing how every part of a deal worked or understanding all the terminology people casually threw around in meetings. But 'I don't have the domain expertise for this' was just the first problem to solve. I started learning the terminology. I asked questions. I read about how investment teams actually worked. I paid attention to why people were doing things a certain way before trying to automate them. And eventually, things that sounded completely foreign at the beginning started making sense. You can learn a surprising amount of finance when the motivation is very practical: if I don't understand this process, I'm probably going to build the wrong thing. You need to be willing to become knowledgeable enough to build something that is actually useful. And this goes for any industry you want to work at. Subscribe now If you're heading into something similar, ie, a small or nonexistent tech environment inside a finance or investment firm…a few things actually helped me get up the learning curve fast: Aswath Damodaran's introductory valuation material: particularly useful for getting comfortable with how investors think about companies, valuation, and the numbers behind an investment thesis. Wall Street Prep's private equity and financial modeling guides: helpful for decoding the vocabulary and mechanics that come up constantly in investment workflows. The actual internal workflows I was building for: honestly, the most useful resource was sitting with the people doing the work and asking them to walk me through what they were actually trying to accomplish. Learn the tools already being used in the environment, than trying to introduce a new framework just because it was trending. Not really, or, more accurately, not in the way most people picture it. I'm sure most other trading firms could be different, perhaps with dedicated teams for every task. But this, it wasn't a trading floor and it's not a hackathon. It was closer to being handed a business with genuine, unglamorous problems and a surprising amount of trust, and being told: you're the only technical person here, so whatever gets built, gets built by you. That's terrifying for about a week, and then it's the best professional experience I could've asked for.. If you're a CS student who wants to become a better coder, this probably isn't the most conventional internship. If you want to learn how to find problems, talk to users, understand a business, and take a vague idea all the way to something people actually use, I'd choose this again in a heartbeat. Fuel the Next Dossier Further Reading: Equity 101 for Software Engineers TFP Dossier #5: Getting into Product Management TFP Dossier #2: Research the Company You Are About to Join The Private Equity Glossary TFP Dossiers are part ofThe First PassKnowledge Library — a collection of evergreen resources for students and early-career professionals exploring careers in startups and tech. While regular TFP issues help you discover opportunities,Dossiershelp you understand the culture around them: hiring, startup culture, compensation, networking, founder outreach, and everything else you don't get taught formally. Got a topic you'd like us to cover next? Reply to this post or reach out. Some of the best Dossier ideas come directly from readers.