I did not start my career with a perfect plan.
I was born in Cairo and moved to Canada when I was 10. For a long time, I thought I would go into medicine or forensic science. Computer science was not the obvious path at first. What changed things for me was realizing that software was becoming the language through which ambitious people could build almost anything.
Once I made that switch, I became very intentional about getting closer to the center of where technology was being built.
My first internship was unpaid. I could not get a paid software role, so I worked for a Waterloo senior’s very early software project. It was not glamorous, but it gave me a starting point. From there, I kept trying to climb into more intense environments: smaller teams, then larger companies, then places where the engineering bar was higher and the pace was faster.
That path eventually took me to Whatnot, then Verkada, and finally OpenAI.
At the time, OpenAI was running its first intern cohort. I applied the day applications opened after a friend sent the link in a group chat. Because it was the first cohort, there was no established playbook. Nobody could tell me exactly what the interviews would look like or what kind of background they wanted.
The interview process surprised me. I expected deep AI questions, but most of it was classic software engineering: algorithms, system design, and behavioral judgment. The difference was the speed and intensity. The bar was not just whether you could solve the problem. It was whether you could think clearly, communicate well, and move quickly under pressure.
That ended up matching the culture I experienced inside the company.
At OpenAI, the pace felt much faster than what I expected from a large technology company. I shipped code on my first day. There was not a long onboarding period where everything was carefully explained before I could contribute. You were expected to learn quickly, ask good questions, and operate with a high degree of ownership.
That environment changed the way I thought about engineering.
Before OpenAI, I thought a lot about becoming a strong programmer. After OpenAI, I started thinking much more about judgment. In AI, especially as tools become more capable, the hard part is not only writing code or producing something impressive in a demo. The hard part is knowing what to trust, what to test, and what to question.
That is what I mean by becoming an AI-native engineer.
An AI-native engineer is not someone who simply uses AI tools to move faster. It is someone who understands how to use those tools with taste and discipline. AI can help you write code, explore ideas, summarize information, generate tests, and move through tedious tasks much faster. But it can also be wrong in subtle ways.
That means the engineer’s job does not disappear. It changes.
You still need to understand the system you are building. You still need to know when the answer looks plausible but is actually wrong. You still need to think about architecture, reliability, users, edge cases, and long-term maintainability. AI can make a good engineer faster, but it can also make an inexperienced engineer overconfident.
That is one of the biggest lessons I took from being around frontier AI.
It is easy to be impressed by a demo. The more important skill is noticing where the demo breaks. When does the tool fail? What does it misunderstand? What information was missing? What assumptions did it make? How would you measure whether it is actually getting better?
Those questions matter because AI is moving from chat interfaces into real workflows. AI systems are no longer just answering questions. They are writing code, using tools, searching through information, reviewing documents, and helping people make decisions.
That makes trust much more important.
If an AI system gives a bad answer, that is a problem. If an AI system takes the wrong action, that can be a much bigger problem. As AI becomes more capable, engineers will need to think not only about intelligence but also about reliability, evaluation, transparency, and human oversight.
I think that is where a lot of the next generation of engineering work will happen.
The industry will still need machine learning researchers, but it will also need strong software engineers, product thinkers, infrastructure engineers, security experts, and people who understand how real users behave. The models are powerful, but the surrounding systems determine whether they become useful products.
That is why my advice to students is not just to study AI in theory. Use the tools every day. Build projects with them. Break them. Compare models. Try to automate parts of your workflow. Notice where the tools help and where they fail.
You learn a lot by using AI seriously.
Earlier in my career, I was skeptical of how useful AI coding tools could be for real engineering work. Now I use them every day. The change was not that I stopped caring about fundamentals. It was the opposite. The better the tools became, the more valuable fundamentals felt.
If you understand the code, AI helps you move faster. If you do not understand the code, AI can create the illusion of progress.
That is why I still think students should study computer science deeply. Algorithms, systems, databases, networking, and software design still matter. They give you the foundation to understand what AI tools are doing and to catch mistakes when something feels off.
At the same time, I do not think students should wait until they feel perfectly ready.
A lot of my career came from taking the next imperfect opportunity seriously. My first role was unpaid. I was rejected many times. I cold-emailed recruiters. I applied early. I asked friends to practice interviews with me. I went to events. I tried to put myself in environments where I could learn faster.
Moving to San Francisco also changed my perspective. Being around ambitious builders made the pace of the industry feel real. You hear what people are working on, what problems they care about, and what skills are becoming valuable. One of my later opportunities came through someone I met in person.
But proximity alone is not enough. You still have to do the work.
When I eventually reached OpenAI, it looked from the outside like a sudden jump. Internally, it felt like a long series of small bets. Each experience gave me a little more evidence that I could operate in a more demanding environment.
That is why I try to be honest about the less polished parts of the story.
Before tech, I worked jobs that had nothing to do with AI. I had to take opportunities that were not glamorous. I had moments where I was not sure if I would break into the field at all. When I shared part of that story publicly, including work I did before entering tech, it resonated because many people saw themselves in it.
Those details matter. People often see the final outcome without seeing the uncertainty that came before it.
OpenAI taught me what the frontier looks like. But the path there taught me something just as important: progress usually comes from taking the next opportunity seriously before you feel fully ready.
For students who want to break into AI, my advice is simple.
Build real things. Learn the fundamentals. Use AI tools every day. Get close to serious people and serious problems. Practice interviewing with friends. Apply early. Cold-email when it makes sense. Do not assume that one rejection means the door is closed.
Most importantly, develop judgment.
The future of AI will not belong only to people who can build impressive demos. It will belong to people who can turn powerful technology into systems that work reliably in the real world.
That is the lesson I am carrying forward.
