A Software Engineer with 11 Years Experience was Referenced as "Junior" - How to Avoid Such an Experience

This is a post about our professional identity and how a very talented software engineer with 11 years of industry experience was ranked as "too junior" for a senior software engineering opportunity at a client of mine.?

Let's call this engineer, Thomas. CS degree from a very respectable institution and he also has had the luxury of working at some high profile startups here in Austin since the early 2010's. But like a lot of impacted IT professionals the past couple of years, he was the product of a layoff back in May of '24 and he technical skills did get a bit rusty. But along with his credentials and having worked at highly regarded companies in his career, we were able to secure him an interview with a top tier startup here in Austin. This story has to do about some feedback my client provided and while I greatly respect the honesty and transparency, it is an experience I want to make sure other software engineers don't realize in their interviews, especially if we are 10+ years into our career. To get things kicked off here, I'll paste the feedback for you now,??

Sadly, we are going to pass on Thomas. The team felt he was too junior considering his background and he didn’t do as good on the technical assessment as we were hoping. Overall, everyone really liked him and gave 5 stars on culture fit and would enjoy working with him. But again, he was just too junior for our Senior Software Engineering position.?

While this feedback and closure was delivered by my client in very good form, the one word that hit me more than anything was "junior". And for any software engineer with seven or more years experience in the industry (let alone 11 years like Thomas), I just want to make sure that such a word isn't applied to you. As we all very well know, opinions and observations other parties have about us in our professional networks matter quite a bit. And I just struggle with the reality that there is now an audience of people here in Austin who view Thomas as "too junior" for their company. But on the other hand, I can also understand my client's view because Thomas has been out of work for almost six months now and in the immediate sense, his technical performance was not at the level they needed for this role. But there is another dynamic I would like to discuss that could have further compromised Thomas' interview.? The suggestion I present in this post, in no way whatsoever, guarantees that you'll get an offer but this kind of experience could provide some nice support for your overall interviewing performance. In Thomas' defense, the moment most likely never presented itself for him.?

Okay, let me get down to the gritty details. This advice is primarily for final round, on-site interviews. An interesting dynamic in the software engineering profession is that even if you make it to the final round with a company, you still have quite a bit to prove before securing an offer. And that was the case with Thomas. Even though he had made it through the first two rounds with my client, the most challenging part of the process still had yet to come. The final on-site with my client consisted of a white board challenge as well as three 1 on 1 interviews with senior software engineers. So what could have Thomas done better? Let me cut right to the chase on this.?

I'm a massive fan of a top 1% software engineer here in Austin by the name of Michael Norman. He's a 25+ year veteran and an absolute industry expert. And yes, while the code he generates is incredible, what also blows me away are his narratives relative to his career accomplishments and the work he's done through the years. Michael is happily employed at a very successful startup called Embrace.AI but in the past, when I've worked on job searches with him, the nature in which he communicates his experience and the technical projects he has worked on is just so damn special. And what's amazing is that when Michael interviews at companies, in addition to his technical excellence, he delivers these narratives that just knock people's socks off as well. I first learned of Michael in 2007 and I remember everyone at Lombardi Software just speaking of him in the highest regard. And Michael might not have even been 30 years old at the time. What got him to such a special heights so quickly in his career?? No doubt, his technical brilliance was the main reason but in addition to this, his commentaries and narratives further validated his engineering talents. As a result, everyone that met him just came away so impressed. Michael graduated in 1998 and the last time he was ever referenced as "junior" was his Freshman year in high school when he was probably in an Advanced Calculus class filled with a bunch of senior students. And I'm not kidding at all about that.

Getting back to Thomas, being six months unemployed, he went into this final on-site not only rusty on his technical skills but also rusty on his narrative. While I had pleasant conversations with him, aside from his resume, we didn't go into too much detail about his professional experience and technical strengths. In terms of his professional delivery, Thomas had not said such words to another party in at least six months. Make no mistake, he is a damn good engineer, a super nice guy and would have been an awesome culture match for my client. That said, if he could have created a moment where he delivered a Michael Normanesque type narrative, it very well could have augmented his overall performance. While I cannot guarantee that it would have secured him an offer, his audience, ie. the other engineers who interviewed him, would have come away with a more positive impression that Thomas had been deep in the software engineering trenches his entire career. And most importantly, for an engineer with 11 years of industry experience, the word "junior" would not have been part of the feedback. That is still what sits with me more than anything.?

