Photo by Andre Hunter on Unsplash
I've been very pleased by the reception of my two articles What's your current salary ? and What's your salary expectation ?. This gives me motivation to write more about the topic.
But first, I have a few questions for you my readers :
- If you have been looking for a job recently, what did frustrate you most ?
- What have you tried to work around those issues as a candidate ?
- How well did it work ?
- What would you do if you were on the hiring side and had a magic wand to debug the hiring process ?
Searching for a job is a huge emotional roller coaster. It can be a huge leap forward for your career, but it also often feels confusing, frustrating and hopeless. Let's brainstorm on how to avoid the bad parts :)
Top comments (35)
I for one absolutely hate "reinvent the wheel" questions. Like "implement a sorting algorithm to sort this array of numbers ascending". Great. In Java that would be
array.sort(), in go it'ssort.Ints(slice), and so on.Why would I do that for an interview, if I wouldn't do it on the job? I just don't see the point of doing things that have been done by language engineers already.
It would be stupid to think that my "5-Minute-Algorithm" is better than theirs.
Let's just solve real problems..
This particular opinion cost me about a dozen interviews already, but I stand firmly behind it.
I also find it pointless. What I do in this case is that instead of showing my frustration, I ask calmly the question :
"I see. (Silence) Can we take a step back ? (Silence) (Yes, go on). What is your goal with this question ? What are you trying to achieve ?"
Then either a good answer comes or not. If they thought about it, I'm fine. If they didn't, they will remember it for next time and maybe do it differently :)
The reason is most likely that they want to make sure you actually know how to code, not just how to cobble pieces of code that somebody else wrote together. Although the latter may be a relevant skill set in some roles as well ; )
When we hire though, we always do a work sample that is representative of what we actually want to achieve. That kinda feels like the best way to do it. But our work sample is quite time consuming, which is a big downside.
And I can see where they are coming from with that kind of question.
Knowing how to learn, use and adapt an existing framework is, in most cases, many times more valuable than creating your own half-assed algorithm for a fake problem.
We are teaching DRY, KISS and many more paradigms of that sort, only to say "scratch that for a hot minute" in an interview. That is absolutely mind-boggling to me :D
Give people a real problem with real technological boundaries and see how they adapt and solve the problem. I don't care if someone can implement a bubble-sort or knows how HTTP internally works. It has zero practical value, since it can be memorized and mindlessly repeated on a whiteboard.
But if someone can take a look at <any framework>, one that is actually of practical value for you in the field, to solve a real problem? That's a keeper.
To be honest, when I look for employees, I don't even care if they "know how to code", as you called it. I want to know if they can learn. Knowing how to code today is easy, still knowing how to do it in years to come, that's important.
IMHO thinking "I can do better than <insert any Framework here>!" is wrong at best, and a waste of time and resources at the worst.
From all of the interview processes I've been to, the common and super frustrating question in most of them was the super crazy and complicated problem algorithm that i won't probably use anytime during the actual job.
And after failing the solution, the worst part is when they reply "oh, sorry but you're not qualified enough to continue in the process" like, are you people trying to recruit a robot??
What I really do not like most is how in 98 if not 99% of cases, they don't get back to you when you are not selected. You email and they just plain ignore your email.
Yeah ghosting sucks indeed.
I will write about what can be done from the candidate side
That will really be great. Please, mention me in the article somewhere so I can get the notification to come check it. Thanks so much
I want to give a view about gosting from the candidate side. and that is intransparency from all the companies side. they only want to show numbers once they like you and are willing to give an offer. in the meantime, the candidate has to contact lots of companies, I mean, you can not just wait,... Ghosting can than have multiple reasons. such as just keeping an option open while trying an other.
ghosting sucks, but i think this is the world we live in,...
Yup, you got it. We just need to keep going, getting better and taking advantage of opportunities.
Take home assignments that require you to do too much. I recently had an experience where I was supposed to build an entire API with a set of features and then also build a frontend that consumes a different API. All in all took me upwards of 5 days. I did not enjoy being stressed out over a job I might not get like that. The reason was because I was applying for a junior to mid role, for one and I was applying to only to work on the back end. I did let the interviewers know my frustrations and hopefully they do not do it to other applicants.
Got one of those from a storage company combining arthropods and trees in their name β write a web crawler with a CLI driver that communicates asynchronously with it via GRPC and can return a formatted tree of its crawl.
Took me a couple days β and I got ghosted.
Still considering whether to make the private Github repo public. I was pretty proud of the code.
of course you make it public, you owe them nothing
I've gotten to the point, after the 2nd 'Give me the definition of
{{concept}}' question (or even 'What is difference between{{x}}and{{y}}'), I usually ask 'Um.. so this is position is for{{X}}, wouldn't you rather be interested in how I solve problems?' Honestly, a company asking me to regurgitate definitions isn't really telling me anything about what I will be doing. Now, if I get asked 'What is a delegate?'. I will answer 'A way to pass a function as a parameter' and follow up with 'Can you tell me when you've had to use this in this current role? Wouldn't{{other option}}be better? Or 'What if I tried to check in{{other option}}?'Like you said, 'How well do they react to something different?' If they have no time for questions, red flag. If they can't prove with tangible data why their way is better, red flag. 'Because I said so' or 'That's the way we've always done it' are red flags.
The irrelevance of people involved in the process. From the recruiter that is irrelevant, the hr that is also irrelevant to the hiring manager who often doesn't know what his team actually does. Again and again the same questions and quizes that someone read online that they are good to ask because people can't really evaluate the proficiency, potential and relevance of the applicant. I've been involved in this process both as an applicant and as a hiring manager for my team.
I've had more than often cases like the following
When being the interviewer, I can understand the applicant fast. I know how and what to ask to confirm the sincerety and when the applicant is young I know to ask questions that allow to candidate to figure what is important from his/her experience that though of unimportant. The only reason that I can do this is because I'm a software engineer and I understand the basics of what drives a good developer and more. Can I hire a civil engineer? No, because I'm irrelevant. Maybe I can tell you if the person is good if I'm present in the interview.
Can I ask how you learned to interview and hire ?
I didn't learn like it was taught to me. I just had to do it and I tried to avoid the pitfalls I had encountered. I also spend some time to prepare and read the CVs of the candidates and have points of interest that I wanted the candidate to expand. Lets say that I do it a bit on instict. When it comes to the honesty, I just understand where there is a lie or not because I connect the small things where people get comfortable. We tend to be well organized and lie on the big topics that we know we are evaluated. But are true selves are mostly represented in the smaller things.
I've also learned over the years that a question is a bidirection flow of information. The way you ask a question and what you focus on, conveys what you are interested in. Dry checklist questionaire reveals lack of relevance but if formalize the questions to be more personal and you can add and inject into the story line with more specific questions or paradigms with issues from your own company, then that connects and engages the candidate besides extracting information.
So this is how it happened. We were going to hire some people and we had senior and junior applicants. With the juniors it was easy. I early realized that I had to help them tell the story. I was more experienced, new what matters and I had to guide them into them telling their stories. I did this for example by asking them what else did they do during their thesis. How much more than the assignment they did. I implicitly asked them to tell me if they found the challenge interesting and why and if at the end it tought them more than the official curriculum. This is particular to the Greek culture but to my knowledge applies to the rest of europe. Let me explain this differently. If you are not willing to hire code monkeys, you want people that can step up, take responsibility and be proactive. If a junior profile did the absolute minimum for a given assignment, how would that ever be?
I had spoken with the juniors afterwards and they had said to me that they chose that company because of the interview. it was different and interesting and taught them a lot.
Overall I try to offer a challenging experience during the interview. An experience where the applicant at least had fun. If the applicant is into the technology as a passion, the exchange of information, challenges and experiences would feel as fun and not a chore and another repetition of the same thing.
In general I think is wrong to approach a candidate with a checklist of specialization. 5y of .net and 3 years of javascript and blah. I strongly disagree with quantifying people like this. What you need to look for is potential. Everything else the one with potential and passion will learn. Maybe it will take a bit longer but I would always trust for a long term relationship the person with the potential over the dry checklist. Not that knowing things is bad but it can't be your only conditions. But potential is the hardest to evaluate because it is based on how the person explains former challenges, what went wrong and what went bad. Admission of failure is also something that dry interviews don't understand but for me the important is what did the person learn because we all make mistakes. Understanding all these requires affiliation with the subject.
I can expand more if you are interested and your question for serious. Maybe with some more particular questions.
IMHO the current process gives the wrong people too much influence on the hiring decision. And by "wrong people" I mean developers and the potential future team members - yeah, unpopular opinion, I guess. So let me explain.
First of all - it's not a developer's primary job to evaluate candidates, most of us have absolutely no training for this task. Don't get me wrong - I know that it takes a good developer to know a good developer. Who else would be able to judge the skills of someone than a master of the skills? But this falls short when only developers have a vote in the hiring process, because then the only value you see in a candidate is their (technical) skills.
But it gets worse. What skills are being judged specifically? Well, of course the skills your developers already know - or do you know of a fellow frontend developer saying "well, he doesn't know react, but I would hire him for the java backend skills he told me he has, even though I have no idea of java and backend thing myself"? I for one would not say something like this.
Last, but not least, we have sympathy for people with similar interests. That's just human nature. It leads to a monoculture, not only people-wise, but also when it comes to the tech stack. Some developers are especially childish in that matter, which leads to our omnipresent framework wars, language wars, and even editor wars.
So in summary one could say that the current hiring process leads to teams of people that are all pretty much the same. These teams might be a local optimisation, mastering the current tech stack of the team. But they won't deliver the best results. Good developers need friction, need emotional debates, need the challenge against their peers in order to deliver their best results. And you only get that when people have different opinions, different passions, different people.
So the last thing you want is a team of people that are all alike. And I think this can be achieved by taking away much of the influence of developers in the hiring process, maybe cap it at 25%.
I would also want developers with no training in hiring matter less.
An alternative way to do that is to actually give developers the training on how to hire :P
I did the job interviews at Amazon and they were quite good. You would have two people interviewing, one of them just listening to understand how to do it. Later he would lead the interviews, but still in a pair. Later he would do it alone.
I disagree with you or lets say i prefer relevant people as the lesser of two evils.
Look at my root comment for more relevance.
This ---> π»
Ghosting does not help anyone. The candidate gets zero feedback and the company's soul degrades as they get closer to hell π₯ π
100% this!
For me is when the interviewer doesn't give feedback. I had a couple of interviews where they ask questions and even give you take-home exercises where I've spent many hours and never heard back from the interviewer.
Thanks for sharing this. I can imagine how frustrating it is.
"How many years of experience to do you have as $JOB_TITLE" is a question that infuriates me as well. It doesn't matter what your job title is. What matter is what you have done and what you want to do in the future.