I'm not going to speak to the homework type of problem (because honestly I think you should be paid for that sort of thing), but I always ask people programming questions in on-site interviews, not strictly because I want them to prove they can program (although that's one useful side-effect), but because I want to observe the candidate's problem-solving process. I can't deduce anything like that from your Github or a homework problem.

And that is entirely fine. I'm all for group white boarding exercises, or pair programming. I think there's a lot of value to be had in making sure the other person can communicate in a technical setting effectively, and explain why they make choices.

Likewise, if someone wants me to walk them through a project I have with explanations of what choices I made and why, I'm happy to do that. But please don't waste my time asking me to implement DFS, or write another twitter API client.

If the GH code is there, works, and is up to coding standards, why do you care about how the sausage was made? I'd look to see if the code is well-designed, organized, original, tested, etc. It's generally easy to see if the author of code knows how to decompose a problem into pieces. So..saying "we're looking for thought-process not the actual code" feels a bit disingenuous tbh.

Now: If you care about being able to collaborate on a tough problem with somebody, work on a problem neither of you has seen before together :)

Alas, I really do care about the thought process. If a person arrives at a great decision for bad reasons, I may not want to hire them. More importantly, though, I'm interested in when candidates pick not-optimal choices for good reasons. So much of software development is about tradeoffs. Seeing and hearing how they tackle those tells me much more about how they'll do than the specific code in question.

As an aside, the reason not to work on novel-to-you problems with job-seekers is that it's very hard to fairly compare candidates after. I strongly prefer pairing on the same problem with all the candidates in a batch. Otherwise it's hard to tell if a bad result is due to a bad problem or an unacceptable candidate.

> Alas, I really do care about the thought process.

Sure - but you're not likely to really see the "real" thought process you're hiring for by asking a stranger a riddle you already know the ansewr to in a high-pressure situation.

Real problem-solving and thinking is done in a huge number of ways that sometimes isn't conducive to strangers, pressure, or whiteboarding.

> I'm interested in when candidates pick not-optimal choices for good reasons

Right - which is why starting with something they've written on GH (which is something they've thought about and are probably passionate about) is a great jumping-off point for such a convo.

> As an aside, the reason not to work on novel-to-you problems with job-seekers is that it's very hard to fairly compare candidates after.

I see your good-intention here, but it's nearly impossible to compare two candidates without all kinds of biases (implicit and explicit) coming into play.

> I strongly prefer pairing on the same problem with all the candidates in a batch. Otherwise it's hard to tell if a bad result is due to a bad problem or an unacceptable candidate.

I think this may be another way of trying to compare candidates to eachother (which is perilous).

Good candidates can do well with bad questions, and bad candidates can rarely do better than okay with good questions. There are lots of good/proven questions you haven't solved - ask your colleagues.

If someone has a good GitHub profile I won't ask the candidate to do much or any coding exercises, because it's much better to just discuss the code they already wrote. I'll put it up on the screen and get them to talk me through it. I'll ask about anything that looks unusual, but also about anything that looks particularly elegant. Even if they wrote it a while ago they should still be able to talk about it.

> If the GH code is there, works, and is up to coding standards, why do you care about how the sausage was made?

Perhaps because, like many developers on modern teams which eschew the older role distinction, the incumbent in the position being hired for will need to act in the role of a classic system analyst in defining specific requirements give a fuzzy business problem as well as the role of a grunt coder.

Also, the presence, functionality, and quality of code on GH does not establish it's provenance.

> position being hired for will need to act in the role of a classic system analyst

Sure but that's a different skill from solving DS/algos, so don't conflate the two. Some people know their DS/algos super well but need to solve them solo, some people need to google around a bit for inspiration or take a walk if they get stuck.

Instead, separate it out. Give a specific "system analyst"-style question that's distinct from coding. A question you don't already know the answer to or that could be taken in a thousand different directions that you've definitely never thought of before.

I want to know how resourceful the candidate is, how quickly they make mental leaps and whether they'll play nicely with others in the team under the context of the work we're trying to get done. If the choices are a) find out first-hand by (gasp) asking for a demonstration of skill while I watch or b) try to decipher these things by shaking a tuning rod at their GH repository--then I guess we'll have to agree to disagree :)

