Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Remote] Gear is looking for Rust engineer #96

Closed
xrdavies opened this issue Mar 14, 2022 · 1 comment
Closed

[Remote] Gear is looking for Rust engineer #96

xrdavies opened this issue Mar 14, 2022 · 1 comment

Comments

@xrdavies
Copy link
Member

About

Gear is a Substrate-based smart-contract platform that enables anyone to deploy a dApp in a matter of minutes. Gear is the most cost-effective way to run smart contracts that have been compiled from many popular programming languages, such as Rust, C, C++, and many more. It ensures very minimal, intuitive, and sufficient API for running both newly written and existing programs on multiple networks without having to rewrite them. Smart contracts are stored in the blockchain’s state and are invoked, preserving their state upon request.

Gear is planning on becoming a parachain in the Polkadot and Kusama networks to host smart contracts on these respective networks. This will mean that by deploying on Gear, developers would be able to take advantage of all the benefits of the Polkadot and Kusama networks and ecosystems at a minimal cost.

Gear will assist with the transition to mass use of Web3 technologies by enabling the running of innovative dApps, microservices, middleware, and open APIs.

https://gear-tech.io

Responsibilities

We are looking for someone experienced with high-performance and high-secure code practices. We code in Rust.

Requirements

  • Rust or several years of C/C++ experience.
  • Compiler internals experience
  • Understanding of virtual machines.
  • Good computer science fundamentals

Nice to Haves

  • Cryptography is a +
  • English for communication

Quiz

Implement basic function to split some generic computational work between threads. Split should occur only on some threshold - if computational work (input length) is shorter than this threshold, no splitting should occur and no threads should be created.

You get as input:

1. Vec<T>
2. Function f(t: T) -> R

Threshold can be just constant.

You should return:

  1. Up to you, but probably some Vec of the same length as input(1)

Code should be published on github.

Job Nature

  • Full-time
  • Remote

Salary and Benefits

  • More than a competitive salary.
  • Cutting-edge technologies and projects
  • Equity in shares and tokens.
  • Conference budget.
  • Team retreats all over the world

Work Location

  • Moscow
  • China (Remote work)

Contact

@github-actions
Copy link

欢迎您提交招聘信息,Rebase 会整理招聘内容,通过公众号发出。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants