I personally don't care that much on how well a candidate can code, as measuring that is itself quite hard (in my opinion). What I like to interview for is someone who really likes to code. I look for things that demonstrate recent personal growth, ability to explain & teach something they do know, a tendency to avoid claiming they are good at anything, open mindedness on trying new things, etc. In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire.
> In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire.
My comment referred specifically to candidates with at least one year of full-time hands-on development experience under their belt. The typical candidate I interviewed had 3+ years of experience.
If you want to code, then you should have ample opportunity to do so during a year or more of full-time employment.
If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills.
Programming nowadays is easy - everyone has a powerful laptop and internet access. It's not like you need privileged access to some $100k time sharing machine using punchcards, and learn machine-language from obscure mail-ordered manuals.
What excuse does anyone claiming to "want to code" have for not coding already?
I'd be quite suspicious of anyone waxing poetic about their genuine heartfelt love for coding who somehow couldn't demonstrate any coding ability.
Would you believe someone who swears they "love long-distance running", but collapses after 50 yards and says they just didn't have the opportunity to put this great love to practice?
> If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills.
Genuine question... What kind of question(s) would I ask to get someone to demonstrate they can code? If my questions are effective, I'm fine. But if my questions stink, it'd be easy to overlook that fact that many excellent people wouldn't be able to answer them well.
There are different approaches, but you can come up with any simple programming task. Doubts are fine, so just run them through some of your existing engineers, especially those you think are really good. If people you consider excellent engineers fail them, then it's back to the drawing board.
That's an exercise I do for hiring in general. For example, every time a hiring process change is proposed, I run it through my existing engineers, and make sure I would have hired them by this process.
For example, in a place that was starting to get a lot of great candidates, someone proposed tightening the education requirements of the preliminary screen. I quickly observed that would have disqualified one of my best performers, who didn't have a CS degree at all. The proposition was therefore struck down.
> There are different approaches, but you can come up with any simple programming task.
My challenge internalizing this phrase is that I have a hard time latching onto the idea of simple. It's a highly subjective measurement. For example, if I ask an to implement FizzBuzz & they can't do it, to my satisfaction, are they a not worth hiring? I suppose it depends on what satisfies me. If my criteria for hire/no-hire is whether they wrote concurrent & streaming FizzBuzz, maybe my expectations are unrealistic. If I'm expecting someone to write FizzBuzz in as few characters as possible, am I going to flunk anyone who implements a verbose concurrent & streaming FizzBuzz? Is there a case where it makes sense to hire someone who implements Enterprise FizzBuzz? I may struggle myself with keeping things simple, so there's that to consider :)
Why ask any questions? Sit them down to a simplified version of a real world class your company is working on with corresponding unit tests and tell them to make the tests pass. That was one of my favorite type of interviews and I've used it before.
For simple questions to verify a person has basic programming competency, I'd keep it very simple. Any simple problem which requires you to use if / else if / else or switch case, or something involving simple for / while loop. This is something any programmer should be able to demonstrate.
