WorkWritingTalksAbout Khoi Tran
writing

they hand you an ocean

they don't give you a curriculum, they give you more than you can possibly use. i wrote down every day of my internship trying to make sense of it. the thing i was actually building took a twenty-minute demo and two conversations in one afternoon to show up.

This summer i wrote down every day of my internship, at the end of the day, while it was still fresh.

Not a summary at the end of the month. actual entries, the same night, with the meetings, the names, the things i did not understand yet, and a line at the bottom for whatever carried into tomorrow. i did it for eleven weeks without once knowing what it was for.

Some context first, in case the job title means nothing to you. i spent the summer as a system engineer intern at Palo Alto Networks. a system engineer is the trusted advisor for technical solutions. not the person talking about price. the one a customer's own engineers turn to when they want to know whether the thing actually works, how it fits what they already run, and what breaks when it fails. the whole role rests on being believed, which means you sit between a company and the people deciding whether to trust it.

A Monday in late June looks like this. a deep dive on encrypted traffic with a services consultant, most of which went past me live and got understood later that night. a check-in with my manager that was supposed to be short and turned into three introductions. a first rough run of the demo with my sales partner, where we both found out how much we did not have yet. then 162 flashcards for a certification exam i would go on to fail.

Tuesday was product overview and firewall architecture back to back, and a notebook of acronyms i wrote down phonetically because i could not spell them yet.

Wednesday was five meetings and lunch standing up between two of them.

Thursday was the last day before the Fourth. i was the only intern at that one meeting, taking questions from a cohort eight rounds ahead of mine, nodding along at maybe 70 percent and writing down the other 30 to look up.

Every week was some version of that. learn something, meet someone, build something, and stay a step behind all three.

None of those days felt like they were about anything. they felt like input. i wrote them down because i had decided to write everything down, not because i thought any single one mattered.

That is the honest description of what an internship at a company this size feels like. nobody hands you a curriculum. they hand you an ocean.

There are more sessions than you can attend, more products than you can learn, more people who would say yes to a meeting than you have hours. the resources are not scarce. they are overwhelming, and they arrive without any indication of which ones matter. i think a lot of people find that paralyzing, and i understand why. it looks like abundance and it behaves like noise.

What i figured out somewhere in the second week is that nobody is going to fish for you. the ocean is the gift. the work is deciding what you are fishing for, going out every day, and keeping a log of what you caught so you can tell where the fish actually are. most of what i pulled up was not useful on its own. it became useful when i had enough of it to see a pattern in where it came from.

I liked that more than i expected to. i think i would have been miserable in a program that handed me a syllabus.

So i ended up running three things at once. a technical demo that was actually assigned, a workshop series that was not, and firewall work that came out of a real customer question. underneath all of it, certifications, a shared channel of notes for the rest of the cohort, and every session i could talk my way into.

All of it was pointed at twenty minutes.

There is a detail i left out of the beginning. i started a month late.

I had been in Japan on a study abroad trip when the internship began, so i walked in during week five of everyone else's summer. that sounds small. it is not. a month is the difference between knowing which channel to ask in and not knowing there is a channel. people had mentors already, running jokes already, a working sense of what the products were. i had a badge and a calendar with nothing on it.

Thankfully, my intern cohort is great. instead of seeing this as their competitive advantage, they actually sat down and have an hour session sharing best resources for me and the other later comer to catch up. I still remember one of the intern sent me 12 pages worth of resources, haha.

My sales partner had come in late too, which is how we ended up assigned to each other. two people a month behind, handed the same deadline as everybody who was not.

The whole summer had a target. every intern had to present a technical demo to a room of evaluators. twenty minutes each. the evaluators were vice presidents and directors, people several levels above anyone i would normally be in a room with, and they had seen this presentation given well many times before.

So i built the schedule. not because anyone asked me to lead it, but because we were the two people who could least afford to improvise. i picked the practice dates, wrote the flow, split who took which part, and then went looking for people to sit in.

That last part was most of the work, and it was not dignified. i asked countless of engineers to watch my broken demo, over and over, in hallways and in Slack, and i kept asking the ones who said not this week. the people who eventually said yes were the difference between the version we would have given and the one we gave.

