I don't think that realtime coding challenges are the solution for the technical screening. I understand they help screening masses of candidates but they can't be the only way.
A lot of people, myself included, are not good at those puzzles and they get nervous if two strangers are looking at them while they fumble through syntax on a whiteboard.
I would probably still be a wannabe developer if the bar was that at every company or I would have chosen another line of work altogether.
What I'm good at is developing real world applications, reasoning on hard problems and designing abstractions. Most quizzes are not that.
People are people, they don't always respond the same way to the same things.
I also think we focus too much on the technical side which is 100% important, but not the only important part.
I've been on an onsite interview (which I failed) for a big company years ago in which you go through consecutive rounds of whiteboard interviews through the day (4 or 5).
Nobody talked to me about software design or company culture or ethics or technology in general.
With time I realised that even if I would have aced the whiteboard challenges and got hired I would have probably hated it there after a while.
No more riddles and algorithm puzzles. Focus on candidate experience, get their thoughts on benefits/drawbacks of different technologies. Focus on getting a sense for how a given candidate approaches problems. Systems engineering problems are usually good too, and I'd like to see more of those. Things like "how would you go about architecting an application to do XYZ?" and going off from there work well.
Yeah for sure. Those puzzles always feel so trivial. Curious to know how junior devs will respond to those questions. It's definitely a more common route in a senior dev or DevOps engineer interview. Have you had good experiences with systems engineering implementation scenarios? Add a feature to a codebase you're familiar with, etc?
At a previous job we used to walk through "How would you tackle the task of creating a class registration system for a local college?" It went well for mid level engineers -> seniors, but I never really saw a junior tackle that particular problem. Maybe something a bit more watered down would work better.
No more trivia questions. Don't ask me about what some obscure feature in a language does that I can look up in 30 seconds and get the answer to, especially when you don't even use the feature. You can never push back in interviews even when something is a really bad idea or inefficient way to do things.
When I did interviews, I basically ask questions that focus on their ability to approach problems and dealing with the unknown.
Ben, can you elaborate on what best practices you're describing here? Do you mean hiring best practices, what type of development best practices the potential employer is looking for during interviews? I'm curious to hear more!
I mean the orgs doing the hiring. Folks are all over the board and generally don't do a great job of learning from one another. So the process is not great in the end. If companies worked together to create better processes, the world would be a better place.
Thanks for clarifying and I completely agree! I wonder if the lack of business to business process transparency is mutually agreed upon and intentionally upheld. Keeping a certain level of ambiguity definitely gives companies more power over interviewees during the hiring process. It's also possible that companies are so caught up in this "war for talent" that they don't see the benefits of being transparent, especially when they could potentially lose engineers to direct competition that they're engaging in process improvement with.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No more whiteboard interviews :D
Think you might be interested in Whiteboardfree :)
Thank you, Victor! This is gold!
You're very welcome and so glad to hear it!
Absolutely. I've been through that hoop a couple times. What does your ideal technical interview process look like?
I don't think that realtime coding challenges are the solution for the technical screening. I understand they help screening masses of candidates but they can't be the only way.
A lot of people, myself included, are not good at those puzzles and they get nervous if two strangers are looking at them while they fumble through syntax on a whiteboard.
I would probably still be a wannabe developer if the bar was that at every company or I would have chosen another line of work altogether.
What I'm good at is developing real world applications, reasoning on hard problems and designing abstractions. Most quizzes are not that.
People are people, they don't always respond the same way to the same things.
I also think we focus too much on the technical side which is 100% important, but not the only important part.
I've been on an onsite interview (which I failed) for a big company years ago in which you go through consecutive rounds of whiteboard interviews through the day (4 or 5).
Nobody talked to me about software design or company culture or ethics or technology in general.
With time I realised that even if I would have aced the whiteboard challenges and got hired I would have probably hated it there after a while.
No more riddles and algorithm puzzles. Focus on candidate experience, get their thoughts on benefits/drawbacks of different technologies. Focus on getting a sense for how a given candidate approaches problems. Systems engineering problems are usually good too, and I'd like to see more of those. Things like "how would you go about architecting an application to do XYZ?" and going off from there work well.
Yeah for sure. Those puzzles always feel so trivial. Curious to know how junior devs will respond to those questions. It's definitely a more common route in a senior dev or DevOps engineer interview. Have you had good experiences with systems engineering implementation scenarios? Add a feature to a codebase you're familiar with, etc?
At a previous job we used to walk through "How would you tackle the task of creating a class registration system for a local college?" It went well for mid level engineers -> seniors, but I never really saw a junior tackle that particular problem. Maybe something a bit more watered down would work better.
No more trivia questions. Don't ask me about what some obscure feature in a language does that I can look up in 30 seconds and get the answer to, especially when you don't even use the feature. You can never push back in interviews even when something is a really bad idea or inefficient way to do things.
When I did interviews, I basically ask questions that focus on their ability to approach problems and dealing with the unknown.
More shared info of best practices! I feel like there are a lot of good examples but the industry is slow to shift as a whole.
Ben, can you elaborate on what best practices you're describing here? Do you mean hiring best practices, what type of development best practices the potential employer is looking for during interviews? I'm curious to hear more!
I mean the orgs doing the hiring. Folks are all over the board and generally don't do a great job of learning from one another. So the process is not great in the end. If companies worked together to create better processes, the world would be a better place.
Thanks for clarifying and I completely agree! I wonder if the lack of business to business process transparency is mutually agreed upon and intentionally upheld. Keeping a certain level of ambiguity definitely gives companies more power over interviewees during the hiring process. It's also possible that companies are so caught up in this "war for talent" that they don't see the benefits of being transparent, especially when they could potentially lose engineers to direct competition that they're engaging in process improvement with.