The world is mobile. Given this and that our software leads the industry in helping organizations provide secure mobile applications, this job is of paramount importance. Consequently, the demands are high, and excellence is expected. Only the top 90th percentile will be found in our engineering team. To qualify, you will need a long experience and a broad range of skills.
With a bar this high, we can assure you that you will grow. Your craft will be honed, and after just a short time, you will see improvement in your abilities. Good ideas are the boss of Curity, so if they are yours, you will lead. As the only dedicated app developer on the team, this will often be the case, but sometimes it won’t. At such times, you will have to listen to and respect your colleagues. We always assume that our coworkers are smarter than ourselves and that they are right and we are wrong until we can prove otherwise with concrete evidence and a logical argument.
Deadlines are a fact of life, but more important than arbitrary points in time is quality. When building security software, the product must be solid, tested, and safe. For this reason, we work with “trains”. The train leaves the station every six weeks, and we release at that time. If a feature is ready, it’s merged to the main development branch and will ship on the next train. If it’s not ready, the work continues on an integration branch till it is. This working model allows us to provide consistent deliveries without sacrificing quality.
All features are verified by automated tests, even on mobile; manual tests are bugs in our view. We have 10’s of thousands of tests that run with each commit to dev, and 10’s of thousands more than run nightly and weekly. A growing number of these run on mobile devices. This helps ensure that things don’t break, but it does not mean that you’ll have to wait around all day for feedback. Our builds and tests are done in minutes.
It does mean, however, that you will have to write tests — lots of tests. We use Behavior Driven Testing (BDD) primarily, which you should be familiar with already. The level of scrutiny and testing our product undergoes is probably over and beyond what you are used to. Upgrades, breaking changes, documentation, and security are often afterthoughts in enterprise software. That never happens at Curity, and our focus is on excellence, repeatability, and stability.
Keeping track of changes is important. Source-level changes are managed with git. We rendezvous at Bitbucket, where we also review every substantial change (ones greater than 4 lines) in a Pull Request (PR). Every PR needs at least two approvals, so you’ll need to get people to help you check your work. This is always easier if you have beautiful, DRY code, proper formatting, tests, docs, and comments.
We also specify what changes should be made in Jira tickets. These go through a process of acceptance and refinement. Upfront design work follows a very lightweight process. We often design things by talking and then type it up in a Jira ticket. If it’s more complex, we will write an architectural description of the problem. We often spike out such challenging parts.
We start our mornings with a standup meeting where we talk about what we did the previous day, what we plan to do today, and if we’re blocked or not. These aren’t reporting meetings for a manager; they’re for you to keep in sync with your colleagues. You’ll need this because things move fast at Curity! During the day, we chat on Slack. Some people don’t like this, and feel it impedes their concentration and productivity. Fair point, but it will be hard to avoid. So, if this is challenging for you, be warned; you’re gonna have to overcome it. Also, if you’re a slow typer, you’re gonna lose arguments. So, learn Dvorak! We’re an English-speaking company, so your verbal and written skills in this language need to be excellent.
We are in the process of launching our new hypermedia API; it’s undergone two betas and a release candidate so far. This has forced us to build Android and iOS SDKs. These are low-level SDKs that are essentially wrappers around an HTTP client. These have to be further developed, and atop these, we plan to build other SDKs that will make it easier to do more with the API. These will handle things like hypermedia representation processing and presentation / UI logic. Eventually, the API will need to be revved, so upgrades and version negotiation will be required. There’s a lot of mobile development work to do at Curity, so you’ll be busy!
If, after reading all of this, it sounds like a fun place to work, please apply to the right. The process is front-heavy, so be prepared. If you get by the first few gates, it’ll be easy and welcoming by the end.
- Understanding of Java and Kotlin as they relate to Android programming
- Swift programming know-how
- Deep understanding of Android and iOS SDKs and APIs
- Experience shipping frameworks with Cocoapods and Swift Package Manager
- Automated testing with Fastlane, Android SDK, and Jenkins
- Knowledge of the different levels of REST and what hypermedia is
- Enough Ruby know-how to keep out of trouble
- Ability to maintain, improve, and create new open source examples and starters
- Familiarity with documentation generation from API source code
- Blackbelt in Xcode and Android Studio
- Excellent verbal and written communication skills in English