Welcome to a new series where we interview reputable and interesting figures within the tech space. The aim of this is to share insights from within the industry, and some tips and tricks that will hopefully give you an upper hand in your career.
Our favourite takeaway from this whole session though? This golden nugget from Julius: 'The reward for short term planning is the now and we pay for it with our future. The reward for long term planning is the future and we pay for it with the present'.
Read on below to find out more.
*Some parts of this interview has been edited for clarity.
In general, the Vice President of Engineering (VPE) is considered the most senior engineering position within a company, in contrast to the CTO which is higher in hierarchy. Startups usually hire the VPE to professionalize the engineering department. The mandate of the VPE is to ensure that the engineering team is as cost efficient as it can be.
By being cost efficient, it doesn’t simply mean cutting costs. It may also mean incurring costs to protect the company. For example, paying engineers more to retain them.
With that as a backdrop, the VPE then looks for various solutions to optimise cost. It could be driving alignment across multiple teams; setting a technical vision, enabling a highly effective culture, hiring, and so forth. That’s basically what I do in a nutshell (and roughly most other VPEs out there).
I’m biased to say good things about the team but it will be good to verify with the engineers who have already left and those that are still here. A 2013 research from Gallup shows that a highly engaged team outperforms their peers by as much as 147% earnings per share. That’s essentially getting more than a free engineer for each engineer!
Various theories have been proposed around how to enable an effective team. A research by Google however shows that a team with high psychological safety tends to outperform others. So at Hubble, that’s the number one goal and I think we’re doing it very well.
Our most experienced engineers demonstrate a lot of humility (by experienced, I do mean those who are Google Developer Experts). Everyone is very kind and collaborative.
It may sound superficial, but I strongly suggest anyone from outside to verify this from any engineer within Hubble. I am quite confident that our engineers will say that the culture here is nothing like they’ve ever seen before, in a positive way.
A study was done several years ago around the categories of people that elicit positive emotions. Friends turn out to be at the top. Spouses (surprisingly) come third, and bosses and colleagues come in at the bottom (in essence, they elicit the most negative of emotions).
In order to negate this, At Hubble, I treat everyone as my friend. I joke with them, have fun with them, hang out with them, mentor them, and make every effort to make them feel safe and ensure that i'm always there for them. There’s a famous quote by Peter Drucker that says, “Culture eats strategy for breakfast.” In essence, take care of people and they’ll take care of your company.
Interestingly, one of my direct reports once said, “if you treat me well, wouldn’t I want to treat you well as well?” Many bosses unfortunately have their priorities misplaced. They put the product before the people and they throw both off the cliff.
At Hubble, we have four rounds of interviews; Three technical and one behavioral interview. We test their algorithms (lai, throw tomatoes at us), system design, general cognitive ability, and behavioral habits.
Excellent people want to work with other excellent people so, we try to hire the best (everyone says that). Why do we have four rounds? That’s because research shows that any more interviews apart from that is not statistically significant to tilt the scales.
To be clear, Google has 4 rounds for non-engineers and 5 for engineers. We however decided to keep the numbers at 4 unless we need to break a tie.
Recruiters as you might know look for ”signals”. If there’s a mention of Google in your resume, that’s a signal. They are not indicative, but are predictive of a person’s capacity to do well.
In my case I look for these signals as well. Do they come from a good school? Do they volunteer in communities? Do they come from good companies? That said, there has been no literature around being able to detect a person’s capacity to perform in a much more sustainable way.
I've passed on numerous people in interviews (and resumes) who turned out to do exorbitantly well. I know this because my boss saved them and got them into the company.
Eric Schmidt, former CEO of Google once noted that “the industry overvalues experience, and undervalues strategic and intellectual flexibility.” I don’t know of a good way to extract this in resumes yet and it seems interviews and resumes fail to represent this sufficiently.
I ask different questions depending on what I interview for. In general, good engineers should be able to answer “What are you excited about the latest announcements on the technology you’re using?” At Rakuten Viki, I always asked that question and straight away I would know whether or not the candidate is a good fit.
I remember back in 2017, I hired a 2nd year intern from NTU who has done AR Kit (AR Kit was announced only in June of that year). It tells me that this person is one who can push the envelope. Every single person that we offered had good answers there.
There’s the “official” way to do things, and the “actual” way to do things. Let’s first talk about the official way. The official way is to simply do your job, excel at it, and then hopefully you’ll get to the VPE level one day. If you want to be a CTO, you just have to incorporate a company and call yourself a CTO.
The actual way is to mimic your boss and here’s why; People like those who are similar to themselves. When you want to get promoted, ignore everything HR tells you to do and do everything your manager does. Your manager would still have the biggest say in your promotion so in reality if you want to shortcut your way through, that’s how you should do it.
Here’s a caveat though. I have interviewed so many people in the Director and VP level positions that have very good resumes but when you start peeling the onion, there’s nothing inside. What this goes to say is that focus on learning and the position will follow. Stay humble. If you flip things around, you may still get the designation and the prestige, but not respect.
This is very situational and depends on the person. In general I would suggest that as a manager, you should spend at least an hour a day reading. If you dislike reading, you’re probably not cut out for management.
When writing code, you need knowledge. When managing people, you need wisdom.
For someone without management experience, The Trillion Dollar Coach is a tremendous book to start with. It’s a book about Bill Campbell, the person behind the success of many Silicon Valley Luminaries like Eric Schmidt, Jeff Bezos, Steve Jobs, Susan Wojcicki, Marissa Meyer, and so forth.
There are other more technical ones like The New Psychology of Leadership and the Culture Code.
If you want typical books recommended by Engineering leaders in Silicon Valley, here they are in no particular order: Radical Candor, The Manager’s Path, Multipliers, Drive, Measure What Matters, An Elegant Puzzle.
This is a very good question. The answer is that the business should know its north star and no matter what the business is, the business has to win. Nothing more, nothing less. Once we make sure everyone gets that, we can now work our way back to find out how we can make that happen.
Should I write my code with the most robust architecture, the most robust test cases, the most robust CI/CD, and the most robust infrastructure in place? When answered in isolation, it is of course, yes. Now what if the company is 90 days away from running out of money, does any of these help? The answer is no.
In reality, there are no best practices, only tradeoffs. A good decision is an agent of scale. If writing “good” code is not an agent of scale, we might as well put that in the backlog. So to answer the question, it depends on the situation. We write just the right quality of code to serve as fuel for future expansion. Sometimes, we have to write them properly. Sometimes, we have to get them out as quickly as we can and refactor later.
One major suggestion though is that a startup should at least bring in one staff level engineer early on. It doesn’t matter what stack he works on. Just bring one to mentor all the juniors. The Staff Engineer will ask good questions even if he does not know enough of the stack. It will make a world of difference in fixing scalability issues later on.
Many tech startups strapped with cash will hire only interns and juniors. That is almost never a good idea.
This is a very good question especially in the last few years where Software Engineer salaries have exploded at an unimaginable rate. A lot of engineers today (in fact people in general) revere instant gratification.
You have companies like Bytedance, Shopee, and so forth who are throwing money at the problem and engineers bite. Here’s what I think people should think about: The moment we enter the workforce in our mid-20s, we should be cognisant that there’s around 40 years of career ahead of us.
The reward for short term planning is the now, and we pay for it with the future. The reward for long term planning is the future, and we pay for it with the present.
When one joins a big company like Rakuten, they are immediately shackled by golden handcuffs. They do very specific work, get paid high salaries, but have little flexibility to expand their cognitive scope. Why would I give up my stable $70,000 TC for an unstable $50,000 TC at a startup?
In a thriving startup, everything is on fire and you get to wear multiple hats. Startups are never comfortable places to be. If you find yourself in the right startup, you will learn so much in so little time. The challenge of course is that you don’t get paid the same rate as the big boys.
Where then, do we draw the line? We should draw the line by looking at what the long term goal is, then we plan the short term in light of the long term.
So if the goal is to be stable, my suggestion is to go to a large company for 2-3 years with plans to move to startups after. Learn the ropes there and then do startups and enjoy the pain of firefighting.
Once you’ve been in both, try going to a startup where you have a hand in scaling it. What you essentially run into is a view of what the endgame looks like, what the early days look like, and how to bridge that gap. Once you experience those, you can go to any size company and figure your way out because you’ve already seen how things are like at various sizes of the company and you become extremely adaptable.
It’s a long answer, but I hope that’s what would help your audiences.
- End of Interview-
Did you enjoy our AMA session with Julius Uy? Let us know your thoughts and who we should get for our next feature!
Isn’t it frustrating to apply for a job without knowing the salary band of the company beforehand? We aim to empower you by making salary information more accessible to the people via verified data.
Contribute your salary anonymously today, and let us help you make smarter career decisions.
Click on the button below to do your part in putting an end to the opaqueness here in Singapore!
Follow us on Telegram (@nodeflairsg) for the latest Tech Insight, Reads, Salaries & Job Opportunities!