Then i did something i still think was the right call. after the first live round i asked a senior leader to sit in on the second one. nobody required that. i could have run the second evaluation in front of one person and been done. i messaged him the same day and asked him to join, which meant three evaluators instead of two, and a harder room instead of an easier one. i also doubled down to run a second technical demo the day after, wild times.

I did it because feedback from a room that is already impressed is worth very little. i wanted the version where somebody had a reason to push.

I ran it seven times before it counted. 7 practice rounds with people who agreed to sit in and play the customer, then 2 live evaluations. i rebuilt the flow after almost every one. after the first full run-through, the person playing my customer told me it looked further along than he expected for someone two and a half weeks in. i wrote that in the log as sentiment and specifically noted it was not a direct quote, because i did not want to catch myself later remembering a version of it that sounded better.

The live rounds went well. i want to be honest about that rather than perform humility. a panel played a security chief, a manager, and an analyst, and the feedback afterward was specific enough that i could actually use it:

you walked it through in a very logical fashion.

— the security chief

i really like how you asked what his priorities and goals were, both short and long term, and then you tied parts of that into your demo. i think that was really strong. i also like how you use your previous experience to build credibility with a customer.

— Paul, my manager, playing the security operations manager

i liked how you kept it very conversational. it didn't feel super rigorous, which i like.

— the analyst

The night before, a senior engineer had run a full rehearsal with me, playing all three personas at once so i would have to switch registers mid-sentence. his verdict afterward was four words, and i have kept them because of how little they were trying to do:

i like it, gents.

The goals line is the one i actually trust, because it names a behavior instead of a feeling. it is also the thing i had been trying to learn all summer. ask what they are trying to accomplish before you show them anything, then make the demo about that answer.

We won it. two people who showed up a month late took the award at the end. Shoutout my partner, Dylan.

a novelty gold crown with two medals reading CEO $$$$ and Executor
the mvp crown 👑 #kingkhoi

I want to be careful about what that proves, because it is easy to tell it as a comeback story and the comeback framing is a lie. starting behind was not an advantage. it cost me a month of context i never fully got back. what it did was remove the option of drifting. we could not absorb our way to being ready, so we had to build a schedule and go ask people for help out loud, earlier and more often than anyone comfortable would have.

Being behind did not make us better. it made us explicit, and explicit turned out to be worth more than the month.

And the demo still had a problem. twenty minutes is not a length, it is a constraint, and i had prepared as though it were a length. i knew more than would fit and i had never once practiced choosing what to drop while people were watching me choose. preparing and prioritizing turn out to be unrelated skills. i had trained exactly one of them.

The correction that actually stung came from a peer, not an evaluator. i had been using internal product codenames in front of a customer. he told me to use the language the industry uses instead, and framed it as the single most important habit to fix early, before it becomes how i talk.

He was right, and it is a small thing, and i think about it constantly. internal vocabulary is a tell. it says you are talking to your company through the customer instead of to the customer.

The other thing i picked up early is where the job actually stops. the technical person advises, and implementation goes to the team whose work that is. i read that as a limit at first, something i was not senior enough to do yet. it is the opposite. someone who will tell you what to do and also do it for you is a vendor. someone who tells you what to do, tells you why, and hands you to the right team is an advisor. the restraint is the credential.

AI.

The second thing i did that summer was not assigned to me, and it started with a podcast.

Our CEO went on 20VC and said that 90% of enterprise employees are not AI savvy. he was talking about a workforce of 21,000 people, and his framing was that this is a training problem rather than a hiring problem. companies that cannot solve it, he said, end up deciding there is no redemption and cutting instead.

I listened to that as an intern who had spent three weeks watching brilliant engineers describe AI systems in ways that did not survive a follow-up question. i believed him immediately. and then i noticed nobody in my own cohort had anything structured to learn this from.

So i built it. a two-part series i designed and taught myself, for my intern cohort and then for the wider academy cohort, with my manager sitting in on both.

