React Developer (React, TypeScript, Mobx) at Trainer Road, LLC (Reno, NV) (allows remote)
Posted 3 weeks agoApply Now
Do you do your own dishes? We've got a job for you (and it's not dishwashing ;-) ).
Do you put them in the sink and expect someone else to do them? Move on, please.
Do you get pissed (in a professional way) when someone else leaves their dishes in the sink? Please apply!
TrainerRoad is looking to expand our engineering group. We're looking for smart software engineers who "get things done." We’re interested in remote candidates in the USA or candidates interested in working in our Reno office.
Areas of work include React, TypeScript, Electron and React Native.
We're moving our apps from cross-platform Xamarin to Electron/React Native. You'd be involved in this process and would work with an experienced engineer(s) to rebuild a section of the app.
Our goal is to increase the speed of app development. We do this through HRM, fast computers, a great build chain, automated testing, clear and well-defined issues and a dedicated QA team that tests every PR.
We track what our users do, learn from that and improve the product. We want this loop to be a quick as possible.
Our website is built in Angular 2+. With our move to React on the app side we'll be making new elements in React on the web.
This job is primarily for Electron (using React) and React Native app development, but there's room for someone to move to the web in the future or split their time between web/app.
Engineering Principles we believe in
- Write good code, but not necessarily great code.
Good code ships, great code gets "tinkered" with and debated about ad nauseam.
- Good code is understandable.
We admit it, we've made things too complex in the past. We've had complex class hierarchies and really shown off our CS skills.
Sure, there's fewer lines of code, but it takes someone a few days to figure out what's going on and it's easy to write bugs.
We believe in a few more lines of code for the sake of clarity and debugging ease.
- Good code is testable, and we're pragmatic about testing.
You don't get the same testing ROI for every line of code. We believe to test the areas that are most likely to break, are tricky or are likely to be changed. We still run thousands of unit tests per build, but we're not testing 1+1 = 2.
- Quick builds will set you free!
To be a successful engineer, you need to get into "flow" (more on that below) as often as you can. That's why we love HRM.
- We want just enough process to be awesome, and nothing more.
We have engineers review issues before a sprint for clarity and completeness. When they submit a PR there's always code review, UI/Unit tests run, then QA manually tests.
For the web, we automatically push every PR that's merged into Master.
For the app, we do weekly releases where there's a final regression test with all merged PRs from the previous week.
Our process prevents bugs/regressions and ultimately saves a lot of time.
- Long-running branches are the devil
Often times projects will take weeks/months before they are launched.
Instead of experiencing a merge/testing hell at the end of the project we encourage small PRs into master with a "feature flag" on the new project that allows employees to use the feature in production but not our users.
Cool Things we Do
- Every PR has a set of unit tests and automated UI tests run against it.
- Every PR is code reviewed.
- We have a dedicated QA team to manually check your PR (it requires four testers to sign off).
- Every web PR that is approved is automatically deployed (CI).
- We've got a beta system that has a flow of production data that helps you develop and test your code without worry of breaking things.
- Everything is hosted on Azure. There's plenty of dev/beta/test servers and databases to use.
- The web and app team have their own Product Managers.
- We run two-week sprints. The web/app team reviews, estimates, and discusses all sprint issues before they are free to be worked.
- We often pair program.
- The majority of our engineers are remote.
- We have a skilled design team that handles the HTML/LESS for app and website.
Who We're Looking For
We want smart engineers who get shit done! Not only do you have to be smart, but you also have to be pragmatic.
Let's say you need to paint a room white.
Smart and Pragmatic Engineer: A pragmatic engineer fills up a sprayer (rather than use a paintbrush), gets to work, and makes sure they don't paint themselves into a corner.
Smart Engineer (but not pragmatic): A smart engineer who's not pragmatic might design a system to change the color of the room in just 30 seconds. Sure, it would take 2 months to build the system but we could change colors so quickly! It's totally optimized for repainting!
If the second example sounds like you, please do not apply. We know it's fun to go hog wild in projects but we need to "get shit done". There's a whole line of other engineers and designers waiting for that room to get painted so they can do their own work on it.
We're a Team, not a Family
It sounds harsh to say, but we're not a Family. I know lots of businesses call themselves a family, but I think it's BS. If you get drunk at work and yell at someone, we're going to let you go (although we would give Grandma a pass at Thanksgiving).
It's better to think of TrainerRoad like a sports team. Everyone has their role and their jobs. It's our jobs as managers to bring new hires up to speed, train them in our system, and coach them to be successful.
If someone is not performing, we need to talk to them, coach them, find out what's going wrong and where we can improve. If someone just can't perform to the standard level of the team and we can't coach them to get better, we have to let that person go.
Another clear sign that you have a high-performance team is that if everyone would "enthusiastically rehire" each other for their current roles. It really makes work wonderful when you respect, trust and value your co-workers.
Required Technology Experience
Web Application Experience (interactive web pages)
Optional Technology Experience
C# (We use this on our web backend)
Web Charting Libraries
Work Remote or in Reno, Nevada
We're looking for the best candidate we can find in the US. Three-quarters of our development team work remotely. It works very well with the help of Slack and Github.
We expect remote employees to overlap at least 6 hours with the Reno, Nevada office (we're there 8am-5pm Pacific time).
We're looking to hire engineers for $100k/year. If you ask for more, we'll reject your application. If you're interested in the company please subscribe to our RSS feed at jobs.trainerroad.com for when a higher level job posting is open.
- Unlimited Vacation
- 401k with 4% company matching
- 99% of employee's individual health care paid (I know 99% is weird...it's an ACA thing, and it ends up being just a few dollars per paycheck) You can see a preview of what you'd pay here: https://www.zenefits.com/benefits-preview/?token=3733c1ac-fc72-420a-b224-d9a25bcc1e27
- Flexible schedule
- Access to the latest fitness devices (power meters, trainers, sensors, etc.)
Your Resume should have:
- Links to any open source projects you've contributed to (not required)
- Github/StackOverflow username if you'd like
- Examples of experience in the "Optional Technology Experience" area
Your Cover Letter should have:
- Let us know why you want to work for TrainerRoad
We also Require
The best engineers only want to work with other great engineers. We've found that the best way to find great engineers is to have them code, not just answer trivia questions during an interview.
That's why we require applications to do a refactoring exercise as part of their job submission. The right candidate won't find this a pain in the ass; it should be enjoyable.
This also weeds out the vast majority of candidates who just fire off resumes everywhere.
You can find the refactoring exercise here: https://github.com/trainerroad/RefactoringChallenge
It has a README.md with instructions.
Excited about our Company?
In your application let us know why you want to work with us and why you think you'd be a good fit for our company.
Do I have to be a cyclist to apply?
Nope! Not everyone in the company is a cyclist. It helps if you're an active racer but it's not required. If you are a racer or TrainerRoad user, let us know!
What's unlimited vacation mean?
The CEO of TrainerRoad used to be an engineer at a Fortune 500 company where life was a grind. We believe employees put out their best work when they are happy and not burnt out.
If your brain just isn't working at 3 pm, we encourage employees to go home and rest up. It does no one any good to sit and stare at the computer screen for another two hours. We don't track that time.
Employees generally shoot for around four weeks of REAL vacation time (no slack checking) but some take more, and some take less. The thing we care about is how productive you can be and how much value you can add to the company. Bottom line, we want people who are passionate and get things done. If you meet those requirements, everything else works itself out.
That being said, if you end up taking massive amounts of vacation, come in late, leave early and aren't producing outstanding work we're going to have a problem.
How do you work?
We're big believers in Deep Work and Flow. If you're not turning off Slack (snooze), going DND on your phone and shutting off the world for multiple hours a day you're probably not being as productive as you could be. The idea is a developer should be able to work on a chunk of work that they understand distraction-free for multiple hours totally. This is the only way the company moves forward.
Development uses Github with a strict pull request process. We test, comment, refactor and improve each other's pull requests.
We have a QA team (we call them the Test Team) that checks every PR and does full regression checks for each App release, and we're continually getting more automated.
We have an Automation Team that only focuses on writing UI tests to speed up testing and find bugs faster.
We can one-click deploy our app on Alpha, Beta, and Production channels.
We can one-click deploy our website to Azure (includes smoke tests and warm up).
We have nightly builds that deploy to Test Flight and Google Play.
We often pair program via Slack.
We work off bi-weekly sprint issue lists on Github.
Developers get the super fast machines and awesome equipment. If it's going to let you be more productive, we want to spend the money on it.
You didn't ask about education, what's required?
Please put your education on your resume, but we're not going to reject someone because they don't have a degree in Computer Science. We understand that some of the best and most passionate engineers are self-taught.
How long until I hear a response from you guys? What's the process?
If you don't follow directions in this job posting, you'll be immediately rejected.
If you did follow directions, our goal is to review your refactoring within a week of submitting your application. All refactoring reviews are done "blind"; meaning the reviewer doesn't know your name, resume or where you're from. Code is code, and it should be reviewed that way without bias.
If we like your refactoring, we'll have you do a coding logic quiz. Nothing super in-depth CS wise. We've found that the candidates who do the best on these exercises are very successful at TrainerRoad.
We'll take the top combined refactoring and coding quiz results and set you up for a team interview.
If the team likes you; we'll then set up a pair programming session with you and an engineer. We'll give you a tour of our codebase and work on a real issue. This gives you a chance to run away from our codebase screaming and also demonstrate that you can communicate with us.
If all of the above is good, you're hired!
I know this sounds like a lot of hoops to jump through, but it works so so well! Once you're onboard, you'll love that everyone else went through the same process and is up to "your level" in terms of "get-shit-doneness".
What's with the dishes analogy?
Doing your own dishes is a GREAT analogy for our culture. Don't leave shit around for someone else to clean up. Do your own dishes. Do you see someone making a mess? Let's discuss it (in a productive manner) so that we can nip that behavior in the bud.
We know we're really doing well when someone points out a manager not "doing their dishes" or causing an extra headache for a process that doesn't add value (it happens). Seriously, we need employees to call managers out on this. I'm the CEO writing this; please oh please tell me if I'm messing up or not walking the talk.
Want more detail about the benefits?
You can see a preview of TrainerRoad's health benefits here: https://www.zenefits.com/benefits-preview/?token=3733c1ac-fc72-420a-b224-d9a25bcc1e27
This is the longest job posting ever, when does it end?
Right now! Congrats if you made it this far! We look forward to looking at your resume and refactoring exercise.