5 Things To Look For In React Native Developers
5 Min Read
You want to build an app. You want to build it in React Native because it’s the streamlined, agile way to do it. You now want to hire the talent.
But what makes a good React Native developer?
The key is that React Native is a fast maturing ecosystem, heavily supported by the likes of Facebook, Walmart and Airbnb. It is growing ever more powerful, and as students of Darwin will know, in a fast growing ecosystem it’s all about the survival of the best adaptors. Those who thrive on change and competition will succeed, those who can’t, literally get eaten.
You’re going to need successful devs who thrive on agility, here’s what to look for:
A technical front end developer will have in their CV a background in computer science and/or experience in objective based languages. These devs will have a better understanding of engineering as a whole, and the broader disciplines will enable them to build mobile apps which work well with the wider world. They’re holistic and adaptable, like pigeons.
Plus, as your company starts developing apps in React Native which are more bespoke, you may need to delve into native development in order to meet requirements. We experienced this with our app for Imperial Hotels, we had to build bridges in Java and Objective-C to access lower levels of functionality within the phone. You want your own devs to have that capability too.
And you need other hard skills: your React Native developers should demonstrate experience with APIs, that they know how to plug into the relevant APIs. A bonus on top of that is an ability to communicate well with your backend developers - should you need them to.
You can have a brilliant developer, but if they’re not used to working in a team, the butterfly of individual style will cause a hurricane of team conflict. The congealed custard of obstinacy will grow the furry mould of delayed releases.
If you’re interviewing a single developer, ask them to take you through their approach to testing, peer reviews and pull requests. You’re looking for someone who can look at the code produced by other members of your team and adapt to their code styles, not plough on inflexibly. Adapt and survive, make Darwin proud.
For teams and agencies, you also need to ask the above. Getting four developers to adapt to your business is harder than one, but they should be much more experienced in doing so.
As important as individual skillsets are, to distinguish between decent dev teams and outstanding dev teams, look at their team structure. Leicester won the Premier League with a perfect team, not with perfect footballers.
Teams should have defined roles with defined specialists in those roles.
At Solid State Group we split the teams into three defined roles: designs, function, application. One specialist designs static prototypes, mock-ups and so on. One specialist makes the designs functional, sets up the navigation, the routing etc. And the third specialist applies these to the functional screens.
Other agencies will have different structures, but good practice is to look for the specialists and the roles that they do: do they have a dedicated designer? A highly technical developer? Or are jack-of-all-trades pretending to specialise?
These role divisions are important because front end development is expanding, taking on more duties and areas of expertise. Where once they were design-focused, front end developers are encroaching on full stack developers in terms of technical ability.
This is especially relevant if your organisation already has the designs signed off internally - you’ll need the technical roles to take the project and run with it.
So you’ve found a team of devs with design and technical specialists, objective-based backgrounds, and they even have the emotional intelligence to adapt to your organisation.
There’s just one more thing you need to thrive in the eat-or-be-eaten world of technology.
One more thing to go from dodo to golden eagle.
Can the devs see the bigger picture?
At Solid State Group, we don’t just trot out some code. We ask ourself, is this the best solution out there for the client’s business? Or, actually, could we do this worse?
We could spend months building the 100% vision from the client, or, point out how we can achieve 80% with 20% of the effort - and save a ton of time and money. Why?
Because all software development is a balance of trade-offs, doing one thing limits another, so a team who can understand the commercial case can make sure the balance of trade-offs falls in the business’ favour, and sometimes, that means doing less than actually asked, and sometimes, much more.
Finally, one more concrete thing to look for in React Native devs: how do they keep up with innovations in React Native?
New components for React Native are released every week, your team should know where to find them, and when to try the new stuff out. Ideally, they can point you to their own contributions to the framework, code repos and so on. SSG have tons of React Native repos on Github, our Firebase authentication has over 100 stars.
To get you started, check out these components we think are most important for React Native. For now.
Ask us again in 12 months for the new list…
React: candidates should be able to demonstrate core React concepts such as:
-The ability to use pure components and make standard components performant with the function ShouldComponentUpdate.
-Initial state, default props and when to use props vs state
-Proptypes for well documented components
- Moment.js: it handles everything to do with the manipulation and display of dates
- lodash / underscore: common utility libraries
- fetch, or your preferred library for making API requests
- NPM: General knowledge of this node package manager is vital as it is used frequently day to day. Bonus points if your team has published their own package
- Redux / flux: Bigger applications will need to manage state and a lot of these libraries are similar - but the main thing is that your team can explain the flux architecture.