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 d...
For further actions, you may consider blocking this person and/or reporting abuse
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!