Don't go there - Software Engineer Vaticle Employee Review

Hi, I'm Haikal, the Founder and CEO of Vaticle. Thank you for taking the time to share your feedback with us. I apologise for the experience you've had that didn't seem to be so great. I do completely see where you're coming from, and so I'd just like to share my thoughts and hopefully some additional context. 1) Our work is indeed high pressure in nature. As a small startup working on a database technology used by global companies, the goal that we need to deliver on is definitely ambitious. The maturity and quality of code that's expected of every engineer is very high. Combined with the size of our open source community and commercial clients, the challenge that stands ahead of us every day only gets bigger. There's a lot of code to be written, and they need to be written well. To some of us, we find thrill and excitement in this type of work. However, I can understand that it may not be everyone's cup of tea. I apologise that this was not what you expected. We will continue to communicate this clearly to all future hires so everyone has the right expectation. 2) I can see how you could have felt micromanaged. As the technical founder of a database technology company that is still small in size, my day-to-day role (2021) is still as the company's software architect and lead programmer. In a much larger company, many of us would not expect the CEO to review a junior engineer's code. However, being the architect and lead programmer in a young and small software company, my responsibility today still includes reviewing every line of code that goes into the main codebase, along with the architectural consequences of every code contribution and software delivery. Being a database technology, where software reliability and scalability is of critical nature, these code and architecture reviews need to be performed very thoroughly and rigorously, especially among very junior engineers. I apologise that these reviews, especially those done by the CEO, made you feel micromanaged. We certainly plan to delegate these responsibilities to new lead engineers and architects as the company grows. However, these engineering practices do need to continue to ensure quality across our codebase, which today still needs to be performed by me, the CEO, as I continue to fulfil the role of a software architect and lead programmer. 3) I apologise for making you feel like I was yelling. I have often been told that my voice is a bit too loud at times, but this would be the first time I've been told that I'm yelling. I sincerely apologise for this unpleasant experience. I take your feedback very seriously, and thank you for reminding me of this; I will continue to improve on my manner of speaking. 4) People do get dinner delivered when they work overtime, as well as bonuses. When we do work late at the office, we want to make sure everyone is taken care of. That includes ordering in dinner of whatever the team chooses, as well covering transportation whenever it's needed. However, we don't usually have plenty of overtime; I would say 1 out of every 10 weeks do we have a bit more of a stressful week where we have to run the extra mile. Most weeks, most team members leave at very reasonable times. Sometimes, such as Q4 2020, when we were behind the deadline for releasing TypeDB 2.0 (then called Grakn), we had to really run the extra miles for several consecutive weeks, where for a few weeks, the work spilt to a day on the weekend. In these periods, we pay our team members daily bonuses for their overtime at rates much higher than the base salary. Today (2021), while our company is still young in size and revenue, we don't yet have a formal overtime pay scheme. We certainly hope to implement an overtime pay scheme starting next year (2022). However, for the past few years, since we've started making revenue, we have been able to reward employees for their overtime throughout the year, through salary bonuses, during salary appraisals. We will continue to reward our team members through bonuses for their overtime, and we look forward to implementing a formal overtime pay scheme next year too. 5) The technology stack we work with indeed may feel more "niche" than the general software development ecosystem. Today (2021), the main development language in our team is Java - the most widely adopted language for backend server development. For our build system, we use Bazel: a modern build system built by Google to handle large, heterogeneous, and complex systems. For our client-server communication, we use GRPC: a high-performant RPC protocol built by Google to implement stateful over-the-network library APIs. For our embedded storage, we use RocksDB: a highly performant embedded key-value store built by Facebook. For our Mathematical Integer Programming solver, we use Google OR Tools and SCIP to build our query planner. For distributed systems messaging protocol, we use ZeroMQ. For language parsing, we use ANTLR. For Actor Model distributed systems framework, we use Akka. There are more frameworks and libraries that we use, but the aforementioned libraries paint a picture of what our technology stack looks like. Compared to general software development, these libraries are considered more advanced and definitely "niche". However, when it comes to building low-level "systems engineering" required in building highly scalable databases and distributed systems, these libraries are prevalent, powerful and widely adopted. Mastering these libraries would allow you to grow as a distributed systems engineer, enabling you to work on any underlying infrastructure of internet-scale technology. I hope my comments above help us understand our team and culture with a bit more context. Thank you so much for sharing your feedback, as they will always help us improve. Haikal Pribadi Founder and CEO of Vaticle