Reddit user orduk asked, “How under qualified were you when you applied for your current position?”
There are a lot of misconceptions about what constitutes as “qualified.” Job postings are notorious for having laughable minimum requirements: more years of experience using a language than it has existed, senior level requirements for junior positions, or years of experience expected of fresh college graduates. It’s no surprise than many juniors feel the “you need experience to get experience” barrier is all too real.
I wanted to make one thing clear:
The top comment, by user vidro3, to orduk’s question is a great reflection of the developer experience: “Bold assumption that I’m now qualified for my current position.”
Your job pays you twice — once with money, and once with knowledge. This does not only apply to juniors; it applies to seniors as well. If you are only getting paid one of these ways, you are underpaid. If you are not growing at your job, you are being held back from advancing your career. By definition, then, you must be “under qualified” or else be stagnant in your personal growth.
This changes the perception of qualified. If you expect to grow at your job, and your company expects you to grow at your job, then you cannot have perfected or know all aspects of your job. You must be hired at a level where you can grow: you must be under qualified. This really just means that under qualified is the qualification level.
Good tech companies will hire “under qualified” individuals because that individual has potential for growth. It is a red flag when a tech company wants an overqualified individual. They don’t want the individual to learn anything new or better themselves. “This is the level you are hired at, and this is all you will ever be. Don’t expect a raise or a promotion, because your job is not going to change, and your performance will never improve.”
You should always be underqualified for any job to which you apply. The biggest sell of a candidate is not their encyclopedic knowledge, but their eagerness and ability to learn what they don’t know. If an employer invests in you as a junior, they hope to eventually have a senior with company loyalty.
Do not ever treat a “minimum requirements” as a wall. Apply anyway, if only for the interview experience. I’ve been a web developer for 17 years now, and I still rarely meet all the minimum requirements.
To answer orduk’s question, I am currently a front end engineer for the largest cloud service provider in the world. Outside of OneDrive for personal file storage, I had never used a cloud service a day in my life. I had not even used services that would have aided my development career; I always hosted my applications myself. I had no experience with serverless. I had not studied system design until two weeks before my interview — because they told me to study it for my interview. I did not know how most cloud services worked, but I am learning on the job, and the knowledge I am gaining, in addition to my paycheck, is that additional compensation that will allow me to grow as a person, as a developer, and in my career.
Being a self-taught front end engineer, not having a degree was one of my biggest hurdles. It took a long time for me to learn how to sell myself. I knew a great deal, I had great learning potential, but I didn’t have the confidence or soft skills to know how to convey that potential in an interview. I read “college degree” on minimum requirements and gave up. If only I knew then what I know now, I would be so much further in my career! Going to interviews for the sake of learning how to interview was one of the best things I could have done. Even when I was rejected, I learned what was in demand from those interviews, and I learned those things. Then, they stopped caring about my degree and started caring that I was A) passionate, B) eager to learn, and C) dove deep into material for a below-surface-level understanding.
Minimum requirements are not minimum requirements. Underqualified is expected. Soft skills are the greatest asset, not a degree or encyclopedic knowledge. You need experience to get experience is true, but knowing how to sell your self-taught or practice experiences as real experience is the confidence that can come from practice interviewing.
A confident way of saying the same thing would be, “I designed a reusable component that was extensible to all customer use cases. With GitHub Issues, I engaged customers to meet their needs, prioritized features, and maintain my service to them.” The interviewer knows that you can communicate technical ideas to users who are not on the same level of expertise, can design code that works across teams, can account for edge cases, can prioritize features, and can offer long-term support and maintenance. 👌
I am talking about the same code in both cases. Both statements come from the same level of qualification. One is selling myself and the other is selling myself short. Practice interviews worked wonders for me. I was able to learn what companies wanted (“Discuss a time you had a conflict with a superior and how you resolved it.”), practiced talking about my skills at home without the pressure or anxiety, then interviewed again with confidence. Rinse and repeat.
Interviewing is not a test where you fail for not getting hired. If you do not get hired, you still learned something. You should be using the company when you interview. Determine what is important to them. You should leave the interview more knowledgeable than you entered. You are a better developer after failing an interview because you know something you didn’t know the day before — you know some in demand tech stacks, you know some soft skills that are higher priority, and hopefully you will know what steps to take next to acquire any skills you are lacking.
Keep at it and see the opportunity in every obstacle.
If you liked this article, feel free to give it a heart or a unicorn. It’s quick, it’s easy, and it’s free! If you have any questions or great commentary, please leave them in the comments below.