Assume people are smart, tell them about the actual job & and it’s responsibilities, tell them about the challenges of the job, ask them if it actually sounds like an interesting position, and then test them a bit on relevant things to see if they sounds reasonably competent.
Absolutely preposterous. Are you suggesting we interview folks for the job at hand?
Sarcasm aside, I’ve started interviewing people with “mock work day” style materials and it’s been pretty effective at determine who has been doing this for a decade, who can do this with a couple months to ramp up, and who is entirely faking it.
I’ll have folks combing through mock stacktraces, creating a new endpoint, connecting to a local database, and even doing a little bit of multithreaded design. I’ll assess completion against quality of the solution and factor in how long it takes someone to complete it.
That’s a difficult determination to make, but usually that’s the difference between someone who can walk me through the solution and stumble on the implementation, and someone who can’t explain to me what’s going on.
Lots of this stuff is language agnostic, so I keep that in mind too. For example, a stacktrace is a stacktrace in any language. However, we usually don’t extend offers to folks doing things for the first time, as we need a quick ramp up.
We generally don’t find it too big an ask for engineers to be familiar with the basics of Spring, or can SSH into and debug remote boxes. If someone doesn’t know this, they’re generally a college grad. Otherwise, unfortunately, it’s not the talent we’re looking for.
