I rarely visited LinkedIn. And if I did, it was just a couple of scrolls and then I’m out. However, things have changed after I got laid off. I found myself opening LinkedIn a couple of times day, updating my CV making sure my experiences are neatly laid out in bullet points. Honestly, I hate doing it because there’s this pessimistic voice at the back of my head which kept telling me that someone out there who has only a Hello World! experience could also write the same thing on their CV, or even better. On top of that, I’m always shadowed with impostor syndrome. What I wished though is to be handed over with a snippet of production code and allow me to evaluate if there is a need for design improvement, potential complexity and missing test scenarios. Unfortunately, that’s not how the world works. HR’s and recruiters have no idea who you are so they have to rely on your written information. It also helps them filtering out unwanted applications which is a shame because there could be potentially great candidates who just don’t have the talent of elaborating their skills on a piece of document. But at the end of the day, padding your CV is the only way to step on the front door.
So, what happens when you are already at the door? Usually, there are a series of interviews and meetings with different people from the company having questions ranging from technical expertise to personal qualifications. Personally, I always give honest answers. I don’t care if they like it or not. I’m not cut for faking it until you make it.
I remember I had an interview a couple of years ago. Everything went fine. However, the technical interview stood out for me. Given my experience, I already expected to have design related questions or some code organizational strategies. After all, your main concern as a programmer is to deliver a robust software and at the same time, it should be easy to change. Software changes all the time. To my surprise, I was only asked to solve SQL problems and most of them were just basic queries. Of course, I did not complain since it was probably their standard process. But that experience left me wondering: Was it enough to consider someone fit for the job? With the availability of AI today, someone could just copy and paste the answer from ChatGPT.
With that being said, I came up with a list on how to spot if a candidate knows what he’s doing. And again, these are just my opinions relative to my own observations.
Junior: I define a junior as someone who has little to no prior experience on the field, i.e. fresh grads, or shifting from completely unrelated career. Since they don’t have any experience yet, I would focus mainly on their problem solving skills. Give them some problems, preferably a real problem that happened on production, and observe how they find the solution for it. If they managed to solve it, then it’s a good sign. If they didn’t, notice how they approach the problem. Did they ask confirmations on obviously obscured situation? Most of the time, they just dove in and fix the issue as fast as possible. But if someone spent more time analyzing the problem and listing the knowns and unknowns? Asking a lot of questions? Then, that’s definitely a great sign of problem solving skills. How they code it does not matter at this stage.
Mid: I’d say you’re mid if you have a couple of experience and exposure to real production code. At this level, I would focus more on their knowledge of some design patterns, SOLID awareness, tests importance.
Senior: Probably, many of us would consider someone a senior if he/she has already years of experience. Maybe that is true but I would argue that it totally depends on their exposure. For example, someone would have decades of experience as freelance without team collaboration. Team feedback is an integral part of self-improvement. Other than the number of years of experience, accountability is also one big factor to become a senior. I’ve seen very good self-acclaimed seniors but they avoided responsibilities and ownership of the project. To conduct a technical interview with a senior, I would let him read a part of the production code and ask for feedback on what needs to be improved or allow him to propose another solution and explain why? Of course, he/she should be able to write the solution to confirm that he/she actually walk the talk. I met a “senior” once who talks like an expert but can’t even distinguished which part of the code is a strategy pattern. And why let him/her read your code? Well, code is written to be read. Otherwise, let’s just write it on Assembly. If someone knows how to read a code, that someone definitely knows how to write. IMO, the best way to determine if you’ve done a good job is to let people read your work. Personally, a well written code requires minimum cognitive load to understand it and reading it should feel like you are having a conversation with the code. And I have to say, my skills on this one is still a work in progress.
These are strategies I would have done if I conduct the interview. This is absolutely not a guide you should follow on your process. These are preferences based on personal experience. Do you have a similar or different opinion? Let me know in the comment below.
Leave a Reply