I had one position going in, and everything else came out of it. i was not teaching people to use AI. plenty of people were already doing that, and what it produces is a room full of confident prompters who cannot tell you why the thing worked or what will happen when it stops. i wanted to teach architecture. treat the thing as a system you design, with parts you chose on purpose and failure modes you can name, rather than a box you talk to until something usable falls out.

The first session was the landscape and the vocabulary. what an AI agent actually is, reduced to a formula you can hold in your head: a model, the context you give it, the tools it can reach, memory, a loop, and a human somewhere in the middle who can stop it. the distinction between a prompt, a workflow, and an agent, which sounds academic until you watch someone confidently call all three the same thing. we ended by having everyone design their own AI-assisted workflow with a human checkpoint built in, on paper, before touching a tool.

That design activity was really about slop. AI slop is not a quality problem you fix at the end with better wording, it is what you get when nobody decided what the system was for. so we practiced spotting it, and more usefully, practiced the choices upstream that prevent it. where the context comes from. what the tool is actually allowed to do. who checks the output and against what. the cohort left able to look at an AI workflow and say what is wrong with it, which is a different and more durable skill than being able to produce one.

The second session went underneath it. four layers, prompt to context to harness to loop, and where each one fails.

For that one i decided not to present slides explaining how agents work. i built a working one instead.

A live workbench running a phishing investigation, real requests going out and real results coming back in front of the room. two modes, so you could watch a single agent reason through tools one at a time, then switch and watch several agents split the same case up and hand work to each other. i put a cap in it so it could not spiral, which is its own lesson and one people remember better after they have seen the trace.

That cost me far more time than slides would have, and it is the only reason i understand the thing now. there is a specific and humbling gap between describing how something works and making it run. every place i had been hand waving in my own head turned into a bug. you cannot vaguely build something.

Then i had to stand in front of people who could tell the difference, and that is a second filter that catches what the first one misses. i found the soft parts of my own understanding about ninety seconds into the first question.

The CEO was right about the gap. what i did not expect is how small the distance is between not understanding something and being able to teach it, if you are willing to build the thing in between.

Then i started collecting conversations.

After the demo the shape of my summer changed. i continued attending sessions as usual and started asking people for time.

I talked to a founder who had built an AI security company early, before the category had a name, and sold it. he told me people advised them to quit in the first year. the two objections he heard constantly were whether they were a real security company and whether they would still exist in 12 months, and the second one dissolved the day the acquisition was announced.

I asked him a lot of questions that afternoon. how you create a category. how you sell something nobody has a budget line for. what he would do differently.

He kept starting with the team.

Not the product, not the timing, not the thesis. every road went back to who was in the room at the beginning. i had been asking strategy questions and getting people answers, and i did not notice the pattern until i was writing it up that night and saw the same first sentence over and over.

The other thing i took from him was not advice, it was a way of looking. he talked about product categories the way you would talk about weather systems, as things with a shape and a lifespan rather than things that simply exist. i came away thinking that most of what looks permanent in this industry is sitting in a layer that will eventually be absorbed by the layers around it, and that the useful question is not only how a thing works but where it sits and how long that position lasts.

Later the same afternoon i talked to a leader who runs the program i was interning in. he had been in the room for one of my evaluations, so this was the second time he had seen me, and the first time without a scorecard in front of him.

I asked how he decides whether someone is going to work out. he said he can usually tell inside two weeks, and that he is watching for one thing:

the pursuit of possibilities over the pursuit of excuses.

Then i asked what he most wants from an intern who comes back. i expected an answer about skills.

help us keep the culture.

I have thought about the order of those two answers more than either answer on its own. the person responsible for the culture is the person deciding who enters it, and he is screening on posture rather than skill. that is not an accident and it is not soft. culture is not a thing that happens in a company and then leadership describes it. it is downstream of what leadership selects for and tolerates, every time, and the fact that i could feel the culture in my first two weeks means somebody was deciding something long before i showed up.

And i talked to peers, which turned out to matter as much. an engineer walked me through how AI agents talk to external tools using a restaurant. the client is the waiter presenting a menu. the model is the customer ordering. the request is the order ticket. the server is the kitchen, and the kitchen is the only one holding the keys. i had read the specification. i understood it after the restaurant.

