NodeFlair
Internet
11-50 Employees
4.9 (Glassdoor)
Claimed
Manages Culture Code and Employee Benefits
About NodeFlair
NodeFlair is a Tech Career SuperApp. Specifically designed for Tech talents - it’s one place for job discovery, job researching, job securing, career uplifting, and more!
We are on a mission to help tech talents in Asia make smarter career decisions; a world where developers can code( ) at where they love.
Come create history with us @ www.nodeflair.com/careers/
---
What’s it like working at NodeFlair?
High Performance - A great workplace is stunning colleagues. Mediocre team will never build great companies.
Intellectual Curiosity - We constantly ask "Why" in pursuit of absolute truth. We also get a kick from solving really difficult problems.
Radical Candour - We stay authentic by speaking your mind freely, no matter how controversial.
Be in Love - We are passionate and relentless towards a common mission. While in the journey, we never forget to enjoy the company of our team.
We are on a mission to help tech talents in Asia make smarter career decisions; a world where developers can code( ) at where they love.
Come create history with us @ www.nodeflair.com/careers/
---
What’s it like working at NodeFlair?
High Performance - A great workplace is stunning colleagues. Mediocre team will never build great companies.
Intellectual Curiosity - We constantly ask "Why" in pursuit of absolute truth. We also get a kick from solving really difficult problems.
Radical Candour - We stay authentic by speaking your mind freely, no matter how controversial.
Be in Love - We are passionate and relentless towards a common mission. While in the journey, we never forget to enjoy the company of our team.
NodeFlair Culture Code
Great Code Quality
Top
We believe in pragmatism when approaching technical decisions - we seek to use the simplest way to solve issues without over-engineering the solutions, allowing us to move fast with minimal production issues.
Every pull request goes through a thorough code review - we sweat over the minor details and catch even the seemingly small and insignificant things that have no impact on functionality. "Code smells" will be sounded off, such as multi-nested statements and bloated methods.
We believe that code should be readable and self-documenting; comments should only explain the "why" and not the "how". We aren't afraid of adding more lines of code if it means improving readability. It is also common to find us being deliberate when choosing names for methods and variables.
Every pull request goes through a thorough code review - we sweat over the minor details and catch even the seemingly small and insignificant things that have no impact on functionality. "Code smells" will be sounded off, such as multi-nested statements and bloated methods.
We believe that code should be readable and self-documenting; comments should only explain the "why" and not the "how". We aren't afraid of adding more lines of code if it means improving readability. It is also common to find us being deliberate when choosing names for methods and variables.
Product Love
Top
Our co-founders are also very active in the tech community and are on the ground to interact with the users. He will personally reply to users' emails and enquiries. Engineers also join for some user interviews to hear the most unfiltered feedback from the users. Users' suggestions and feedback (both good and bad) are shared with the team and taken seriously.
For example, one user previously shared that they are uncomfortable contributing their salary on NodeFlair Salaries because the submission date can be too exact by showing "2 months ago". It took the team one day to act on it and have similar submissions be reflected as "within six months" instead.
We believe that relying on marketing to grow a poorly-built product will backfire in the long run, and we stay away from it. This strategy is successful as our platform usage has grown consistently with almost zero advertising dollars spent since the start.
For example, one user previously shared that they are uncomfortable contributing their salary on NodeFlair Salaries because the submission date can be too exact by showing "2 months ago". It took the team one day to act on it and have similar submissions be reflected as "within six months" instead.
We believe that relying on marketing to grow a poorly-built product will backfire in the long run, and we stay away from it. This strategy is successful as our platform usage has grown consistently with almost zero advertising dollars spent since the start.
Engineering-Led
Top
NodeFlair is building towards empowering the tech community to work where they love. So, naturally, we practice this ourselves! We are proud to share that we are "By Engineers, for Engineers" at our core.
Our co-founder Adrian comes from a technical background and leads the Product and Engineering team. The tech team are not ticket monkeys who solely exist to support the sales and business team. Unlike many companies who view the tech team as a cost centre, we see it as a (long-term) profit centre that innovates and breaks new grounds on how we can better serve the tech community.
One example of being engineering-led is being very conscious of engineering productivity and ensuring the team has enough time to focus on deep work. We constantly look into ways to improve, even iterating through many variations of "standups" before landing on asynchronous updates, which we think are the least disruptive to one's schedule.
Our co-founder Adrian comes from a technical background and leads the Product and Engineering team. The tech team are not ticket monkeys who solely exist to support the sales and business team. Unlike many companies who view the tech team as a cost centre, we see it as a (long-term) profit centre that innovates and breaks new grounds on how we can better serve the tech community.
One example of being engineering-led is being very conscious of engineering productivity and ensuring the team has enough time to focus on deep work. We constantly look into ways to improve, even iterating through many variations of "standups" before landing on asynchronous updates, which we think are the least disruptive to one's schedule.
Move Fast
Top
The biggest enemy of a startup is time, so we have a bias for speed over perfection. We strongly believe in moving fast and breaking things (cliche, but true) and getting feedback rather than waiting to get things right on the first try. The first versions of our products were built and launched within 2 to 3 weeks before iterating hard to improve them.
For example, we turn NodeFlair Salaries from an idea into reality in less than a month. Re-iterating rapidly, it quickly became Singapore's largest repository of verified tech salaries, backed by offer letters and payslips.
We also constantly look into empowering the team to build fast by stripping down unnecessary processes. It is the norm for new joiners to ship to production in their first week.
Unlike many companies, we pride ourselves on not having full test coverage. Yes, you read that right. We acknowledge the trade-off between writing tests and speed, so we write tests only if they help us move faster. They consist of two primary situations. Firstly, too many cases to test manually. Secondly, the code is potentially catastrophic (How badly can this piece of code mess up our day + How difficult is it to recover from the worst-case scenario)
For example, we turn NodeFlair Salaries from an idea into reality in less than a month. Re-iterating rapidly, it quickly became Singapore's largest repository of verified tech salaries, backed by offer letters and payslips.
We also constantly look into empowering the team to build fast by stripping down unnecessary processes. It is the norm for new joiners to ship to production in their first week.
Unlike many companies, we pride ourselves on not having full test coverage. Yes, you read that right. We acknowledge the trade-off between writing tests and speed, so we write tests only if they help us move faster. They consist of two primary situations. Firstly, too many cases to test manually. Secondly, the code is potentially catastrophic (How badly can this piece of code mess up our day + How difficult is it to recover from the worst-case scenario)
Impressive Team
Top
Our co-founders, Ethan and Adrian, were from Softbank-backed ShopBack. Ethan grew ShopBack's tech team by 2x and launched their Vietnam and Taiwan tech hubs from scratch, while Adrian helped launch V2 of the mobile app and have mostly single-handedly built our current platform.
We are also fortunate to be backed by many angel investors who believe in our mission. These investors include executives and CTOs / Engineering VPs from high growth tech companies like ShopBack, Carousell, Airbnb, Nium, 99.co and more.
We highly value and enjoy working with the craziest and most brilliant people. Unlike many companies, we designed our interviews to give all applicants an equal chance, even if they did not come from "branded" companies and schools. Some software engineering interns did not have prior internship experiences or have yet to attend university even! Nevertheless, alumni joined companies like Indeed, Google and OpenGov, known to have high engineering standards.
We are also fortunate to be backed by many angel investors who believe in our mission. These investors include executives and CTOs / Engineering VPs from high growth tech companies like ShopBack, Carousell, Airbnb, Nium, 99.co and more.
We highly value and enjoy working with the craziest and most brilliant people. Unlike many companies, we designed our interviews to give all applicants an equal chance, even if they did not come from "branded" companies and schools. Some software engineering interns did not have prior internship experiences or have yet to attend university even! Nevertheless, alumni joined companies like Indeed, Google and OpenGov, known to have high engineering standards.
NodeFlair Culture Code QnA
<div>We welcome anyone to review and comment on any pull requests (PR), even if it's not their feature. Before a pull request can be merged and deployed, a senior needs to approve it.<br><br>Code reviews are strict as we understand the importance of good code (or rather, the damage by the bad ones). One element that affects code quality is readability. Code is written once but will be read multiple times down the road, so we are deliberate even when naming methods and variables. "Will someone understand this six months from now?" is one question we ask.<br><br>However, there are situations where we prioritize speed over quality, such as feature launches or urgent hotfixes. We will proceed to approve the PR but create an issue in our backlog to keep track of the code smell. 🦨</div>
<div>So far, we are fortunate not to face any outages or critical production bugs (touch wood)! But if all things break loose, our co-founder, Adrian, will be jumping right in to fight the fire!</div>
<div>There are two parts to the ramping up portion: Landscape Analysis and Technical Ramp-up.<br><br>Landscape Analysis involves researching and understanding players operating in similar spaces. We do this to ensure the team is self-aware of our strengths and weaknesses and challenge them to think through why our competitors do X and not Y.<br><br>After that, they will receive a simple ticket to familiarize themselves with the end-to-end development process, from building to code review to deployment. These are usually completed within the first week to give a sense of accomplishment and confidence to take on increasingly complex tickets.</div>
<div>We don't pair programs much because most of the tasks allocated are manageable, so forcing pair programming will be counter-intuitive and cause unnecessary zoom fatigue. That said, we aren't allergic to pair programming! If someone faces an issue and it's much easier to debug and explain verbally, we will hop on a call to solve it together.</div>
<div>Every morning, everyone in the Product, Engineering and Design team (PED) will share their updates and progresses in Slack. Anyone can reply if there's a need to clarify, re-align the team or update tasks prioritization. During the day, we will also ping each other if we need the other party to review a task we completed.</div>
<div>We are very conscious of engineers' schedules and deliberate in ensuring they have enough time to focus on deep work.<br><br>For example, we have iterated through many variations of status updates for tasks, from daily standups to having it twice a week to doing asynchronous updates.<br><br>Our co-founder even wrote a blog post on engineering productivity where he covered tips on improving productivity by yourself, a manager, and non-engineering co-workers!</div>
<div>The team is encouraged to attend meetups and conferences to learn beyond their job scope - our co-founder, Adrian, leads by example by participating actively in the community! He also often shares interesting learnings from engineering blogs and resources with the team!!</div>
<div>Yes! Currently, we are project-agnostic - everyone can have the opportunity to work on any product. <br><br>Also, we believe in helping engineers grow in both breadth and depth by doing our best to assign them a wide range of diverse tickets. Of course, if someone wishes to be more specialized in one area, we fully respect that too!</div>
<div>Our co-founder, Adrian, regularly co-hosts the local RubySG meetup and attends meetups to catch up with engineering leaders from other local companies to learn from their experiences. <br><br>Check out Adrian's sharing on how we use Scenic gem at RubySG!</div>
<div>We will do a premortem for critical decisions - the hypothetical opposite of a postmortem. <br><br>For example, we will ask: "If the product fails six months later, what would be the reasons?" We then break it down using the "Five Whys" analysis, a technique to determine the root cause of a problem by repeatedly asking "Why". <br><br>Most of the time, we will discover many potential issues, big or small. While we might decide not to fix these issues sometimes, we still find this thought process helpful in being more aware of the pitfalls.</div>
