REACTjobsboard

Senior React Developer

React jobs at TrainerRoad

TrainerRoad

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."  They will be full-time employees of TrainerRoad and will join a cross-functional pod on an established remote team.

Areas of work include React, TypeScript, Electron, and React Native.

App Development
We're recently re-written our mobile and desktop apps in React/RN with Typescript.  It's a solid codebase (it can always be better) and we strive to add to it without making it exponentially more complicated.

Our goal of the re-write was to increase the speed of app development. We did this through hot module reloading, 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 as quick as possible.

Our website is built in Angular 2+ and there's the opportunity to work on the web in Angular, although we will be migrating this to react in the future.

This job is primarily for React (on Electron or web) and React Native app development.

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 are 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 hot module reloading.

- 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
Oftentimes 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.
- We are organized into cross-functional pods of 6-10 people with their own Product Manager. They work on a feature across platforms.
- We run two-week sprints. The web/app team reviews, estimates, and discusses all sprint issues before they are free to be worked on.
- We often pair-program.
- Our engineering, marketing, and design team are remote.
- We have a skilled design team that handles the HTML/LESS for the apps and websites.

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
React
Redux/Mobx
Typescript
Git
Web Application Experience (interactive web pages)

Optional Technology Experience
React Native
Electron
Native iOS/Android
Angular
C# (We use this on our web backend)

Work Remote or in Reno, Nevada

We're looking for the best candidate we can find. Don't let a little thing like geography get in the way. Over half of our development team works remotely. It works very well with the help of Slack, Screen Hero, and Github.

We expect remote employees to overlap at least 4 hours with the Reno, Nevada office (we're there 8am-5pm Pacific time).

Salary
We're looking to hire engineers at 110k USD per year. We can tie that to USD or your local currency (your choice).

Perks
- Unlimited Vacation
- Flexible schedule
- Fast computers
- Access to the latest fitness devices (power meters, trainers, sensors, etc.)
- Co-workers you can learn from

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.

FAQs

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 6 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. The 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.

We try to work as pragmatically as we can. We have excellent designers on staff who go from mockups to responsive HTML with light javascript work.

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 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 on board, 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.

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.

TrainerRoad is an equal opportunity employer.
TrainerRoad believes that Black Lives Matter and is proud to have raised $64k for the NAACP Legal Defense Fund.
You can view our core values here.

Apply for this job