Sure - my point is that asking them to solve a problem on their own that you already know the answer to isn't a realistic environment of "playing nicely" either and is only going to show you how they deal under pressure, not how well they collaborate with somebody who genuinely wants to find the answer and can build off of.

If you need proof they can "actually code" and use DS/algos etc, use their GH if it exists. And if you want to see that they can work on a team to define and deliver a messy problem with other people, do that with them on a messy problem you've never solved before. (It could eventually be a DS/algo problem; my point is it's a group effort and neither of you knows the solution; you're looking explicitly for how the interaction goes, not if "the candidate" got the "right" answer.)

So I'm supposed to spend my time researching your GH instead of just letting you spend 5 minutes proving it? There isn't enough time in a day to research every candidate's code they wrote on their own time (and personally I'd rather not be judged by mine). And, if people lie on their resumes already, what makes me trust their GH? It's like saying here's an essay I wrote, you don't need to talk to me in person, I"ll just stay home and you can decide whether you want to hire me.

Yes. It's a lot of work on both sides to interview and be interviewed.

If you don't take a candidate's prior art into consideration, you're wasting everyone's time. You're also eliminating candidates who may excel in ways that aren't solving riddle-problems out-loud in front of new people when their livelihood is on the line.

Start with the GH and if you have doubts fall back to portions of old model.

> So I'm supposed to spend my time researching your GH instead of just letting you spend 5 minutes proving it?

I've never seen a worthwhile programming q take only 5 mins to answer. And the candidate is supposed to waste an hour of her time proving to you what you could see in 5 minutes on GH?

> There isn't enough time in a day to research every candidate's code they wrote on their own time

Yet there is enough time to spend with whiteboarding problems that prove the same things the candidate has already proved on their GH?

> (and personally I'd rather not be judged by mine).

Sure - only use the candidate's GH if they prominently put it on their profile and/or own an "intended to be used/seen" public repo.

> And, if people lie on their resumes already, what makes me trust their GH?

Not a replacement for conversation! It's a way of indicating they can code without solving an arbitrary riddle in a high-pressure situation. If you're not convinced they wrote or understand the code you're looking at, ask them about it or ask them how they might change it slightly.

This is fair, it's just not realistic for a lot of places. In the places where I've worked and interviewed people, this was not my main responsibility. Typically I'd get a resume that morning and have to prioritize looking at it along with whatever else I had going on that day.

On the one hand, I agree entirely. An interview should not make people jump through hoops if they can answer their questions via existing material.

On the other hand, fakers have caught on to the "GitHub is my resume" thing. I have had applicants who have basically fraudulent Github projects, or who have taken group projects on which they did basically nothing and claimed them as their own. So a Github page now requires an expert to evaluate it.

Surely getting them to talk you through the code would solve that problem.

If its is their own code it shouldn't be a problem.

If it isn't their code and they can still talk you through it, even better - they have managed to understand code that someone else wrote which is probably an even more valuable skill.

You realize that your third second contradicts your first, right?

And no, having somebody who's an energetic fraud on the team is poisonous. Having somebody who's so good at it that they're hard to catch is worse, not better.

If people are genuinely a fraud they won't be able to talk about the code in a sensible manner.

I didn't write the monstrosity that I am working on just now, but I could explain how it works and I know where to look to fix bugs. I don't know why some crappy design decisions were made. Does that make me a worse programmer than if I had written it myself? Is harder to understand someone else's code than stuff you have written yourself. There are far more jobs working on existing code bases than on new new projects.

(My guess is that you have never worked with anyone who has claimed ownership of someone else's code, have you?)

> but if I have an entire github of highly starred and heavily developed projects with reasonable commit histories... don't make me do your do damned homework or implement a toy BST.

Unfortunately, the current common argument from the hiring side is that GitHub profiles are not sufficient proof of skill since code can be copied (not fair) and GitHub projects bias toward people with extra free time (reasonable, but not enough to discount GitHubs completely IMO)

Right. Don't "require" a GH, but use it if it's there!

Yes, some of the code may not be original, but unless the repo is a fork you can pretty easily see if the code is organized in a coherent way that shows the committer knew how to decompose a problem well. If they solved /every/ piece of the problem themselves, it may be a sign of a different problem (and also copy/pasting without citing source is also telling!)