Nic Wong: From Formation Fellow to Mentor

Welcome to Formation’s Mentor Spotlight, a blog series designed to introduce you to our dedicated and experienced network of program Mentors. Today we’ll meet Nicholas Wong, a Software Engineer at Meta. Nic studied law before finding his passion for engineering, and he was a Formation Fellow before joining us as a Mentor. Hear about his journey—from Oxford student to Meta software engineer—and why he’s passionate about Mentoring our Fellows.

What is your educational/professional background prior to Formation?

I grew up in Singapore and attended college at Oxford. During school, I studied law and thought I’d possibly become a lawyer one day. However, I had a change of heart after a summer internship at a law firm. I realized I didn’t want to do law for the next 40 years of my life. It didn’t make me happy, and I kept thinking, “There must be another path.”

I asked around and spoke to some classmates who went down the tech path. That’s when I decided to go back to school. I attended Columbia where I earned a Master's in Statistics. After grad school, I briefly worked at Bloomberg as a Data Analyst. I got a chance to work closely with the software engineers there and realized that all the things that caught my attention were actually in engineering. I researched companies that could help me make that leap into engineering, and I found Buildschool (which is now Formation). I took the leap. At Buildschool, and specifically with Sophie, I learned the fundamentals of how to be a great engineer. I ended up finishing the Fellowship and getting my first job as a software engineer at CoinTracker where I worked on crypto tax software.

Mentoring helps me solidify concepts to myself as I’m teaching them to others.

What motivated you to become a mentor at Formation?

While I was in grad school, I tutored middle school students in math. It was so rewarding to see that spark when they understood a concept. I also helped mentor the next group of Buildschool students after I completed the program. Both of these experiences were extremely fulfilling, and I knew I wanted to continue teaching others.

Along with the rewarding nature of mentoring, I also find that it’s a lot easier to understand a topic yourself if you can articulate it in a way that’s understandable to someone else. Mentoring helps me solidify concepts to myself as I’m teaching them to others.

A lot of times people just need a little tiny nudge to understand a concept, and the teacher can make all the difference.

Where else have you mentored?

I’ve always wanted to help people understand things. In high school, I tutored students who didn’t have solid English skills. I wanted to help them get on a level playing field.

A lot of times people just need a little tiny nudge to understand a concept, and the teacher can make all the difference. Some people get left behind—not because they’re less intelligent, but because they need a specific explanation for their idiosyncratic way of learning. So, having that 1:1 mentorship can help you tailor their experience and accelerate their learning.

The point of the technical interview is to show your problem-solving and communication skills and demonstrate how you work with other engineers to iterate until you have a working solution.

What are some of the most common mistakes you see engineers make?

I think the number one mistake people make is treating an interview like an exam rather than a collaborative exercise. I see too many engineers with the mindset of, “Ok, it’s like I’m sitting in a classroom with a pen and paper trying to solve a math problem on my own.” But a technical isn’t a solitary problem; you should be working with your interviewer on your problem. The point of the technical interview is to show your problem-solving and communication skills and demonstrate how you work with other engineers to iterate until you have a working solution. It’s there to simulate an actual work environment. It’s important to communicate what you think even if it’s not a complete working solution, communicate which direction you’re going in, and what you think a high-level solution looks like.

The second common mistake I see is people jump into coding right away without understanding what the problem is. It’s like starting construction on a building without a blueprint! You have to act like an architect and weigh the pros and cons of each “building design” before beginning to code.

The strongest engineers I know are able to look at systems when things are going wrong and eliminate possible hypotheses on why they’re going wrong.

Can you describe the strongest engineer you know and name some traits that make them such a strong engineer?

I’m thinking of three separate engineers who all have many things in common. All of them get things done productively and deliberately, break problems out into subproblems, and map concurrent trains of thoughts into a larger project. The strongest engineers I know are also able to look at systems when things are going wrong and eliminate possible hypotheses on why they’re going wrong.

The whole point of the Fellowship is to help you gain the skills you’re not confident about. Everyone in the community is here to help.

What does your role look like working with Fellows at Formation?

Right now, my primary role is hosting mock interviews to help Fellows prepare for coding interviews at large tech companies.

What kinds of engineers would you recommend to join Formation and why?

Anyone who is ambitious, motivated to learn, and interested in leveling up their career—whether that means getting a raise, working at a company they find more suitable, or just up-leveling their skills in general.

Do you have any advice for new Formation Fellows?

My main piece of advice is don’t be afraid to ask questions and don’t bottle in your doubts. The whole point of the Fellowship is to help you gain the skills you’re not confident about. Everyone in the community is here to help. Ask questions if you’re not sure; there are no dumb questions.

Don’t think about your education or past as something that holds you back; think about it as an opportunity to learn something you just don’t know yet.

In your experience, how would you describe the difference in expectations between each of these levels of engineers?

Junior: Their main metric for success is getting things done. They’re assigned tickets and they’re expected to complete them. Being a Junior Engineer gives you a foundation, like laying the bricks to a building.

Mid-level: Similarly, Mid-level Engineers are expected to get things done, but their projects are larger. For example, they might be working on teams as a lead on a feature. They’re going to make some higher-level decisions, choose which stack to use, and take responsibility for ensuring systems work together.

Senior: Out of the three levels, Senior Engineers code the least. Their main focus is designing systems and overseeing how they work together. Designing a whole system from a high level is like drawing the blueprint to the building. The implementation details are left to Mid-level and Junior engineers.

Anything else you want to add?

I want to add one more piece of advice for all the Fellows from nontraditional backgrounds, like myself. You might have imposter syndrome, and you may have it indefinitely. I’ve been there. But, don’t think about your education or past as something that holds you back; think about it as an opportunity to learn something you just don’t know yet.

Looking to learn from and among Mentors like Nic? Apply to the Formation Fellowship today.