I've been sitting many interview sessions recently as part of our recruitment process and let me tell you, it's one of the hardest tasks I've ever ...
For further actions, you may consider blocking this person and/or reporting abuse
This is just my personal opinion. Feel free to disagree (I would actually like to hear your thoughts).
This might be difficult for someone who hasn't had any challenging problem recently.
So, an honest answer like "I actually haven't had anything challenging recently" might not do them justice.
Just because the project/environment/company they're working at/on isn't challenging doesn't mean they couldn't handle one.
It's kind of like asking a body builder "have you ever lifted a horse?" and they say "well, no, because there are no horses where I live".
Just because he hasn't, doesn't mean he couldn't, if necessary.
Good one. I would however hint at what you mean. It might not be very clear exactly what you're thinking of.
Very good. If you can't explain something in simple terms, it usually means you don't really understand it as well as you think.
Good, but depending on X, it might be difficult to think of answers on the spot.
Perhaps a better approach would some thing like "Do you think 'this quality' is required for X? Why?"
Honestly, I think a lot of people would not know how to answer this question. Or, at best, just give a random/standard answer which doesn't tell you much. :D
I think most people will avoid talking about failures, because they know this reflects badly on them.
Honestly, I think some people will just say they can't remember such a situation or just tell a small lie.
I agree with you wanting to find out how they deal with failure, but I don't think you'll find out this way.
What you're basically asking them is to open up (slightly) to a stranger.
Good one.
Good one, but I would rephrase it simply as "What is your opinion about agile? Or working in a agile environment"
After that you can extend the discussion, if necessary.
Asking them about pros and cons would require too much "processing power" IMO :D
I'm not sure if this is really relevant.
You can have good developers who have never held a presentation in their life.
It's good that you want to know about this and let them know that your company supports this, but be advised: some people might consider this a personal question.
I'm not saying don't ask it, just to be mindful. :)
Thanks for taking time and providing your thoughts.
Here are mine:
And if at the end they really said they haven't, then imaginary situations can be used.
All of the questions can be delve more into if the candidate hasn't fully understood them.
Really good point and we usually have different forms for rephrasing these.
I'd argue about generalisation in this area. There are many people who know their limits and potentials really well. But even if they can't describe themselves, it's a really good starting point for provoking some thinking to see what is their evaluation about themselves. In another aspect, it's up to the interviewer's people reading skills to get the value out of this. But I wouldn't say the question is worthless.
Failure's definition can vary for different people. It's up to the interviewer to create a safe environment and let them know they embrace failure and value people who learn from them. Everyone has failed at something even in their day to day job, the fact that how they react and recover from it is the core for this question. So let's agree to disagree in this one.
This is really important for many companies including consultancies. As I mentioned before I don't just mean public speaking. Presentation in its simplest form can mean pitching your idea to your team. We're looking for skills in someone to simplify an idea and explain it to people concisely. Again we can agree to disagree.
We're not after their personal life's details. Simply to understand whether they are able to unwind and have the ability to maintain balance. We don't want someone who is super active for a couple of months and then goes under the weather for the next couple.
Thanks for your comments again, they'r really valuable for readers 🙏🏼.
Great article Yaser, I'm reading this 4 days prior to my first second interview. It helped me better see what to prepare and also what I might not have thought about.
I've only started programming a few months ago and it is my first time getting a job as a developer. Which getting any job can be intimidating by itself, but this is a huge career change for me. Thanks a lot again!
Glad it was helpful, and good luck. I am sure you’ll nail it
Thanks Yaser, I really appreciate the vote of confidence. If you'd be open to it, i'd like to pick your brains a bit of other questions I might have. Is there somewhere I could send you the questions? I promise not to over do it and that they will be well thoughtout questions not something like "What should i do?"
Thanks
Be happy to, send them over to me@yashints.dev
Thanks! I' doing some research atm, so maybe tomorrow or sunday i'll use this privilige!
have a great weekend!
Most of the people whom i consider really good would fail most questions due to imposter syndrome, unpopular opinions about scrum, and simply beeing not good at marketing themselfes.
Nearly all of the posers who had trouble with fizz/bazz i met in my career will ace these questions, except maybe questions 1 or 3. Hopefully, they'd be weeded out by the challenges before, but i wouldn't count on that.
I have to agree with you. I hire a lot. And initially I tried all these really hard interview type questions or questions that I expected that somehow they would have a good answer to. I also knew some very good developers that had terrible looking resumes (they just didn't know how to write a good one), and weren't particularly good at interviews. I also noticed that I scared away good candidates.
The reality is that being able to answer questions really isn't a measure of how they'll do in their job.
So I went back to basics. A favorite question of mine in interviews is "Write a program that will print the numbers from 1 to 10". Its trivially easy, but it filters out people who I definitely don't want to hire. The other thing I put a lot of weight on is references. Since we live in a place where lots of people know each other I see who gets vouched for and who doesn't, and who likes the work the person has done. I understand that nationwide that may be harder to do though.
Then I just talk to them and make sure we'll get along. And see that they've learned relatively new things recently.
I've fired very few people in the last 15 years. So I guess my technique works. The main reason I've fired people is that I feel they aren't growing as they should, or that they have caused problems. But as I said its very rare. And our attrition is also very very low.
I think a lot of companies have gotten out of hand with their technical interviews and they are making the process needlessly expensive for themselves. Recently I witnessed how they were interviewing someone I knew for traditional engineering positions. I was shocked to find out how non-technical the interviews were. And yet the engineering world isn't collapsing is it.
In my opinion, the single most important attribute of any candidate is potential. With potential everything can be learned. All the rest are easy to manipulate but asking people about former challenges and explaining a topic are actually very good questions. Both help to create a context that the candidate can expand and not just answer questions. The problem with this type of evaluation is that it requires the interviewer to be relevant to the domain, in other words to have a technical background when the job is about software. Unfortunately, due to lack of knowledge and insight in technology, many organizations want to hire someone based on a checklist on prior experience, usually on keywords that are not understood.
I also agree with the ability to explain a topic but it is very difficult to explain something to an audience that has no clue about it. It really puts the candidate off.
Thanks, Yaser! This article clarifies me some things about the technical interview process and when I was reading I notice that I made mistakes taking a technical interview.
Sometimes I feel I responded to some questions like a robot, giving the answer that the recruiter waits, because they ask me questions that, in my opinion, don't give any information about me as a programmer or how I work with teams.
The weirdest question I received was: which teacher did you have in X course? I responded and the recruiter told me: 'that teacher is not good and maybe you don't have enough skills' (after this the interview finished).
In my last interview, I was asked about what was the last thing I learned I respond like 'I am learning X and improving Y'. Then I was asked to give an example of what I learned (this question is the same as 'How do you explain X in simple terms?'). At this moment I felt that I was applying for a real tech job.
Yes, unfortunately we all fall into that trap from time to time