 Yes. Okay. Yeah. So at Telenox, we love Ruby. So we are built on Ruby on Rails. Yeah. So I thought to share my journey and reflections. So if it can help in any way for you to build your own company or product in the future. Yeah. So for those that don't know about Telenox, we built HR software for SMEs just focusing on payroll and leave. All right. So we just have a few different models. So profiles where you can store the employee information and to onboard your entire company in a breeze. Yeah. So users usually use our import function, which will give them a Google sheet so that they can key in the data on their own. So we don't need to handhold them. For payroll, we are localized for all the countries that we are in. Currently it's Singapore, Hong Kong and Malaysia. So if a company or HR admin were to run payroll for the countries they are in, everything will be the same and it's seamless so that it's easy for them and they know what to expect. For leave, we will also take care of the statutory requirements that for the country they are in. So all the preset statutory requirements will be in the system. So they don't really have to worry about what's the default for every country. So yeah, and we are integrated with many banks and apps like zero for counting local banks, DBS, OCDC and UB. But integration, I would say in this case today, is still a file generator at Telenox and users will have to upload onto the bank portal. But yeah, we are solely working with the banks to change this future and it will come soon, something exciting will come soon. Yep, so we have integrated ecosystem in Singapore with CPF, IRS, local banks, accounting and scheduling and time tracking. We have a premium basically, so we have a free plan and a paid plan. So we have a lot more companies on the paid plan actually. So we can actually support SME of many, many sizes. Yeah, so I just thought to share if you're like, this is an overview of what is Telenox in case you don't know. Yeah, so I thought to share like how Telenox started actually. Yeah, so Gordon actually had a HR outsourcing background while I'm a software engineer. So we met when Gordon was actually working on his previous educational technology startup. And so I call up with Gordon, as a friend of mine actually running an MNC in Qatar, had an issue finding a good HR system. So both of us then realized that no one is really doing a good job for HR software in Southeast Asia. So from this reference MNC customer, we really underestimated the amount of effort needed to build a HR software actually. So in 2014, we had to make a tough call to actually disappoint our first MNC customer that actually believed in us. So while looking to actually support more SMEs in Singapore and around the region and understand the requirements. Yeah, so at that time it was quite tough because since it was a personal friend of mine. So in 2015, so we started, we actually had a traction of about 100 to 100 SMEs already. So we started raising angel investments over three years. So in total we raised about a million by 2017. And then we decided to go Hong Kong and Malaysia and then today we have about 3000 SMEs in Singapore, Hong Kong and Malaysia. So I talked to talk about my journey so that it can help or maybe give you some ideas on how everything will split together and it can maybe help you in your journey. So surprising to many actually I choose the path of entrepreneurship not because I really wanted to have a company, but more that I would want to work with good or great people while painting the shared canvas of a team of tele-nogs together. So on the top left is actually our first team retreat in Johor. It was like 2016. Yeah, so it was a small team of eight of us only. And in 2018, so not too long ago, if you see at the bottom left, actually the team only have about four engineers and it's four of us. Yeah, like we're celebrating sounds with it. And today at the right hand side, like we have a Zoom to celebrate this birthday. We have a team of 20 and we have about 10 engineers today. And many of them are better than me in different skills like David would be very good in ops and and I don't know as Danny, many of the engineers are much better than me and many other skills. So I'm proud to build the team together with them. So working on tele-nogs, truthfully, if you were to meet me in person or ask me, I will admit to you that I really do not have passion for HR and it's quite difficult to have passion for HR. But I do have the passion to help others and together with the team actually to be putting a lot of effort to help others. It's true directing this passion that I realized that that imagination is actually more important than knowledge. So because I came in without actually knowing anything about the industry. So I realized and after some time I realized why actually no one can actually also create a great experience for each other. So today we just have so much still have so much to do. But yeah, so if you want to set out to do anything, even if you do not know anything about the thing you want to build, if you can imagine how it can be better, just have the courage to go explore and make many mistakes. Yeah, I believe it will go somewhere. Okay. Yeah, so yeah, the reason why I'm sharing a lot of my personal journey is also because it's really quite difficult to gain empathy. And really keep it going for a long time. So because it's actually a lot easier to enjoy and go build something for yourself, but rather than for others. So if you personally want something, yeah, then go do it and try because it's really much harder if you want to try to build something for others. You have to spend a lot of time to or empathy to actually go and do it. Yeah, so if you want to build something to spend time to deeply think like what really drives you and whether it's for yourself or others and what are the problems you really really like to solve. Build your angle be a company or product where you actually can maintain as a indie or indie or solo developer while having a full time job. There's no right or wrong answer. But most important is to find a fulfillment in what you like to do as an engineer. Yeah. So whether your angle is a company or indie developer, I thought it would be interesting to share like finding a co-founder or people that are better than you. Yeah, so God and I are beside each other and in the photo on the left. So I'm in black and is the one on my right. Yeah, so I think people a lot of people talk about finding a co-founder. Yeah, but I think what's most important is not skills of a lab but but certain values that you have, especially when it comes to money and integrity. Yeah, so if you want to talk if you want to build anything long term. Yeah, so then those two values paramount because both of us are actually thrifty in our own ways. And we have always prioritized like a valuing or paying and promoting the team members first rather than ourselves, even during cash flow difficulties now. So which led us to always find people better than ourselves as we want to take care of them and their needs and while challenging each other to go further. So your team work will actually get better and easier. Yeah. And on the right, actually, like times like the engineers are even more passionate than me. This is when we were beginning into 2016. This is actually in the toilet. So they're actually debugging or fixing the bug. They are so the engineers are even more passionate than me, you know, when there are certain problems. They just had to do in the toilet of all places. So finding people better than you and building to admit and learn from them is quite important. So when you build a company or product as an indie, so you always need help in like marketing, sales design and all the other skills that are not really engineering. So you are your team actually be so a lot more motivated when you actually have smart people around you to help you. So yeah, I can say that today our engineering team is better than me in many different ways and we're always hiring and looking out for engineers. Yeah. So one way to actually find people better than you is also to learn to be better and also use your skills to actually help others as well. So in our early days, actually, we don't really have much to offer. So for 10 o'clock about half the team I knew a lot of them personally so on the left is like the early beginnings of the company. You already knew that I knew them from my personal endeavors like assisting them in the past or already worked with them before. So we did not have the finances to actually recruit them. But the initial team was motivated by everything else we had to offer but money, you know. So our friends will show actually help us to build things before they left for their jobs or help us to recruit others. Like on the right, the calculator I'm showing actually was built by a good friend of mine before he left for the US to join startup and then Google. So to today, like, even to today I knew like half the team personally in engineering and business before they actually joined the company. So to end off, I thought that it's important to find a problem issue you really care about a lot and so that you can build something people want. And you're not likely succeed on your first try, but the best way to learn is by building. So imagination is more important than knowledge. Yeah, and yeah, if I could do it coming into the industry without knowing much about HR, but yet learn a lot about it. So I believe that if you're, if you really care about something, imagining it how it can be better will really help you a lot. And so and find good or great people that you really want to work with from day one. So you need to look inward a lot also to be a good or great person to attract others to work with. Yeah, so building tenors actually made me a better person in many ways. Yeah, so they can lead the company better too. And yeah, so tenors aspires to contribute one day back to would be like how this can get up Shopify does it. And it's only when we do then we're truly proud to consider ourselves a company. I think that's all for my sharing. Yeah. Thank you. Awesome. Yeah, that was a great, great sharing. Now I guess now it's just like the Q&A. So anybody have any questions just feel free to shout out if you are very shy about asking it like on record, you can type it down. I can ask it ask it for you. Yeah, maybe I can start off like Yeah, I understand. I know like you said Tyler Knox uses Ruby, right? I mean this is a Ruby with us. So my question is that why do you guys like stick to Ruby? Do you all like run into what other people call like performance issues and stuff like that? And if you do then how do you all like get over it? I think recently we are facing my memory issues. So David and I were looking into it because once the app grows bigger and once we had to load a lot of Jax like for the employees and for many large companies, we can see that memory profile has always been increasing larger and larger. So it's a challenge to manage. That's why we have been looking into those issues. And what really helped was also using jmail up that it really showed a 20% drop in the memory usage. So that really helped a lot performance wise. It's actually works for us too. Yeah, but the memory issue is really a challenge. Why do you guys like, like, like, what, what, what will you like? Okay, probably I'm not like discouraging you. I'm just like curious, like maybe they all have any decision like why you want to stick with Ruby? Because you guys like the real spring work, et cetera. I don't know what's the opinion for all the other engineers, but personally, I really enjoy reading Ruby Cola. Yeah, it's a very personal thing, I guess. Yeah, very personal. I think that really helps. Okay, Edwin, thank you. My name is Ernest. I want to find out. I guess it's a monolith, right? And if it is, then how do new developers who come on board get acquainted with the code? And if it is microservice, are you still using Ruby or using another language or is just pure Ruby? Oh, yeah, we are using a monolith. Yeah, so all the code is together in the same code base. So in tenox, everyone is divided into different teams or squads like Shopify. So they all work on different parts of the code base. So the leads will actually onboard them with their own like documentation or knowledge on how the code base works and to help them figure out the initial, initial, how the code will work, like for leave or payroll. The upstream which David is in is the most challenging because they work across the entire code base to help with any performance issues that they face. In the front end, is it, do you do any kind of maybe JavaScript or any of the JavaScript web frameworks or libraries like React or Vue.js or just pure vanilla. Yeah, we are using Angular currently. However, we are considering to actually exploring different ways now to what's the best direction to move towards. Whether to use a React or stimulus with hot wire that what he and this can be doing. So actually exploring the next direction and hope to make a decision soon. Last question. Sorry. No, no problem. So, so, I mean, it started with a version of rails right so over the years you have to keep on upgrading depending on the version that is coming so the current version I assume is either 546 and now seven is coming along so how is that you have difficulty I mean, especially with the changes that are involved in seven now almost everyone is going not divided a group into two. So I'm just, how do you find difficulty in changing upgrading, let's say from five to six then from six to seven which is coming. It's a good question. Actually, we have an engineer called anonymous. His name is anonymous. Yeah, so he actually always helps. We started from four. So over the years he actually has always helped us to see how we can start moving the grid path towards five, six and we are preparing to go to seven. So we are 6.0 going to 6.1 to 10 to seven. So you need someone to work on it. Someone dedicated in ensuring the upgrade. Yeah. He has the passion to like look forward to be more like future thinking for us. Yeah, that's fine. Thank you for the questions. Right, I'll go next. Hi, I'm Ted. So it sounds like some of the killer features of the product is that you're able to integrate with like iris and other systems that the HR staff need to interface with anyway. So how did you go about that? Did you just like take the bus down to iris and ask like hey, do you have an API or something? Thank you for asking. Actually, when iris wanted to do the API, they asked us for their feedback. The reason is also because we were also we also had a lot of SMEs compared to other companies in our space. So they wanted to know whether things could work out and how would the initial implementation be because we gave them the feedback that before the API. Let's say if you're a HR admin, you will probably need to take like two hours just to submit your text. It's quite crazy. Yeah, so because you have to figure out, you're going to go to a 50 page document to learn how to submit it. I have to go through that so I know how it feels. Yeah, so we actually asked them when they're doing it and actually they happen to be doing it. Yeah, so and we actually have to explore. So they're quite forward thinking actually. I think also because iris is the revenue generation of the country, so they do have a lot more resources to innovate and move quite fast. So the timing just looks up for a second. Well, thank you. So about so about follow up to that question. So it means so how do they so is every company that you are integrated with, are they uploading the content themselves if they are uploading onto your platform or all of them have an API and if they all have an API, how are you consolidating all the end points into one to ensure a similar integration. And secondly, how are they doing the upload they have a spreadsheet with a world defined data set to upload. Yeah, like for iris, I would say that there is a well defined API on what you want to submit. Yeah, because for taxation the views are quite fixed about information that they want. Yeah. And not all the time you will have a very well defined a behind for but for the government. Yeah, they're actually working quite a lot on it. And there's a lot of very good improvements for the API aspect coming from iris but for the banks, it's still a little bit far behind here. Yeah. I mean, Adrian from. So I also co founder of note for us so I think I think the question that I have is that I see that you did have much experience, like, when you started telling us right. So, like, I was like, well, what is the like, the one of the few like challenge you face as a relatively inexperienced like, like, CTO when you started. I think the hardest is always recruiting other engineers, I guess. Yeah, I guess that's the hardest. I think technically I feel that I could always figure out the hard part is always finding like like minded and good people to work together. I guess that was always the constant challenge the people the people portion of building a team and a company. But like, because I think from a very similar background from new luck. So like, yeah, well, we advise for someone that also have not much technical experience when it comes to like hiring the first few engineers. I think, find people so how I did the how the way maybe I talk about the way we interview people it's quite different from most companies. It's a bit maybe it's a bit similar to what base camp is doing as well, but it's a bit different as well. So we actually send them a list of questions and this list of questions depending on how they answer. Like I just asked them what's their dream or what's their hardest challenge to face in life. What's the most difficult technical challenge. The reason why I asked all these questions first when when I filtered them for the first stage of the course, we are remote team actually. So since we are remote team, they need to know how to communicate their ideas through text or else it will be very hard to work with others. I some of my engineers I never see them for a few years. So, yeah, like I rarely meet many of them in person actually sometimes it's quite nice to really meet them in person. So that's why we want to filter this way then from there I read your responses to tell maybe how they can how they think. Yeah, so it's quite internal reflecting based on our culture. Then that's our first stage so second stage interview we actually like well if they have ruby on real experience will pay them to work with us. And the reason why we do that is because so maybe we pay them to work on a feature together, then we can tell how they work. Yeah, so we are not the type where we want to do programming test and stuff like that because a few doesn't find the engineers that we can work with the best. Yeah, we like to work with people first like like some of the senior engineers or so we work with them for a few years actually before before they join us or so. Yeah, so we really like that and the final stage would be just to see like, like for them to meet the different leaders and people so that we can see if the character fits. So, I wouldn't really say advice maybe from the same experience and from a friend to friend, maybe this you don't need to be afraid, it's actually an honor to hire people that are better than you technically. The good thing, the most important thing is to find to reflect on what really works well for you and what kind of people you enjoy working with, then create the process to help you find those people. Then, then you can kind of work out like, yeah, yeah, like so if you're like you feel like algorithm problems then maybe you need to find people that really likes that. Yeah, that's really nothing wrong. I mean that's how like Google started out to write and it works for them. Yeah, so just find something that really works well for you personally. And I think you will attract the people that you will really like to work with. This question will be quite biased because I'm looking for entry level so what trainings like you have for maybe for do you have entry level position for junior developers and that how is the training like what do you expect of them do you expect someone to have as a junior developer for you to consider even bringing them on board to work with you for that period of time while assessing them. Yeah, for juniors we actually look at the type of problems they have solved before and what type of projects they worked on or what are the things that they built before those are actually quite good sites. Because like or whether we are they are willing to pick up Ruby on Rails. Yeah, so we actually put actually all our interns we put them through learning Ruby on Rails using the Rails tutorial, because if you, if you don't want to pick it up then it's, it's for us I think I mean maybe for me personally like being an engineer means you have to learn many things but not willing to learn the stack that a company works on then it's a bit difficult for us to also work with you. Yeah, so, so we kind of like want them to learn we know that it's not what we put them it's not easy it's going to be long, it's going to be a commitment. So we put them we put them through that so that if they commit themselves to learning, actually every intern or every junior will have a mentor so that they can actually learn, learn from this person. Yeah, so that's how we create a good learning structure. There's still a lot that we have to do, like maybe like good learnings from the different senior engineers as well as we learn. But it's always a work in progress for us that do for both the senior engineers and we can teach juniors better so yeah. So what about with regards to gems right do you gemify everything or you look at the tradeoffs of using which gem is going to solve your problem or which one you or team have to handcraft. How is the balance like. We are quite pragmatic. It's a good question to figure out things, but we are quite pragmatic if the gem works then we will use it, or else we will also explore deeply how to solve it. Because sometimes there are some problems with a gem that suddenly has a CV issue and we cannot deploy because we will have a bundle of day patrol errors and you know it will put everyone up so we do need to make decisions like that on quite a daily basis. But the engineers actually go ahead on what's most pragmatic, but also keeping like all the baseline practices like passing the bundle of the passing all tests and things or things to go live. I actually have one question. You said that you guys are full remote right and other engineers. We hire from the region or is it just Singapore. Oh, we are trying to hire from all over the region actually. And of course I run the Ruby SG community so I'm actually curious how are the Ruby engineers like outside of Singapore. So far we have three engineers working from Malaysia actually we're trying to find higher outside more but three Malaysia and the rest are in Singapore. So, we actually I think they didn't have Ruby background at first, but only when they joined time logs they started out the experience. Yeah. Thanks. Like, like looking that right like what what are some like maybe some technical decisions that you wouldn't have like, you wouldn't have to eat that you're you're you're you're doing otherwise. Oh, it's a good question. I have to think. Technically, actually, we really helped us a lot to be honest. But maybe I think the hardest is knowing what not to do. Maybe the challenge technically hasn't we hasn't reached the large bottleneck yet because every time we reach a certain challenge. We always a good practice and how to solve it. Like for example, if the load gets too high or what what can we do. And we always have good people to help us like For example, when we face a scaling issue when there were too many requests and how can we do it or like she did it also was helping us to switch to Kubernetes so that we can start to scale and we can start to scale our notes temporary so everyone work together to solve these issues. So I can't really think of issue where I think I would do things differently, but definitely no cutting down on a lot more stuff that doesn't need to be done like for features wise, will really help us a lot. Yeah. So the good thing about telenox I guess is that we make a lot of decision based on how we can improve the users experience. So we don't have to. I will say chase features so that you can get customers. Yeah, which is always quite a dangerous path to go into. Yeah, because once you go into that path, you can remove features easily. So I guess, yeah, for me it's more, I think, I think I've been quite blessed to have good people that we all solve all these problems together actually, but maybe we will not do Angular so early, maybe, which will help the development path faster. Yeah, maybe. I have one question about, like, maybe like just deployment and like how you all do your infrastructure, like the you guys started out with, like he wrote cool, or you'll do your own servers configuration all those stuff. We started with Haruku. It's also until we can, we cannot take it anymore because the memory bloat is there's memory bloat keeps blowing up so you have to increase the dino memory. So we moved out to AWS and we set up with Capistrano and yeah then Capistrano then some issues also like because you had to manually image the images and do the deployments for us when scaling you get old code. So after for one or two years with Capistrano, then because the issues aren't easy to solve as we go. So we decided to move everything over to Kubernetes when it came out. Yeah, and it was a nightmare when we first started actually because there was some issues with AWS when we hosted Kubernetes Masters on it. I think David knew when we were. So everyone David goes to Genting, our system goes down. So for the first time he goes to Genting the system went down. So I was like 10pm calling him he was in the hotel room then I was and not trying to try to bring up the system. Yeah, because I think there's some AWS bug also is causing this AWS bug that they didn't want to talk about the way that how networking works. It brought out all the Masters so all the nodes went down. Yeah, so we had to quickly try to bring up the cluster. Yeah. You are damn awesome. Yeah, so actually David really really helped us a lot. Yeah, then we actually work together a lot very very closely to bring out everything. It was really quite a fun time. Then Kubernetes actually was really awesome and a great decision. It really simplified our lives a lot and the scaling issues and David can probably talk more next time or so in another talk like how it helped everyone. Nice and then like how do you all do like pure CI CD or you're like do staging and then deploy to prod this time. Yeah, we do like pure CI CD. It's just that deployments are not automatic. So the engineers can decide when they want to deploy when they want to deploy actually because sometimes there could be migrations that might that might table log over so they can actually be more alert when they do a deploy as well. So you will do a much and then they will decide when to push it out. Correct. Correct. Yeah, they will decide when to they want to push it out because during certain periods we can deploy as easily like everyone like There was once I think we brought down the system during a period. So then suddenly you get you will get like 10 mess you get like 20 messages every minute. Everybody's trying to use the system and the system down. So it's quite intense. Oh, interesting. Okay, I was in the Shopify so so we do like have crunch time around the year. Like crunch time specific months of the year. Is there such a thing for talent or is it really like distributed the load. The load is quite distributed in some way I think depending on what we are going through like currently we are going through security audit so the op steam will be more busy like a big steam will be more busy. The team is usually a lot easier maybe in the early early early start of the year. Like January and February because that's the tax season and it will be really busy so everyone is quite spread out. So we try our best to spread out the load and preempt the preempt when pick period will happen. Yeah. But for Shopify, do you have a peak period? Yeah, we do. Our peak period is during Black Friday, Cyber Monday like that. That's probably like plus minus total one month about there of the year. Understandable. Anybody else have any more questions? Okay, I guess not. Yeah, so thank you very much for answering all our questions and sharing with us like how talent also spills and all the internals.