This was over a phone/internet call (first technical screen after a non-technical recruitment call). Or are you saying our non-technical recruiter should be asking potential candidates to write a fizzbuzz?
I am interviewing candidates in the Fortune 10. We get a lot of fraudsters that have found a way to lip sync Webex interviews and do all manner of silly things to get marginal people hired into roles they aren't suitable for. After 25+ interviews, and hundreds over the last nearly 20 years of my career, I can tell you in just a few minutes whether I want to work with that developer or not. I don't have to ask them to code, I just have to ask them things about our day to day work that only real developers know, for example:
If you're writing Spring Boot applications, tell me about which jars you include in your build to do that. Oh you only use Spring initializr? Okay, well, then tell me about which jars you added to your project after that initial setup. You say you use Kafka in your current role, tell me what jars allow you to set up Spring Boot Data for that. Oh, you don't use that approach? Interesting. We looked at doing that, too. And then, hopefully, you get to understand what they are doing and what they know.
Interviewing for Angular: What is your least favorite thing about working with Angular? What packages are you using in your application? Have you had trouble with your CI builds in Jenkins (or whatever they say they use?) I listen to them and I ask questions that ought to be relevant to them.
I typically start "hard" and then if I don't get anywhere, I ease back. You stated that you write REST services? Tell me, what Java library do you use for making a REST call from inside your application? Oh, okay, another team did that, I see...
And so on. It becomes very obvious whether the person is bullshitting you. I recently interviewed someone for a tech lead role who says he had been a tech lead at another company but I was astounded by not only how bad his answers were but also by how little he appeared to know about the business of coding. Either the guy was lying to use completely or he was in a real creampuff kind of lead role where you don't need to know anything about coding, anything about the architecture of the system you are responsible for, or anything useful at all, really. How do I get that job?
>tell me about which jars you include in your build to do that
If you're doing this frequently enough, you probably have a template of which "jars" (dependencies) you generally use, so you probably don't remember.
If you're doing this infrequently, you probably googled what you need to include for what you want to achieve and forgot about it.
So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
> If you're doing this frequently enough, you probably have a template of which "jars" (dependencies) you generally use, so you probably don't remember.
You're being ridiculous. Being able to converse with other developers is part of being able to do the job. A very common topic of conversation is "what libraries are you using on your project? Why are you using X instead of Y?"
I expect every engineer I work with to be able to talk about the tradeoffs of using (or not using) any library in any project they've ever worked on. Knowing what's in your application is important with regards to size, speed, understandability, modifiability, etc. I consider this information far more important than if you can reverse a binary tree.
> So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
People who remember the dependencies they're using to implement things and can explain why they are using them are both efficient and competent. Most likely, anyway. It's not the only signal I use when hiring, but it's an important one.
