Some developers begin their coding career from college and it’s natural to land a software engineer position for their first job. Others, like me, were self-taught. Does the self-taught camp get rejected more often initially or do we have more street cred? Do we have more unusual stories to tell? I’d like to think so!
In college I majored in electrical engineering, which meant that I had to take a couple of computer science intro courses. They talked about C++, pointers, linkedlist and OOP. But I wasn’t interested at all. The assignments and projects felt boring.
After graduation I moved to the U.S. in 2000, right around the time of the tech bubble burst. I didn’t have a car or an Ivy League degree, so I worked in a production line of fiber optics devices at JDS Uniphase. Let’s just say I got a lot of hands-on experience … and maybe fun … cutting optical fibers with these tools. One day a manager asked if I could help modify a testing program written in C, I said sure. It turned out to be my first real life program that the operators relied on to control an Agilent (Keysight) lightwave multimeter 8163A.
My passion and my career for writing programs started from, well, a production line. It became clear that real world application of programming is so different and interesting. Two years later, I picked up basic Java while working in the IT department of a semiconductor company.
Turning points
In 2007, I decided it’s time to focus fully on software engineering. I got my first software role at Electric Cloud. I remember I didn’t do so well in the interviews – no CS background, no FAANG. One of the interviewers, surprisingly, was the TCL inventor: Professor John Ousterhout. Somehow I made the cut. And there I learned a lot of Java and software engineering practices like unit testing, CI/CD pipeline, JIRAs, etc.
Around 2013, startups were hiring like crazy. Cyphort was very interested in talking to me. The job was really scary though as it required fluency in C++ or Python, and a deep understanding of Linux. I didn’t know any of those. But I took the call, which became one of my life’s turning points that took me into the security field.
I got hooked. I ended up working at 3 more security startups. Whether it’s malware detection appliance products, container security, Kubernetes, security is fascinating to me.
Why Palo Alto Networks?
Cybersecurity, at the end of the day, makes the world a safer place. After 7 years of helping to fight the bad guys in the cyber world, I strongly believe cybersecurity is not an afterthought and should be an integral part of software development.
Most of the time, cybersecurity startups can only offer a product that is specific to certain use cases or customers. I came to Palo Alto Networks because it has a whole suite of security products – from firewalls, endpoints, incidents automation and response, to cloud native security.
Today, I am a cloud security engineer in our First Customer team. The main focus of the team is to deploy our products internally quicker, provide critical feedback to the product teams, and educate other customers. In the last year and a half, I’ve worked with 8+ different products from new Firewall capabilities, IoT security, XSOAR, to Prisma Cloud.
Do I need to write any code? YES! Sometimes I have to try out APIs from products. I did an XSOAR integration and submitted two projects to a hackathon (I actually won first place in the group project). I investigated how to integrate Vault to our Kubernetes clusters and container image scanning in our drone CI pipeline. Fun stuff!
A typical day
Broadly speaking I code, deploy our products in our IT area, and work with our product managers closely on the features feedback.
Recently I’ve been working with microsegmentation in our Prisma Cloud product. After using the product for two months, I started to code my own policy generator and a Kubernetes operator for deploying the policies in the cluster. The idea is to capture the flow logs within the cluster and recommend a basic set of policies for each Kubernetes namespace.
Aporeto ships its CLI program (apoctl) to interact with Aporeto to create ruleset and define external networks. However, you need to:
- Install apoctl whenever you need to run the program
- Configure the apoctl with an Aporeto server endpoint and a token of secret
- Manually create/delete the ruleset based on the application deployment
Instead of doing these 3 things manually, in Kubernetes you can have the operator handle this automatically. I just went ahead and studied operator-sdk for two days and completed an Aporeto operator. I showed this to the product team and they loved it and showed it to the developers. Eventually they’re going to put these features into our product roadmap. One thing I really like about my work is that I have freedom to innovate and make products more user friendly.
Some advice
If you’re thinking about becoming a software engineer, then get involved in as many projects as possible and code often. I hate to tell you the truth, coding is no different from practicing piano. It takes 10,000 hours to master something and there is always new stuff to learn, which takes even more time.
And assume people you work with are reasonable. As you build your career and go through various jobs, remember to keep a positive mindset and give people the benefit of doubt.
If you enjoyed this post and would like to explore opportunities at Palo Alto Networks, check out our open roles. You can also read more stories like this or learn about our technologies.
