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 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. You can test any of the following builds::
    1. Download latest released version of the Status app from the Google Play Store for Android or subscribe for the TestFlight invite for iOS. For installing on Android emulator: 0.9.25 version (check what version is available on PlayStore/TestFlight and request the same from HR if link is outdated on this page)
    2. Latest nightly build unless it contains major issues like can’t launch app, create account, send messages or funds. If basic operations are fine - it’s OK to report bugs for Stage 1. Important: always mention the source used to install the build e.g. installed nightly from http://artifacts.status.im:8081/artifactory/nightlies-local/im.status.ethereum-011n7e-n-fl.apk version 0.9.25(6060). Latest nightly link for Android can be found here If you proceed to test next day then install new nightly, please. Do not re-use same nightly build for several days unless link was not updated on https://status-im.github.io/nightly/ , usually it contains new nightly each European morning :)
  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, please follow Bug_Report guidelines
  4. Send links of the reported bugs to HR
  5. You can apply for participation in Bug Hunting sessions, so your bug reports might be paid with SNT. Join "bug-hunters" channel in Riot to ask for details. Also can read about past session 1 here.
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 `Send transaction` functionality in the Wallet. It should highlight as many test ideas as you can generate to verify that send 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 icon is shown next to Ether or there is Advanced section hidden by default, etc). Only ideas to check the functionality are expected. For example, for Recieve transaction such ideas would be:
    • can request from contact who didn't add me to the contacts
    • can request 0 ETH
    • can request more than contact has
    • can't request not valid amount, e.g. "3,,5" -> Send Request button is not active.

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. Create an automated test to cover one of scenarios and submit your PR. These are real bugs to be added to the test automation suite, you can pick any from Open or from Closed issue list. There are 2 expectations from the PR:
    1. PR title should start with [TESTS]
    2. PR description should contain test steps and verifications that are implemented.
  3. Take your test design for `Send transaction` functionality from Stage 3, General Testing Expertise. Which of ideas you would not add to the test automation suite? Please, explain the reason(s). Share the link to the results with HR.
  4. If stages 1-3 are OK then schedule a session with one of the testers from the team (via HR).
    1. It will take ~1 hour and you will implement new autotest together.
    2. You should have good enough internet connection to share the screen and use audio/video.
    3. You should have local infrastructure ready and working before session starts.
    4. You'll get a link to the GitHub issue that should be covered with autotest 10 minutes before session starts.
    5. During the session, tester will answer extra questions you might have about the functionality or the bug. You need to lead a session and show how you would approach the task, so at the end of the session there is new working autotest.

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
   /* ORACLE ONLY */
   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 this 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:
    • Improve efficiency of the decentralized team
    • Ensure the most important features are built first
    • 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.