None of those conversations were assigned to me, but almost none of them would have happened either.

My manager was Paul. i want to be specific about what he actually did, because the generic version of this paragraph is worthless. when i told him i wanted to go deep on AI, he did not hand me a reading list. he introduced me to 3 people, and one of those introductions is the founder conversation above. he sat in one of my evaluations playing a customer so i would get a harder run. he made room for the team outside of work. and when i asked for feedback he gave me the kind that names a specific behavior instead of a feeling, which is the only kind worth anything.

The program around it was built, not improvised. structured sessions, real events, a cohort of us moving through it together, people whose actual job was somewhere else showing up to teach anyway. i came in expecting to be given tasks and be quiet. instead the thing was designed so that if you pushed, it moved. that is a design decision somebody made on purpose, and i benefited from it constantly.

The other half is that i asked. the introductions were offered, the meetings were mine to schedule, and nobody would have noticed if i had not. a good program does not remove the part where you have to reach.

Between.

Here is the part i did not plan.

Those two leadership conversations happened hours apart. neither person knew i was talking to the other. and when i sat down that night to write both entries, they had told me the same thing in different vocabulary.

The founder said the durable skill is understanding how models and protocols and agents fit together. the program leader said it is being able to explain how things fit together while the technology underneath keeps getting replaced. neither said depth. both said connection.

I had spent the summer optimizing for depth, because depth is measurable and it feels like progress. two people who have done this far longer than i have arriving at the same unprompted answer in one afternoon is the closest thing to evidence i am going to get.

But the convergence is not the point i want to make.

The point is that i only saw it because i wrote both of them down the same night, in the same format, in the same place. if i had kept one in my head i would have remembered a feeling. i would have said good conversation and moved on. the pattern was not in either conversation. it was between them, and it was only visible because i had built somewhere for things to sit next to each other.

That is what the notes were actually for. i thought i was recording. i was making a place where the parts could touch.

Which changes what the log was doing the whole time. i had been treating it as a record of what i caught. it was closer to a chart of where the water was.

Which is the same lesson twice, if you look at it. the durable skill is connective tissue. and the way i found out the durable skill is connective tissue was by connecting two things i had written down. the method and the finding turned out to be the same shape.

The discipline underneath all of it is honesty about sourcing.

Somewhere in drafting my own demo i had written down a few numbers that made the case beautifully. when i went back to source them, i could not. i had picked them up secondhand, they were illustrative rather than measured, and i had carried them forward without checking. nobody was going to check them for me either.

I marked them unverified in my notes and cut them from anything i would say out loud. not because i am unusually principled. because i did the arithmetic. if i use a number i cannot defend and nobody challenges it, i gain a little. if it gets challenged once, i lose the entire thing i spent the summer building, permanently, with the exact people whose trust is the whole job.

Credibility is the only asset here that does not grow back.

I run the same rule against myself in the log. exact quotes and my impression of how something felt live in separate sections, because the moment those blur i start remembering a flattering version of events. the record is only worth keeping if it is allowed to disagree with me.

It disagreed with me plenty. i failed three certification attempts in a single week. that week is in the log next to two of the best demos i gave, in the same handwriting, which is more or less the correct picture of what any given week actually contains.

Where this leaves me.

I graduate next Spring, and i have never been more excited about this field than i am right now.

Part of that is timing. i spent the summer inside the security problems that AI is currently creating, in a company that has to answer for them commercially, next to people who were building in this space before there was a name for it. that is an unreasonable seat to get as a student.

But most of it is the lifespan idea, which i find thrilling rather than discouraging. if the specific thing everyone is building toward has a shelf life, then betting on any single product is a bad bet, and the only durable position is being the person who understands how the pieces fit together while the pieces keep changing. that is the same connective tissue answer, arriving a third time, now as a career decision instead of an observation.

It also means the field is going to keep being new. i do not think i could have said that about most industries at 21.

The notebook is still open. i am still out on the water most days, and i have stopped expecting anyone to tell me where to cast.