In closing, if you're coming up on your final on-site and the company has made it clear that you will be asked to get up on the whiteboard, best of luck to you and hopefully it goes well. However, to complement your technical performance, can you look back in your career and try to identify 1-2 Michael Normans that you may have worked with before? And from there, try to recollect any special narratives they delivered? And only if the moment presents itself, can you try to create a moment of conversation in the interview and let a quality narrative flow from you in a manner that would further authenticate your software engineering expertise??

When it comes to software engineering interviews, verbal articulation is not discussed enough. That trait always seems to be saved for Product Managers, Account Executives and Business Development professionals. As always, please make sure there is consistency with your solutions on the whiteboard and the words that come out of your mouth. The current labor markets for software engineers are heavily focused on three areas and they are the following:

  1. Technical proficiency and tech stack alignment.?
  2. Culture match
  3. Willingness to commit to in-office or hybrid working schedule

But in addition to this, please take special inventory of the words that come out of your mouth and the audience you are speaking to. A detailed description of the environments you've worked in and the consistency with your technical skills will elevate your rank among those interviewing you. And again, even if you're only 5-6 years out of school, you won't be seen as "Junior".?


Thanks,?

Mark Cunningham

Technical Recruiter

512-699-5719

[email protected]

https://thebiddingnetwork.com

https://markcunningham91.blogspot.com

https://www.dhirubhai.net/in/markhc

Mark, I have to tell you this post had a real personal link for me. I went to work for a tech company some years ago and was quickly/unexpectedly embedded with a group of engineers on a product team who were used to writers that were more familiar with coding and tools. And I sat right next to Michael Norman. He was key in my learning how to present myself and work successfully with engineers as a "less technical" writer (at the time) and gain respect for my work. He was also a kind desk neighbor during a high-tension product release. Seeing you call him out delighted me and also reminded me one more time of the importance of minding my narrative not just in interviews but when working with new teams. Thanks!

Michael Sadlon

Experienced Software Engineer & Architect | Dotnet 6, Architecture, Microservices | Full Stack Developer

3 周

Interesting post Mark. Thanks for sharing. I agree with Mark's take on having some narratives. Talk with authority on that 6 month project you led, etc. Have some good narratives as they help sell you as a candidate. I think interviewing, whiteboarding, presenting, and such skills require practice like anything else. The more you can prepare the better. You only get one chance with this company.

Jeremy Gaither

Lead DevOps Engineer with 17+ years in software development, cloud infrastructure, and automation. Skilled in AWS, Kubernetes, Terraform, and CI/CD. Passionate about building scalable, secure systems that drive results.

3 周

Getting rusty after a long period laid off is easy, especially regarding the words coming out of your mouth. Keeping coding and other technical skills up to date is easy with regular, deliberate practice. However, replicating that same practice with a whiteboarding session is harder. It isn't something that someone might think of doing. One tip I'd like to offer that might help is to practice using the rubber ducky method for technical whiteboard interviews. Record yourself explaining a solution, possibly to an actual rubber duck or some other object that won't get tired of listening, and then listen to those recordings or watch them if you're taking a video. Using a video is probably only beneficial if you have a large whiteboard for practice. Not everyone can give a toastmaster-quality delivery of a narrative, at least not without practice. However, whiteboard practice is as essential as practicing technical skills to keep from getting rusty. By listening to what you said while deep in thought and watching how you interact with the whiteboard versus the rubber duck, intentional practice can help with these kinds of interviews.

Tim Dugan

Principal Software Engineer at PROS

4 周

I think calling him “too junior” was their inept way of saying “the depth of his technical knowledge is inadequate”

要查看或添加评论,请登录

Mark Cunningham的更多文章

社区洞察

其他会员也浏览了