i've always approved everyone i've ever interviewed because i believe that it's possible for anyone to learn how to do this kind of wok and with the anticipation that i will have to show them everything i know; but i've never had to, i've always been pleasantly surprised.
i would approve this guy before the interview as over. lol
Trying to sus out a candidates ability to learn and adapt is number one thing I try to do when interviewing. A question I ask a lot is “Give me an example of a time you got completely stuck on a task and how you overcame that.”
my go to question is: tell me about an time when you couldn't get something to work and how did you attempt to make it work? what did you learn from it?
Drag hates being asked that question. "Drag was stuck on a hard problem... And then drag figured it out?" Drag doesn't know how to explain inspiration. Nobody does, not even philosophers or psychologists have managed to explain that moment of insight where suddenly it all makes sense.
Usually when drag is stumped, the answer comes to drag three hours later on the toilet. So drag's standard procedure is to exhaust all available options, find something else to do for three hours, and then take a shit.
I've definitely had some coworkers that in retrospect we should not have hired. But I've also had people I was iffy on that turned out great. Hiring is hard.
What about hobbyists with no "standard" corporate programming experience, but have been noodling around with PHP/C/C++ for 25 years? (I'm actually not even joking anymore lol. Never had the self-confidence to try and make it professional).
I would have questions about how they work with a team and structure.
Are they going to be okay with planning work out two weeks ahead? Sometimes hobbyists do like 80% of a task and then wander off (it's me with some of my hobbies).
Are they going to be okay following existing code standards? I don't want to deal with someone coming in and trying to relitigate line lengths or other formatting stuff, or someone who's going to reject the idea of standards altogether.
Are they going to be okay giving and getting feedback from peers? Sometimes code review can be hard for people. I recently had a whole snafu at work where someone was trying to extend some existing code into something it wasn't meant to do*, and he got really upset when the PR was rejected.
Do they write tests? Good ones? I feel like a lot of self taught hobbyists don't. A lot of professionals don't. I don't want to deal with someone's 4000 line endpoint that has no tests but "just works see I manually tested it"
The other day I was updating something and a test failed. I looked at it and saw I had written it, and left a comment that said like "{Coworker} says this test case is important". Welp. He was right. Was a subtle wrong that could've gone out to customers, but the wrong stayed just on my local thanks to that test.
that used to be a thing when i worked there (early 2000's); we literally hired a guy who had no degree and his only experience was creating websites from scratch for the businesses that his rock climbing friends owned.
i'm sure they've raised the barriers significantly since then.