As a candidate, I have only worked with an external recruiter once. I found it interesting that they told me almost the exact questions to expect during my interviews. After the interview, they asked me what questions I had to answer. I assume this was to improve their data for future candidates.
I’ve been told that this is both common and considered a good thing. Candidates who have a chance to prepare for the interview are more likely to succeed. Companies succeed when candidates succeed.
This statement is false. Companies succeed when employees succeed. This is a small, but extremely important distinction. The goal of interviewing is to find a candidate that will actually be a successful employee. If that is not the case, it is in everyone’s best interest for the candidate to look elsewhere.
This is where the idea of preparing for an interview becomes a problem. Preparing by learning about a company and its product makes sense. But preparing for an interview by cramming/studying material that is supposedly needed for the job makes no sense. A candidate should have the experience to do the job well.
Do you think cramming for 1-2 weeks can make someone as qualified as someone who has years of experience?
Probably not. Cramming may get a candidate a job. But they won’t succeed at the job if they don’t have the skills and experience needed. This also isn’t a “you’re either good or enough or not” statement either. Think about science. There are many different types of scientists. A biologist would not do well teaching physics. A physicist would not do well teaching biology. They can still be good in their respective fields, but terrible when doing something they are not trained in. Software development is also diverse and has similar issues. It’s not about being good enough. It’s about a developer finding a position where they can realize their full potential.
That recruiter shoved me into 5 interviews for positions that were not right for me. It showed. Each interview was extremely stressful and I struggled in all of them. No surprise that I didn’t get any of the jobs.
Funny side note: one company was told I was an expert in Scala despite it not being on my resume. When the interviewer asked “How’s your Scala?”, my response was “Zero.”
Now you may be thinking “Well you should have prepared and got those jobs! Why are you an idiot?”
The reason is that I want to succeed at a company. That means being able to leverage my experience to its fullest and that means the company needing the type of experience I have. You can’t study to get experience. It only comes from doing the work and well… experiencing things. Even if I had received a job offer from one of those five companies, I would have struggled just as much when on the job. It’s not a guarantee that I would have failed, but the odds would have been against me.
The next interview that I went, which I got on my own, went very differently. I didn’t prepare for this one despite failing five times in a row.
The interview was objectively stressful. It was 4-5 hours long. They forgot to schedule me lunch. They had me talk to engineering managers, software architects, product managers, the vp of engineering, the vp of HR, and the CTO. I was asked to write code on a whiteboard. I was asked to architect complex systems. I was asked a number of leadership questions. I was asked to explain bad decisions I made in my past.
In the end, the interview was easy for me. I didn’t feel stressed at all. All the questions seemed like they were tailored exactly for my experience in a way that I could explain well. It was like having a series of enjoyable conversations with interesting people than it was having an interview.
And note that none of that means that I am the best software developer to ever walk the face of the earth. I’m not. Five failed interviews straight proved that. And it’s not like this company had low standards. The stream of failed candidates before me proved that.
What the ease of the interview meant was that I was right for the company. I had the exact skills the company needed and that meant that this was a place where I could succeed. It was the right position for me at the time. More importantly, there was no way to prepare for the breadth of questions I was asked. They all relied on experience that I actually had.
Getting one of those other five jobs would have required me to pretend to be someone that I’m not. Taking one of them would have set me back in my career since I would not have the skills I would have needed to do the job well. I would not have been able to realize my full potential at one of those jobs. This would have been bad for me, but it would have also been bad for one of those companies. They would have hired someone who provided them less value than another candidate would have.
The job I did get is one where I utilized the skills that I had gained over years. It also gave me an opportunity to continue practicing and improving on those skills. That makes me more valuable to companies that need that skillset, which consequently is good for my career growth and my wallet.
Granted, all of this implies that companies have actually created an interview that actually tests the skills needed for the position they are hiring for. It is in their best interests to do so though. In doing that, they make interview preparation pointless since studying is no substitute for actual experience. Every developer should have confidence in the skillset that they painstakingly built and trust that it will get them a job that is right for them.
This post was originally published on blog.professorbeekums.com
Top comments (15)
I once got a lucrative job offer at a major software company, more money that I have made before or after and more prestige than any other position I've ever held. I ultimately declined to join because I couldn't see myself being happy working with technologies that didn't interest me that much, holding a role that didn't offer me much freedom and ultimately losing the ability to choose my path.
Not that I have to choose my path in every situation, but being placed on a path that doesn't fit my general personality and aspirations would lead to a bad situation and stagnate my love for this craft.
On the same general topic, but approached from a different angle, I wrote post Embrace How Random the Programming Interview Is, making the argument that you should just go for a job if you feel like it, and hope for the best.
The programming interview is definitely random. I think that's partially fine. Interviews should be about a company and a candidate discovering more about each other. Both need to decide if the job is a good fit for the candidate. I agree that there is no reason to not apply for a position if it seems interesting.
I'm wondering how are things with picking up new stuff? Usually I expect to learn a few new tricks at every job. E.g. I have no experience with microservices. Then, how does the company test if I can learn that? Suppose I want to learn about microservices, how do I teach it myself besides my job and family? Any book and tutorial can bring me to the beginner level, and then what?
The microservices could be anything else, like Erlang or machine learning. Still, it's unclear for me, how to test for some sort of general learning ability?
Give the candidate a problem not in their area and see how they do with it while guiding them as a good teacher would—with a hands-off approach, seeing what they learn with each step.
This is how Sandia National Labs interviewed me as a college student. They asked straight up if I had any experience in parallel systems. Nope, I said. Then we went through some exercises to see how fast I could learn the material—how well I used the underpinnings of my undergrad and grad work to understand the problems he proposed to me. They were, I later found out, very simple, beginner level questions but ones I could not solve had I not been able to learn on the spot.
I got the job offer. I went with Amazon instead though, a decision I regret immensely, and not just because the interviews were so generic that I had no idea why they wanted me. Turns out they just wanted a cog.
Sandia wanted me because I could learn.
Life would have been different. And I'd probably be doing coding still, instead of burning out after a decade and turning to art.
Yeah I did the same Amazon, but I actually landed a good team at Amazon that would have helped me grow better. Though I took a chance at AWS to learn more. Worse decision for happiness.
Working at places that are way above your experience level does teach you new things quickly, but you don't really master them. Just cramming every day and having a half-assed skillset + burnout.
One of the problems is that the job market pushes you to make a choice quickly in sub 2 weeks (exploding offers). It really takes a while to figure out whats the best element, but then you get marked as a job hopper, etc etc.
AWS's issue was more that it tossed people at fires while needing to create long term solutions. Not that they never did so, it's just that there's something that resulted in them tossing devs into their oncall hell rapidly. My last position at Amazon was at AWS, and also the one that landed me in the hospital and prompted me to quit before the job literally killed me.
Ah Amazon. AWS was the worst. And I spent five years in the trenches of one of the most stressful areas of Ordering, and I still rate AWS as The Worst.
Yeah the on-call sucked, but I find the worse is that human compassion is only given to those who perform. If you are struggling and not "killing it" at all times, your manager doesn't offer a hand or suggest a transfer (until you hand in your 2 weeks).
Which is why I find this article relevant. Companies will hire to fill quotas / on-call bodies, but not all them vet or can vet everyone properly so as a candidate you can't even trust that the process is correct.
Gotta be prepared / have the confidence to quit within a weeks / month if it doesn't work out.
The way that's worked for me when conducting interviews is to ask open ended design questions (e.g. how to scale a web application, how to implement asynchronous workflows with multiple dependencies, implementing an API for a sample service, etc). No matter what the candidate says, there's always something I can think of that will cause things to not go according to plan. How a candidate adapts to the situation says a lot.
Do they get frustrated when they don't know something? It'll be more frustrating when production systems are having issues than in an interview.
What kind of questions will they ask? Can't Google the answer if you don't know the question.
What are their theories for solutions? This is the best indicator I have for knowing what it's like to work with a person if they're hired. If we can have productive discussions in an interview, then we can have productive discussions when implementing things.
As for micro-services specifically, I have a few things to say. The first is that I have met more people talk about micro-services than I have people who have had experience implementing micro-services. At the moment, just reading about it will put you at the same footing as most devs I think.
The second is that most software design patterns that we use for writing code are also applicable at a much larger scale. You generally want to structure code so that related functionality are grouped together. With micro-services you are taking it to another level so that related code is not even on the same repository or running on the same machine as unrelated code.
Lastly, some things are hard if not impossible to do on your own. You can implement micro-services by yourself as a side project. However, you won't be able to see how the design decisions you made with those services will fare with an organization of 30+ developers. You also won't see how those services will hold up with a million users and hundreds of requests per second. Most of the challenges in micro-services are scaling that development.
I think that's why I always advocate taking a job where you will learn what you want to learn. The benefits from a high paying job will only last so long as you have that job. The benefits from a high learning job will last the rest of your career, which will also open up even more high paying positions later on.
I absolutely agree. I did the same for the last couple of jobs I was invited for an interview. However, I think this only works because we're in the comfortable situation that there are more jobs than good developers.
Developers are definitely fortunate with the job market being the way it is. Even if that wasn't the case though, it is in the best interest of a company to create interviews where preparation isn't necessary. They want to measure the skills that a candidate has accrued over their career, not what they managed to cram in 2 weeks.
Someone brought up that new developers can't possibly do this. I agree mostly, but I think companies can still do something with the interview process here. You want new developers to have a strong thirst for learning. I once interviewed a bootcamp graduate who described an assignment where she refused to use a front end framework because she wanted to experience what it was like without one. Then she would know the full benefits the framework gave her.
For me, preparing is less about learning and more about practicing. I'm not compensating for years of education, I'm making sure that my years of education is all fresh on my mind and I can recall it easily. It's not cram study crazy new things and hope they don't ask tough questions, it's review what I already know so I have the ability to think and reason to the full of my abilities.
In that way, preparing so you can give your all, it's exactly what they need to see - what you are capable of. If they hire me, they know that I can be this person when they help me fire on all cylinders by inspiring me or mentoring me etc. And it shows, because I'll be much more confident in my answers because I'm sure I studied everything I know. So if I answer something wrong, I don't know it. If I answer something correctly, I do know it. They get the full picture of my knowledge and skills, and not my ability to min-max googling for definitions.
Good stuff! I recall early in my career that I just wanted AnyJob™ and would lob myself into whatever I could. Now with a much longer resume, I'm very selective about where I would apply because I want to make sure I'm a match for the job, and that the job is a match for me. When people ask me for interview advice, I often mention that the interview goes both ways. Candidates are ensuring they would want to work for the company as much as the reverse.
As an interviewer, it's much more delightful to interview someone who is in their element. It makes the decision to hire easier, and we feel like we didn't waste anyone's time. Applying for the right jobs makes that experience much better.
When we observe a candidate who shows significant talent, we want to hire them. One thing we are trying to do more is understand whether the candidate is perhaps a better match for a job that isn't the role for which they're interviewing (e.g., she's okay as a frontend dev, but really showed stellar Linux knowledge. We should consider her for an SRE position.)
I recently interviewed with a tech company. I had a lot of experience but not a lot of formal education in the area. I was stressed out of my mind preparing for the interviews, and spent mornings, nights, and weekends devouring everything I could. As you can imagine, there was far more to cover than I could possibly cram into a couple of weeks. I was terrified I would be asked a question about a data structure or sorting algorithm I had never heard of.
Turns out, I way over prepared. 99% of the things I worried about never materialized. All of the things that made the interviews go well came from my experience, not from cramming.
I 'cramed' for 3-5 month. Was a great time, not a waste, brought me a little bit further and i will do this again.
And learning is never a waste anyway :)
Great article. I think all prospective interviewers and intereviewees should read this!