Skip to main content

Backend

Back-end jobs​

Backend Engineer​

The Backend Engineer will be responsible for the development of the backend part of our products and internal systems, working with product managers and frontend engineers to achieve common goals.

All back-end engineer roles in the company need to have the following requirements​

  • Experience with server-side programming
  • Ability to solve complex problems
  • Experience in dealing with, diagnosing and optimizing problems
  • Comfortable with rapid iterations of software development
  • Passion for technology
  • Effective communication skills
  • Strong execution skills

Responsibilities required of all back-end engineer roles in the company.​

  • Develop and iterate on products towards security, stability and high performance
  • Ensure product quality
  • Solve problems with complexity
  • Recognize team and product deficiencies and propose solutions
  • Work effectively as a team

Performance Metrics for Backend Engineers​

  • On-time and complete delivery rate of Issues
  • Average time to fix and average time between failures
  • Engineering MR rate
  • Technical contribution

Front-end Engineer (WEB direction)​

The Back-end Engineer (WEB direction) will be responsible for the WEB part of our products and the development of our internal systems, working with product managers and back-end engineers to accomplish common goals.

All Front End Engineer (WEB direction) roles at #### require the following.​

  • Strong understanding of semantic HTML, CSS and core JavaScript concepts
  • A solid understanding of core Web and browser concepts
  • Expert experience with modern JavaScript web frameworks (React, Angular, Vue, etc.)
  • Experience addressing, diagnosing problems and optimizing issues
  • Comfortable with rapid iterations of software development
  • Passion for technology
  • Effective communication skills
  • Strong execution skills

Responsibilities required for all front-end engineer (WEB orientation) roles in the company.​

  • Develop and iterate products towards a secure, stable and high performance approach
  • Ensure product quality and good user experience
  • Solve problems with complexity
  • Recognize team and product deficiencies and propose solutions
  • Work effectively as a team

Performance metrics for Front End Engineer (WEB direction)​

  • On-time and complete delivery rate of Issues
  • Average time to fix and average time between failures
  • Engineering MR rate

Objective/Direction​

In the second half of 2021, we want to optimize the ENG development area, complete the expansion and reorganization of the engineering department, improve development effectiveness in general, and make rapid progress based on this quarter's OKR.

First, we need to know our current status. In the past year, we have actively promoted the practice of OKR in the company, the construction of internal knowledge documents (Handbook), the form of team interaction, the restructuring of the department, the construction of the company's effectiveness, the effective expansion of the team program, has been basically built, and the company is currently working in an orderly manner based on this. In the next year, the number of hires will increase exponentially compared to the last six months. A reasonable and effective team expansion is an extremely important decision. Considering our current product development goals and plans, we need to expand the back-end group by 4 core developers and the front-end group by 2 core developers.

In order to achieve the goal of effective team expansion, we have developed and validated our hiring process, and at the same time optimized our onboarding process, based on the competency ratings of different members, and will complete job transitions as appropriate.

is reflected in the following​

  • Develop a hiring plan

  • Start recruiting

  • Resume interview scheduling

  • First week of company information synchronization, work style training, rules and regulations

  • The next week of communication between the team, confirm the development direction, divide the simple type of work to practice, and gradually step into the regular work, to complete the transition

How we work​

We use Epics, Issues and Issue Boards to organize our work as they complement each other. All work task sources are based on the team OKR planning landing. This is the core goal of the work.

Added as a sub-level to the top Epic is used to describe the projects undertaken by the team. Having all projects at this level allows us to prioritize using a single list and allows us to prioritize work from different services alongside each other. Projects are prioritized based on the OKR for the quarter. Project status is maintained at a glance in the description of the top Epic.

Project assignment​

Engineering is the DRI for mid/long term team efficiency, performance, security (incident response and anti-abuse capabilities), availability and scalability. the expertise to proactively identify and iterate on these belongs entirely to the engineering team. And the product can support the performance issues identified by the customer. In some ways, these efforts can be seen as risk mitigation or revenue protection. They also have the characteristic of being larger than a group at the stage. Developers want to conduct an experiment that focuses on initiatives that should help the organization scale appropriately over time. We think of these as percentages of time investment associated with a phase or category. The percentage of time invested can be thought of as a priority budget outside of the normal product/development allocation.

