I recently had a conversation with a recruiter that went more or less like this:
- He: Are you available for a project?
- Me: What kind of project?
- He: I have one React project and one Angular project
In my head, I have trouble classifying projects in terms of the specific front-end frameworks that power them. We’re using technology, sure, but what are we using it for?
My ideal client knows the answer to the latter question and leaves implementation mainly to the team. The longer I’ve worked as a front-end developer, the more I’ve realised that specific technologies don’t matter that much, especially in projects that run for more than a couple of months.
Anyone can learn how to operate a gearbox or figure out how to reverse in a specific type of car. But where are we driving to? Ok, silly metaphor, but hopefully it gets my point across. We’re putting stuff on the people’s screens. It’s mostly about what and making stuff that matters, but those are (mostly) not front-end things.
Front-end wise, I think these things are probably key:
- are we making a fast website, i.e. do we optimise assets and avoid sending unnecessary bytes to the client?
- are we making a usable website, i.e. have we provided ease of use, rather than confronting our users with problems resulting from our complex business logic?
- are we making a website that doesn’t exclude people, i.e. do we have all users in mind when hiding and showing content and is our interface keyboard accessible?
I don’t want to be all millennial and display overly unrealistic idealism, but these things seem quite basic to me. Why strive for less? Of course, in actual interviews, it would be interesting to gloss over technologies to use to reach those goals, but I can’t see how filtering for them works as a recruitment strategy.
In order to find good people to solve your development problems, problem-solving and people skills are probably going to help much more than previous experience with specific tricks of the trade.