Hiring Tech Talent for Startups in One Sprint: Part 5
Five Years Experience With Flutter
This might be the most relatable part yet for anyone who has ever searched for a tech job. It’s a widely known, serially mocked, universally consistent, globally adopted unhealthy obsession with years of experience. The one, inevitable ingredient in about every job description and candidate evaluation. “How many years of experience do you have with X, Y and Z?”, “Must have at least X years of experience with Y technology”. We are all familiar with this public call for professional stat padders, often by engineers themselves, which is what makes it all the more surprising. Any decent engineer would know how IT engineering works. On the one hand, practice makes perfect, but on the other hand, prolonged usage doesn’t guarantee mastery any more than prolonged usage of a soccer boot guarantees a successful career in soccer. To understand the problem with this vain metric, one has to visit the bottomline of startups. What exactly are startups trying to achieve at the core of their operations? Well, in generic terms, a possible response would sound like: “Providing a solution to the sauerkraut accessibility problem in the food delivery industry/space by building a platform/tool/system which facilitates easy ordering and delivery of sauerkraut” or something like that. The USP of a startup is to identify and solve problems in a given space. This naturally suggests that a lot of emphasis would be placed on problem solving skills and familiarity with the solution domain during the recruitment process. So far, the entire industry is somewhat in alignment about the correctness of the previous statement. A candidate is definitely appraised based on both their ability to make an impact on the general direction of the product(s) and their relevance to the specific impact entry-point. This alignment however completely goes off the rail when it comes to ability assessment and relevance metrics. The focus right now is on the latter.
Experience matters and helps a lot, and for pretty much everything and anything. An experienced driver would likely handle dire road situations better than an inexperienced driver, an experienced chef would probably produce a better tasting meal than an inexperienced chef, even biology supports experience. It’s possible to have more tolerance to certain physical conditions than others, just on account of being exposed to those conditions more. In all of these, experience directly corresponds to the deliverable or the bottom line of the underlying context, and while it’s convenient to attempt to map these examples one to one with engineering, it’s not quite as straightforward. It probably works decently well with defining a senior vs junior developer. It might be fair to say someone who has been solving problems for a longer time than another person is more senior to the other person. Not guaranteed, but all external conditions being equal, it’s a decent assumption. This is however not how experience is often defined in recruitment. The “problem solving” part is completely ignored and the nitty gritties are zoomed in. Slowly but surely, requirements somehow become rigid. There’s a checklist of the important pieces of technology being used to solve problems within the startup and the minimum amount of years an ideal candidate must have used those technologies for. We end up having: “Must have at least 2 years experience with terraform, at least 4 years experience with typescript. 3 or more years working with Selenium. At least 2 years with Elasticsearch and MySQL”. The problem here is that these are all tools. A means to an end. Familiarity with them is indicative of nothing but familiarity with them. Knowing how to write Typescript makes you a problem solver the same way knowing how to use a screwdriver makes you a carpenter. These vain indicators just say what you can use, probably off the top of your head at best, giving a decent signal as to how fast you might become comfortable with the existing tools, but absolutely nothing about how good you are with the bottom line of problem solving. Yes there’s an interview to assess problem solving abilities, but this rigid filter already takes out many qualified problem solvers just because they used DynamoDB and not Elasticsearch. Personally, if one has the brain capacity to understand and use a programming language, that’s more than enough proof that they can come to speed with any other language or supporting tool.
There are so many tools in tech, that in a 60 year career across 60 companies, it’s still highly likely that no two companies would have a 100% overlap on tools and technology used. A new one comes up every other week and there’s always something more efficient or cross-functional being built. If it has documentation, it can be used.
A tool is used to solve problems. That’s it. If properly documented, it can be used by anyone. If 2 years experience with Elasticsearch is so important, who were the first adopters of the technology when it was built and how did they get 2 years experience from day 1? The amount of tools that come up every year make it increasingly obvious that it’s a better investment of effort to assess a candidate’s ability to adopt a well documented technology as opposed to their familiarity with the technology beforehand. If it doesn’t matter with new tools, it never really mattered. There are way too many technologies to expect candidates to have even an 80% overlap in the first place, talk less of having used them for a specific minimum amount of years. I’ve seen interviewers prefer a candidate over the other just on account of familiarity with a specific npm package. Again, deviating from the bottom line and obsessing about the nitty gritty details that don’t necessarily imply competence in the bottom line, is a recipe for bad hiring outcomes. Think of it as considering a chef incapable because they never used an induction stove.
The most interesting part of all this is the fact that we all learn a new technology every 2 years or so. Imagine not being able to get a particular job despite having 8 professional years of problem solving, just because you’ve only used Azure for 1 year and AWS for 7 years. It’s reasonable to expect more from someone whose primary job is with and about that specific tech, but as a tool or “part of the tech stack”, the proven ability to learn and work with complex technology should be sufficient proof that they can navigate whatever the tech stack looks like. I guess the next question is: where is this unnecessary bias being made? Job descriptions have somewhat channeled this feedback a bit better. A lot of descriptions now state some degree of flexibility with how well candidates are expected to match with the company’s tech stack. The interview process however, doesn’t always align with this. The reasoning behind hiring decisions does not reflect this. It reflects a bias for familiarity over competence. Don’t get me wrong, familiarity should definitely be an advantage, but only as a tiebreaker. It should not add points to a candidate’s interview performance evaluation only on account of a faster onboarding. There are far reaching homogeneity consequences of this bias interviewers often tend to have, both within the company and in a bigger picture across the industry. Startups are so fast and innovative partially because of their flexibility to build and adopt the right tools for a job. When there’s a culture of preferred technology, professionals at the entry stage tend to familiarise themselves with just the hot takes. Everyone becomes a MEAN stack developer because that’s what the “industry” wants these days. Then they switch to becoming a MERN stack developer because that’s the updated industry standard, thereby losing an important bit that makes tech so exciting: the variety of approaches to problem solving. Also the lack of skills and knowledge of the fundamentals by entry level candidates is mostly driven by this vain obsession with tech stack competence. People skip data structures and algorithms and try to learn React so they can be immediately relevant and employable, or at least appear to be. And I don’t blame them!
Apparently, the people that get to evaluate the relevance of a candidate’s experience to the role being considered are part custodians of the future of tech. The interviewers have a part to play in what becomes a widely accepted industry practice and what doesn’t. We should choose them carefully. If there’s anything talent shows have taught us, it’s that: the fact that someone has great talent and success in something doesn’t make the person the best judge of talent or trainer of talent in that same thing. Yes, I’m referring to that one Rick Ross incident, but this holds true for about anything and tech recruitment isn’t an exception. Your best engineer isn’t necessarily the best interviewer or mentor. Being a good engineer probably means you get to know how to have a solid technical discussion around tech of interest to you, but not necessarily understand the variable bits that complete the interview experience. I might change my mind in the future, but as of now, I’m an advocate for outsourcing the interview process altogether (HMU if you’re working on, or interested in working on a solution in this space ;)). I dare to argue that a professional interviewer role in a company is as important as a scrum master. Alternatively, companies can just train the people that interview for them. Interviewing is an art and there are many bits to it that make it both successful and positive for all parties involved and competence alone in the core of the job being interviewed for doesn’t quite cover it all. It barely scratches the surface. What the industry suffers today, from the lack of adequate training, is an interview process only as good as the Interviewer. The experience is hardly consistent from one company to the next. Sometimes you’re lucky as a candidate, other times, you are having a chat with someone who is extremely condescending in countenance and not even deliberately so. So there’s a REST framework for API specification but nothing for interview processes? We can do better!
Another prominent feature in my many conversations with untrained interviewers is the negative interview style. The conversations tend to be a foray into discovering what makes me not a perfect fit for the job as opposed to finding out what relevant experience I have that could make me succeed on the job. Emphasis is often placed on what’s missing rather than what’s present. Yes, the half empty glass perspective has no place in job interviews. It is in fact the opposite of what should be happening. We should be looking for positive touch-points, while taking notes of the not so positive ones, but primarily looking for positive overlaps for a potential match. The problem with being fixated on shortcomings is that there are always shortcomings and any shortcoming can be magnified through the lens of bias. Surrounding details might be good to know to help with tie-breaking decisions or even salary decisions, but should certainly not be a prominent aspect of the interview in itself. Way too often, interviewers are carried away with comparing the candidates with themselves and looking for a candidate with a similar profile as themselves. The danger of this, apart from the already mentioned homogeneity, is that people tend to have a bloated idea of themselves and it is almost impossible for someone on the other side of the table to meet that, even if they are, in fact, exactly the same as them. It makes sense that the thinking on the side of the interviewer should be the same as when they were in that candidate’s position. What they wished they’d be evaluated against and what they hoped would be appreciated by the interviewer. In the end the interviewer would not be interviewing a candidate if someone reasonable didn’t interview them as well. So next time you’re tempted to ask “I know you’re familiar with React, but how many years have you spent writing it?”, remember that you were once yourself, unfamiliar with React and someone hired you nonetheless and that hasn’t affected your relevance to the company negatively over time. A more positive interview style would be to assess the relevance of what relevant knowledge and experience the candidate currently has and what the candidate’s potential looks like against the company’s current [and projected] needs and determine how the candidate could potentially fit or grow into the role.
The last artefact of untrained interviewers I’d like to point out is the unidirectional style interview. It’s all about projecting what they want to portray. They ask all the questions, question your answers and talk about what they use and how they use it or how they would have approached the same question they asked you. They do all the talking and the candidate does the responding. At the end of this process, candidates tend to feel drained, and depending on how many questions they didn’t have ‘adequate’ responses for, they might also feel ‘stupid’. This sour taste in the mouth of candidates is what happens when a candidate is placed on the other side of the table and pretty much asked “why should we hire you” without any form of conversation about “why you should join us” or even “what do you want in a company/employer?”. A balance is needed. It should be a conversation not an interrogation. Both parties are considering each other for a potential employment relationship and the interview process should reflect and project that. The role of mutual respect in an interview process can’t be overemphasised. Candidates should also try to emphasise this point in the form of asking explicitly about the interviewer’s experience when they were interviewing or during their first year or if they themselves had 5 years experience with Flutter before they joined the company. Oh, by the way, Flutter’s initial release was in May 2017, so as of now, in 2022, only the inventors of Flutter could possibly have 5 years of experience, 1 of which would overlap with building and not using it.
