Have you ever had that terrifying moment in an interview when you’re asked about technical experience you don’t have? Well, I recently have and ended up with a job offer for a role where I didn’t fully meet the job requirements. The company noted that they were impressed by how I handled the interview, particularly that moment. Here’s how I approached that.
Heuristics when applying for stretch roles
During my recent job search, I applied for “stretch roles”. A stretch role is one where you don’t meet all the job requirements advertised. By my assessment, I probably met somewhere around 70% of the actual requirements (not the advertised ones) for this particular job.
I could tell some of the requirements in the job spec were nice-to-haves for the company because they didn’t complement the core requirements well, and some were just to convey seriousness because no one really expects you to be au fait with JVM implementation details.
Figuring out the role’s core requirements
The ad was for a senior backend developer, and up to then, I had been an intermediate developer with about four years of experience. From perusing the ad, I could see that the core requirements were Java and Spring because the main function of the role was to develop microservices to meet business requirements.
JAX-RS, GraphQL and AWS experience were nice to haves because the description focused mainly on design patterns and object-oriented best practices. Similarly, the inclusion of React, the need for “three years experience as a Senior”, and J2EE was probably placed to convey the gravitas of the role by the recruiter. Firstly, a backend engineer working in the team implementing account transactions is unlikely to use React/Angular. If they do, it certainly wouldn’t be the core tool. Secondly, Spring obviates the need for extensive J2EE knowledge and is mature enough not to need too much under-the-hood tweaking. Also, the demand for developers is most acute at the senior level, and competence seems more important than pedigree based on my observation of some of my peers’ career progression.
I actually love chatting to recruiters to sharpen my skills, but I’ve realised that they generally aren’t technical people and will sometimes rely on buzzwords or trending technologies to create a particular perception of the role. Since I had two years of experience building microservices in Java with Spring(boot), I applied, passed a technical assessment and got the interview!
How I handled my lack of technical knowledge
In the interview, I quickly realised just how much I didn’t qualify when asked about the appropriate use of Kafka and Docker—cloud technologies I had never touched up to that point. The panic set in! I dismissed the “cool story” forming itself at the edges of my mind and used the opportunity to give them an impression of who they would be working with: someone direct, honest, curious and growth-oriented, which are values I try to maintain.
I managed to utter something like: “I really haven’t worked with any of those up to now, but I have read a bit on them, and I like what I’ve seen so far and would love to work with them and build those skills.”
What hiring teams want to see when approaching knowledge gaps
It turns out both the recruiter and manager I had spoken to mentioned how they liked that I was upfront and honest about my ignorance. Apparently, this put them at ease and showed that they were dealing with someone who was aware of and honest about their limitations and saw them as a challenge and invitation to growth. That allowed us to discuss how the company and I actually fit together really well.
They said they were aware that no developer will meet all their requirements, and they appreciated when candidates didn’t try to make up a response when they clearly didn’t know enough. Knowing a candidate’s skill level makes it easier to give them the appropriate level of support to get up to speed. I received two offers from them with that moment as a highlight!
How to respond to questions about your lack of technical knowledge
I reflected on that interview, and refined that approach to really show my curiosity around the topic and that I was willing to learn. I ended up coming up with a strategy that I actually applied in an interview shortly after that one.
My response around technologies I didn’t know or have experience with needed to:
- Be transparent about my lack of exposure
- Demonstrate my interest in technologies I had no exposure to
- Fully indicate my current level of awareness
- Assure the hiring team of my willingness and ability to learn new things
- Give an example of how quickly I had ramped up before with technologies that I had not known up to that point
That response was a lot smoother and helped me get the offer that I ended up accepting.
My more composed response went something like:
- “No, I haven’t actually worked with any of those up to now, but
- I have investigated them a little in my weekly review of new technologies.
- I understand Kafka enables event-driven programming, which can save resources by allowing the system to respond only as needed. Docker impresses me in reducing the overhead required by full VMs while allowing a completely portable environment for microservices to run in.
- They both seem to represent the cutting edge for scalability, and I would love to get my hands dirty with and understand them better.
- It reminds me of how exciting it was when I first worked with microservices having previously not even known about them. It was a steep learning curve, but in about three weeks, I managed to create a microservice that the team later used as a template for other microservices.”
That response was the result of a little pre-interview mental prep. To prep, I:
- Recalled ways I showed interest in various cloud tech and solution design, such as reading blogs
- Brushed up on the names and functions of current major cloud technologies
- Crystalised my level of exposure to cloud tech
- Prepared anecdotes based on my experience that demonstrate my willingness to learn and succeed in learning new technologies
- Realised that by this point, they really, really want me to be the one they hire otherwise, they would have stopped talking to me two interviews ago
- Trained myself to think of this interview as one of possibly many, and that there was a world outside of it that still had many opportunities for developers, thankfully.
Why developers can apply for stretch roles
Companies really need competent developers and are willing to hire skilled developers with knowledge of the role’s core skills and who they feel they can trust and teach. I was applying for positions I didn’t yet fully qualify for based on the privileged position software developers currently hold in the market: the demand for our skills seems to keep growing—just have a look at your LinkedIn inbox. The shortage means job descriptions are a wish-list companies expect to compromise on.
If recruiters are willing to compromise, then it’s potentially a significant boost to your career growth. If not, it’s only an hour of your time and theirs. I’d roll those dice.
When applying to roles you don’t meet 100% of the criteria for:
- Be realistic: Don’t apply for a role you would need more than two promotions to reach
- Be optimistic: Some of the requirements are added in by recruiters who may not be well-versed in tech
- Try to work out the core responsibilities by focusing on the “What the team does” and “What you’ll be doing” sections, then use your industry knowledge and/or Google to check the requirements against those responsibilities
- Any requirements that don’t seem to address the core responsibilities are probably nice-to-haves, whether they’re labelled that way or not
- What Your Future Employer Is Looking For in a Technical Interview
- How to “Flip” the Interview in your Developer Job Search
- What I Learned From Interviewing For A New Job
- Fighting the Imposter Syndrome: Lessons from a Self-Taught Developer
- 4 Steps to Get The Full Picture of Your Developer Job Offer
- Tips to Land Your First Job After a Coding Bootcamp
- How I Used Technical Assessment Feedback to Ace my Developer Interviews
- Developers: How to Ace Your Introduction When Interviewing
Trevor is a family man with about five years experience in short, medium and very long term project management, culture hacking, conflict resolution and resource allocation. He enjoys playing with chaos and structure aka freedom and tyranny, writes code sometimes and is employed by Takealot.