DataSpark
Internet
51-200 Employees
4.1 (Glassdoor)
Claimed
Manages Culture Code and Employee Benefits
About DataSpark
DataSpark are leaders in processing large geospatial temporal mobility data to deliver intelligence on people and places using the highest data privacy standards. Understanding how people move, where they go, and what they do enables organisations to map their strategy around where people live work, and play.
DataSpark takes anonymised mobile and GPS data, public transport data, road network data, immigration data, and census data and transforms it into cohort-focused insights about how specific population segments move throughout their lives. DataSpark believes mobility data intelligence can help organisations make better-informed plans and decisions.
DataSpark is a subsidiary within Singtel, Asia's leading communications group. To learn more about DataSpark visit dsanalytics.com.
DataSpark takes anonymised mobile and GPS data, public transport data, road network data, immigration data, and census data and transforms it into cohort-focused insights about how specific population segments move throughout their lives. DataSpark believes mobility data intelligence can help organisations make better-informed plans and decisions.
DataSpark is a subsidiary within Singtel, Asia's leading communications group. To learn more about DataSpark visit dsanalytics.com.
DataSpark Culture Code
Great Code Quality
Top
We pride ourselves on writing readable code and not reinventing the wheel by having a deep understanding of how our adopted frameworks & Big Data stack work under the hood.
We also complement code with strong documentation of our algorithm methodology so that new team members can get up to speed in the shortest amount of time.
In addition, we follow best practices in our release management, in terms of branching and semantic versioning, which are equally important to our coding process.
We also complement code with strong documentation of our algorithm methodology so that new team members can get up to speed in the shortest amount of time.
In addition, we follow best practices in our release management, in terms of branching and semantic versioning, which are equally important to our coding process.
Engineering-Led
Top
Our engineering leadership influences our product directions and is proactive and two steps ahead of what businesses may expect of engineering.
We advocate engineering initiatives that accelerate product development and thus business growth and have a strong voice on paying down technical debt while explaining the whys to stakeholders.
Engineering leadership is also represented at the DataSpark Leadership level and part of the executive team, charting and influencing the business directions.
We advocate engineering initiatives that accelerate product development and thus business growth and have a strong voice on paying down technical debt while explaining the whys to stakeholders.
Engineering leadership is also represented at the DataSpark Leadership level and part of the executive team, charting and influencing the business directions.
Data-Driven
Top
We measure how our product is used by our user journeys, keeping metrics to identify hot spots that may hurt customer adoption or long-term use.
We also measure the traffic trends that inform our compute choices for maximising uptime while balancing costs to serve. We also look at performance benchmarking which will shed light on ways to further improve the experience of our data-centric products.
One example is our Data-as-a-Service (DaaS) API product providing a deep analysis of movement data from telco signals. We analyze the query patterns/depth, time periods of those deep calls, geo-location of customers making the calls, the associated response times etc. Doing so allows us to make the best trade-offs between geofencing, spot versus on-demand compute instances on what time of a day to minimize costs, proactively conveying SLAs degradation to customers etc.
Another example is our home-built Data Quality Framework (DQF) which we have now leveraged as part of our CI/CD to ensure all modules in the data processing pipeline are subject to automated data tests. The DQF allowed us to improve our test quality while concurrently correlating how many gaps we still have when our logic meets real customer-provided datasets. This creates a positive feedback loop which drives the engineers to look for areas of improvement.
This year, we also intend to introduce tools to measure our software delivery performance by tracking cycle-time, deployment frequency, change failure rate, and mean-time-to-restore (the DORA golden signals). This will allow us to know where which part of our internal processes can be further improved.
We also measure the traffic trends that inform our compute choices for maximising uptime while balancing costs to serve. We also look at performance benchmarking which will shed light on ways to further improve the experience of our data-centric products.
One example is our Data-as-a-Service (DaaS) API product providing a deep analysis of movement data from telco signals. We analyze the query patterns/depth, time periods of those deep calls, geo-location of customers making the calls, the associated response times etc. Doing so allows us to make the best trade-offs between geofencing, spot versus on-demand compute instances on what time of a day to minimize costs, proactively conveying SLAs degradation to customers etc.
Another example is our home-built Data Quality Framework (DQF) which we have now leveraged as part of our CI/CD to ensure all modules in the data processing pipeline are subject to automated data tests. The DQF allowed us to improve our test quality while concurrently correlating how many gaps we still have when our logic meets real customer-provided datasets. This creates a positive feedback loop which drives the engineers to look for areas of improvement.
This year, we also intend to introduce tools to measure our software delivery performance by tracking cycle-time, deployment frequency, change failure rate, and mean-time-to-restore (the DORA golden signals). This will allow us to know where which part of our internal processes can be further improved.
Safe-to-Fail Environment
Top
We are very concerned about our people's engagement levels and ensuring DataSpark is a great place to work.
We celebrate learnings and value retrospectives which will identify action plans and responsible individuals/parties to constantly improve the way we work.
We make mistakes all the time and value radical candour to bring the point across on what's working and what's not, without getting personal. We value openness to feedback and constant internal communications to align everyone as much as we can.
We celebrate learnings and value retrospectives which will identify action plans and responsible individuals/parties to constantly improve the way we work.
We make mistakes all the time and value radical candour to bring the point across on what's working and what's not, without getting personal. We value openness to feedback and constant internal communications to align everyone as much as we can.
Team Oriented
Top
We value collaboration and applaud "team-over-self" behaviours. We understand appreciation goes a long way and we are never shy to show this in big and small ways. Everyone chips in when the going gets tough which further enhances our bonding.
After-work events are self-driven with many individuals taking the initiative to organise such bond-building activities.
After-work events are self-driven with many individuals taking the initiative to organise such bond-building activities.
DataSpark Culture Code QnA
<div>Full CI/CD, semantic versioning in our branching strategy, with our custom-built Data Quality framework running integration tests before product release.</div>
<div>We pair as often as we can, so reviews are incorporated almost immediately. PRs are usually reviewed by peers or senior engineers before a merge is allowed.</div>
<div>We have dedicated service engineers who form our customer success team. We also have a dedicated incident management process which we also practice for production issues.</div>
<div>For major undertakings, we run product inceptions so that everyone involved is aligned on the goals, non-goals, risks and blockers, which frame the boundary of an idea. <br><br>We practice scrum and adapt it to suit our needs - 2 weeks of sprints with review & retro at the end of each sprint; setting clear sprint goals is also key.<br><br>We do quarterly release planning as a road mapping exercise too.</div>
<div>There is an assigned engineer at any point in time to attend to issues. This engineer is given a low workload in feature sprint so that they can attend to the production issues timely. The service engineers will triage the issue and attempts to recover 1st before escalating to the product engineer on duty. We set severity levels to production issues so we can prioritise what to fix first.</div>
<div>There is an assigned engineer at any point in time to attend to issues. This engineer is given a low workload in feature sprint so that they can attend to the production issues timely. The service engineers will triage the issue and attempts to recover 1st before escalating to the product engineer on duty. <br><br>We set severity levels to production issues so that we can prioritise what to fix first.</div>
<div>No more than 3 working days</div>
<div>We leverage Confluence as the body of knowledge for all our engineers to get them started. There are also video resources we recorded to let them self-pace their learnings.<br><br>But nothing beats getting them as part of the sprint cadence to experience the discussions, solutions and prioritization thought process.</div>
<div>As much as we could, especially on complex implementations. We do not mandate everyone to do this at the moment.</div>
<div>Every 24 hours. Our daily scrum is where we have the latest updates, feedback and asking for help within the scrum team.</div>
<div>Quarterly release planning will set the boundaries of what is important for the next three months. <br><br>Estimations are t-shirt sizing during the two weeks of release planning discussions and solutions, setting the expectations with the Sales Team of what they can expect from our product offerings.</div>
<div>After every sprint, there are retrospections in which all team members will spend time talking through what went well and what needs to be improved. Post-incident retrospections are also conducted.</div>
<div>We plan who will focus on what pieces of work in each sprint and will not deviate from it to prevent context switching. The more senior folks might be the subject matter experts to answer some of the production issues and allocated support time, taking less workload during sprints.<br><br>We also attend to platform issues as soon as we so that engineers are not blocked in their development flow.</div>
<div>We have a standardized performance evaluation framework where everyone is subjected to the same benchmarks, depending on their job grades. We look at consistent high performers (over two years) and potential for growth at the next level to decide who to promote.</div>
<div>We encourage engineers to come forth and present topics they are passionate about with the rest of the organisation. Everyone has a development plan and a set of OKRs to help them achieve their growth.<br>We also have various online learning platforms and an in-house competency academy to level people up.<br><br>In addition, we are now planning a standardized tech skills training that every engineer will need to go through so they are well equipped to be productive.</div>
<div>We have a very flexible working culture where we do not mandate hard working hours. Engineers are also encouraged to look after their well-being and take breaks as needed.<br><br>Everyone also engages in 1-1s regularly (throughout all levels) so that we have a sense of where things may go awry before it becomes an issue.</div>
<div>Definitely! There is more work than people and we certainly encourage job rotations amongst engineers so they can be exposed to different areas of work.</div>
<div>As you progress higher in the job grades, the bar to getting promoted becomes higher. Only the top 1% gets promoted for senior folks.<br><br>Having said this, being recognized as a high performer (even though there are no promotions) also means a higher reward for more senior folks when compared to junior folks.</div>
<div>B2B growth is challenging and can be slow to materialize. Compared to eCommerce or fintech B2C companies, DataSpark has yet to reach the hockey stick effect. As a result, we are also trying stuff in various domains, which can be a source of frustrations and distractions for some folks.</div>
<div>The Data Engineering Singapore meetup group is primarily started and managed by DataSpark folks. We organise monthly meetups to share knowledge about all things about the movement of data.<br><br>We also get to speak at domain-specific conferences such as Transportation, which will showcase our thought leadership and know-how in Geospatial data processing. We encourage all to attend conferences to get them in touch with the industry trends.</div>
<div>We prefer to promote from within because the prospects already know the culture and expectations of what is needed for their next role.<br>We will look for external candidates to beef up the existing team size or composition to scale.<br><br>We will also look for external candidates who require cross-functional experiences, which may be hard to find in a single person within DataSpark.</div>
<div>Usually socialized in smaller group settings or 1-1s first to get early feedback before announcing to a wider audience.</div>
<div>Mistakes happen all the time. We do not avoid them because they are learning moments. However, it is important to take action to prevent the same mistake from happening again. It is also important for the affected people and those involved in the execution to be aligned on what could have been done better and own the preventive action plans.</div>
<div>We have various structured weekly to make sure cross-functional collaboration and conversations take place. For example, we have bi-weekly product sync-up between product managers and engineering leads to ensure we are aligned on major directions, address tactical choices and needs etc.<br><br>We also project-specific weekly "war room" where products, engineering, and sales come together to align on what needs to be fulfilled to meet customer commitments.</div>
<div>We do not yet have any deliberate action plans on this. However, we do not have biases against nationality, race or gender in our hiring.</div>
<div>It happens within the product and engineering organisations mostly. This is a result of trying to solve problems, which may be faced by the product and engineering teams, to move the business forward.</div>
<div>We have a monthly town hall where we invite open questions from all staff. Any topics are welcomed and addressed squarely during the sessions without skirting around the root causes.</div>