How to add workload to engineering assignments

One of the most common questions we get as part of this experiment is "How do I include issues in my engineering allocation list?" . The short answer is that someone makes a suggestion and we add it. Just as everyone can contribute, we want the feedback loop for improvement and long-term goals to be robust. Therefore, everyone should feel entitled to make suggestions at any time.

To help get items on the list for consideration, we will conduct periodic surveys. The survey will include questions such as.

1, If you were paid 1% of the engineering development fee per release to work on something, what would that be?
2, How would you justify it?

We will maintain a short list of questions to solicit the most input. The survey will be conducted for members of the development, quality, and security departments. After obtaining the results, we will consider possible items to add as engineering assignments.

While our projects and company prioritize speed, we must prioritize one set of things: product availability and safety.

In addition, we will hold regular checkpoints for engineering assignments. The recommended cadence is once a week.

Collaboration Model​

The way we work remotely and asynchronously makes it hard to know when we need to collaborate. Here are some things to consider.

  • Keep in mind the pros and cons of synchronous and asynchronous communication. Either is fine, but fit is best.
  • Everyone on the team has the mindset to stay responsive to requests for collaboration. -We have daily morning and evening meetings. We have daily morning and evening meetings, where we synchronize work goals and communicate work content at night. If we encounter any problems in our daily work, we will ask questions in the corresponding groups, and the people related to them will be able to respond positively. In addition, there is also a weekly meeting to summarize the work content of the week, discuss the problems encountered by the team this week

Division of responsibility​

The company's applications are built on top of many shared services and components, such as PostgreSQL database, Redis, Prometheus, and so on. These services are tightly integrated with the code base for each function. Often, DRIs need to be identified as requirements arise, whether they are feature requests, event escalations, technical debt, or bug fixes. The following guidelines can help one quickly find the best people who might be able to help on this topic.

  • Members of the collective are regularly synchronized and made aware of each other's common interests. Problem areas are identified and formalized in the collective, but are not recorded in the collective backlog. Instead, the assigned DRI should submit the task to the team with the greatest need to solve the problem. This is to ensure that work is distributed fairly and that no two backlogs are competing with each other in terms of priority.
  • Collectives work best when they are made up of different individuals from different product and engineering areas. They double as knowledge-sharing centers, first exchanging information from cross-teams within the collective and then passing it back to specific teams by individuals
  • Teams that implement specific functionality or take advantage of certain features of a shared service are responsible for their change from local development environments to production deployments to ongoing maintenance after deployment. No single development-wide DRI owns part or all of the shared services

Project Management​

The product is responsible for guiding the direction of our product, and the technical person is responsible for guiding the technical architecture to meet these requirements. Engineering managers should be involved in both of these conversations. Consistent with these conversations, the engineering manager's primary responsibility lies in project management: ensuring that their team is in the best position to achieve both goals as effectively and efficiently as possible.

  • Capacity Tracking/Planning - While onerous estimating methods do not fit our way of working, it is your responsibility to keep a close eye on your team's capacity. This allows you to forecast capacity, which helps with product planning, and also allows for earlier identification of issues if important plans may be delayed.
  • Collaboration with Stakeholders - In addition to the product manager and team members, you are the primary contact for any other stakeholders in the work being done by the team. You should expect to take the time to communicate clearly and thoroughly about the status of ongoing projects.
  • Be aware of the status of your team. Change can happen quickly - the better you understand what your team is doing and how it is proceeding, the better you will be able to make the best decisions.
  • Balance engineering plans- Make time for engineering-led plans to be balanced with the team's product needs.

Data Tracking​

With gitlab and internal BI systems, you have a clear picture of your work progress and can make adjustments when things go awry. In addition, to ensure the project can be carried out as expected, we will synchronize the work progress once a day to further track the project data. In addition, data is one of the most important reference indicators to improve the effectiveness of the team

Please refer to the section for Team KPI and Project KPI