Hiring Process

From Status Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

Hiring is one of the most important things at Status to ensure a strong and stable community and culture. Building the core team of contributors requires finding applications with the right balance of motivation, knowledge and value for an open culture.

Hiring Criteria

The attributes to assess candidates for Status should follow 4 criteria:

  • Analytical Ability
    • Is the candidate able to think critically?
    • High vs low resolution of thought. Shallow vs deep idea generation.
  • Role Related Knowledge (RRK)
    • Ensure that the candidate has the experience and knowledge to be able to successfully fulfil their role
  • General Cognitive Ability (GCA)
    • How smart is the candidate?
    • Think ”Always hire someone smarter than you!”
  • Community receptivity/engagement
    • Engagement with the project - communication, idea generation and self ownership. Passionate about Blockchain (and Status preferably)

Candidate Scoring

Each interviewee should insert a a score and a recommendation summary for each candidate, including a definitive score on each of the above areas

Feedback Review.png

If you are unsure about a candidate, remember how important your decision is to maintaining Status' culture. Err on the side of false negatives, instead of false positives.

SWE Interview Process

As an Open Source community, Status is uniquely positioned to include all applicants in the project as part of the interview process.

Engineering Introduction

The 30m engineering introduction should cover the following:

  • Development style inside of Status (e.g. GH, Idea Meritocracy, Slack as a communication)
  • The open culture (e.g. flat hierarchy, blurred lines between core contributors and community)
  • The perks of working at Status (e.g. remote work, your own hours, offsite twice a year)
  • Next steps in their process (i.e. Submit 2+ PR so that the team can see how the candidate works with the rest of the team. The candidate can use Status Open Bounty to find PR's and get paid at the same time)

Questions to ask:

  • Why does the candidate want to work at Status?
  • Have they worked on Open Source projects before?

Be sure to leave some time at the end (~6-8m) for the candidate to ask questions.

Closure/Go Software Engineer:

  1. Candidate submits application
  2. HR Screen
  3. Intro interview with engineer
  4. Candidate is requested to send a minimum of 2 Pull Requests from a Status Repository or Status Open Bounty.
  5. Team member who merged Pull Requests are consulted to provide feedback on code quality.
  6. Leadership interview

For software engineering interviews that are not able to find relevant space in the repository or on Status Open Bounty, they can submit an application with a Github link in order to see relevant work in the applied field.

Tester Inclusion Activity

After candidate submits their application, there will be multi-stage inclusion activity for the candidate to familiarise themselves with the work environment:

Part 1 - General Testing Expertise


  1. It’s a mobile app with lots of functionality to send/receive messages, so you’ll need at least 2 mobile devices to effectively test it. Ideally, it’s 2 real devices. Acceptable: 1 real/1 emulator. In the worst-case scenario, 2 emulators.
  2. For Android emulator you can install trial Genymotion version (please, use any phone with Android 6 or higher)
  3. To learn the app you can read User guide

Stage 1:

  1. Download the Status app from the Google Play Store for Android or from the TestFlight for iOS (to get invite for TestFlight share you email with HR). For installing on Android emulator: 0.9.12b version
  2. Find 3 bugs in the application, that are not reported yet in the Github Repo
  3. Report them into the same repo as above, according to the template inside the issue creator
  4. Candidate to send links of the reported bugs to HR

Stage 2:

  1. Execute test cases (link), download app from the same source as in Stage 1
  2. Propose at least 2 improvements for the test cases you've executed: describe them in a free form and send to HR

Stage 3:

  1. Create a functional test design for a `send` command that is used to send ETH in the chats (/send). It should highlight as many test ideas as you can generate to verify that send command works. It can be any form you like that can be shared online and accessible without installing extra software (e.g. Google Sheet, online mind map, etc.). No need to describe its UI (e.g. no need to list that command is grey in the input field or there is a green sticker in the sent message, etc). Only ideas to check the functionality are expected. For example, for another command 'location' such ideas would be:
    • can send existing location selected on the map;
    • can send location if type some address and select it from the suggestions;
    • can copy/paste coordinates if long tap on sent location command,
    • can’t send if type non-existing address -> no send button shown.

Send the link to the ideas doc to HR.

Stage 4:

  1. If stages 1-3 are OK then schedule a pair-testing session with one of the testers from the team (via HR).
    • It will take ~1 hour and you will test together some new feature or a bug fix.
    • You should have good enough internet connection to share the screen where emulator is shown or a real device screen (e.g. screencast with AirDroid or Reflector2). This should be ready before session starts.
    • You'll get link(s) to the issue(s) on GitHub and the apk file 10 minutes before session starts.
    • During the session, tester will answer extra questions you might have about the functionality or the bug to be verified. He/she can also assist if you need extra contact to be added and interact with your contact in the app. You need to lead a session and show how you would approach the task, so at the end of the session you can tell "bug is fixed"/"bug is not fixed because ..." or "feature is implemented"/"feature is not implemented because...".

Part 2 - Test Automation Expertise

  1. Set up local infrastructure according to guide (automation framework can be found by the link)
  2. Describe how IOS client testing could be implemented in the automation framework.
  3. Create test according to scenario below and submit your PR:
    • Create 2 users from scratch on 2 devices
    • As user A, add user B to contacts 
    • As user A, send several messages on several different languages to user B
    • As user B, verify that all messages received and displayed correctly

DevOps Inclusion Activity

After candidate submits their application, there will be multi-stage inclusion activity for the candidate to familiarise themselves with the work environment:

  1. Status Open Bounty uses the same testing and production server.
    1. How would you change this setup?
    2. How would you implement monitoring for a production website and for production server?
    3. What will be monitored on the production server?

Smart Contract Inclusion Activity

Write the code (deployable to the EVM), publish it on GitHub (public or private) and send the link to the repo. Please include any additional information you consider important.

The code we are looking for could be conformant to the following interface. Feel free to remove/add any functions as you see fit:

// For the sake of simplicity lets assume EUR is a ERC20 token
// Also lets assume we can 100% trust the exchange rate oracle
contract PayrollInterface {
  /* OWNER ONLY */
  function addEmployee(address accountAddress, address[] allowedTokens, uint256 initialYearlyEURSalary);
  function setEmployeeSalary(uint256 employeeId, uint256 yearlyEURSalary);
  function removeEmployee(uint256 employeeId);

  function addFunds() payable;
  function scapeHatch();
  // function addTokenFunds()? // Use approveAndCall or ERC223 tokenFallback

  function getEmployeeCount() constant returns (uint256);
  function getEmployee(uint256 employeeId) constant returns (address employee); // Return all important info too

  function calculatePayrollBurnrate() constant returns (uint256); // Monthly EUR amount spent in salaries
  function calculatePayrollRunway() constant returns (uint256); // Days until the contract can run out of funds

  function determineAllocation(address[] tokens, uint256[] distribution); // only callable once every 6 months
  function payday(); // only callable once a month

  function setExchangeRate(address token, uint256 EURExchangeRate); // uses decimals from token

Non-SWE Interview Process

For non-SWE interviews, there will be a more traditional hiring process. This includes:

  1. CV screen
  2. HR phone screen
  3. Inclusion task (outlined below)
  4. 45m interview with functional lead (Design/PM)
  5. 45m Operations interview (i.e. Nabil)

Inclusion Activity


  1. Pick a topic outlined in the Status White Paper
  2. Write a 2-3 page mini-PRD. The document should outline the user problems to be solved, product overview, success metrics and more. (See "Top Highlights" example on this page to get an idea of what to focus on)


The UX inclusion activity can be one of the following:

Be sure to outline the user journey being solved, and some principles behind the design


The UX Research inclusion activity includes. First, pick a topic outlined in the Status White Paper (e.g. Core Application, Status Open Bounty [aka Commiteth], Status Teller Network, Sticker Market, Discover etc.)

Perform one of the following tasks in a 1-2 page document:


Create a project brief (1-2 pg document) for one of the topics outlined in the Status White paper which outlines the following:

  • Project Background and Goals (i.e. Why are we doing this?)
  • Project Target Audience
  • Key Project Challenges
  • Strategic Approach (i.e. what is the goal of the project and how will we achieve it?)
  • Project Requirements
  • High Level Project Timeline


  • Pick a topic outlined in the Status White Paper
  • Write a 2-3 page strategy document outlining key partnerships and growth strategies for Status

Technical Writer

  • Take a look at https://github.com/status-im/nimbus and in 1-2 pages, describe the main areas of support that a Technical Writer could provide towards this project
  • Provide examples of previous technical writing

Technical Program Manager

  • Check out the Status Ideas repo (https://github.com/status-im/ideas/issues). In 1-2 pages describe which processes and improvements you would propose to the development team in order to:
    • A) Improve efficiency of the decentralized team
    • B) Ensure the most important features are built first
    • C) Make sure team deadlines are met

Hiring Committee

Once a week, the Status support team will meet and review each candidate to be hired by the company.

There will be the final go/no-go decision making process for each candidate, which will then be communicated to the candidate by HR.