[zeroname]

> I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. I will probably never need to know how to write a BFS.

If I give you a description of what a BFS is, you as a programmer should be able to write one. A BFS is rather trivial. You shouldn't have to know how to write it, you should be able to figure it out. The same goes for implementing a linked list or the FizzBuzz problem.

As a programmer, you need to make up algorithms on the spot to solve business problems. You don't know the solution beforehand, you figure it out, that's your job. It's the key skill that basically separates you from a typist.

> There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it.

This is a different skill. It's an important skill, but finding errors in an existing structure and fixing it is different from being able to create that structure in the first place.

[TheOtherHobbes]

Depends on the algorithms. Some people can brute force something basic, and the brute force answer will usually be slow and stupid at scale.

I'm working on something at the moment, and one of the key features is that while there's a fair amount of data, none of the structures are particularly big - and are very unlikely to ever become big.

So my thought process is that stupid brute force algos are absolutely fine for this domain.

If I have performance problems I can look into optimising them.

If I had hundreds of terabytes of data to start with, I'd take a different approach, and I'd research - not invent, because I don't care to reinvent a wheel if someone has already produced a much better solution - more efficient algos.

If none of the above work, then I'd consider improvising something and testing how it performs.

Would this pass your interview process or not? Do you want someone who's going to brute force an answer to your toy problem and think they've solved it with something that works but is inefficient, or someone who has memorised a collection of standard answers but maybe can't improvise something new, or someone who is going to check what's already available to save time, or someone who can improvise a super-efficient answer and do it even if it's not needed?

Who would you pick?

Do you really think this question has a simple answer?

[zeroname]

> Would this pass your interview process or not?

Yes, that sounds very reasonable.

> Do you want someone who's going to brute force an answer to your toy problem and think they've solved it with something that works but is inefficient, or someone who has memorised a collection of standard answers but maybe can't improvise something new, or someone who is going to check what's already available to save time, or someone who can improvise a super-efficient answer and do it even if it's not needed?

First of all, let's talk about what I don't want. I don't want someone who can't solve the most basic problems. I'm not interested in all these details at this point in the process. Don't get stuck in analysis paralysis.

> Do you really think this question has a simple answer?

No, but it's not the question I am asking. My question would be, can you solve basic problems? I'm not looking for 100% accuracy in testing, that's impossible. Surely some kid fresh out of college will get an "unfair advantage" with something that's still on their mind, while some genius may have a bad day and fumble the test. I wouldn't personally pick BFS as a test either, but the fact that you should be able to solve it remains. The fact that "you may never need it" is irrelevant.

[antoinevg]

You're asking the wrong question.

For all software businesses there is only one question to ask candidates: "Can you help us ship working software that solves the problem of our customer"

What I can tell you is that there are a number of books written on this subject if you need help identifying the correct interview questions to ask.

[theamk]

But this question does not really tell me anything. It only has one possible answer, which is "Yes!"

If I had a magic truth-detecting wand, it might be a good one, but in practice, candidates may be lying or honestly overestimating their ability.

[jenscow]

That's just the type of answer I look for.

You're not someone who would look at the screen and just say "I don't know" (or thank me for my time and storm out).

[antoinevg]

The problem is that here you are optimising your test for https://en.wikipedia.org/wiki/Chutzpah.

Which is great and all, but it it's not a quality which correlates particularly well with the stated problem you are hiring for.

Now if you were hiring for the marketing department…

Repeat after me:

A good hiring process is one that will not be affected by the luck of the draw nor the personality of the candidate.

I've been doing this for a quarter of a century and I will tell you right now that the best engineers of my generation would indeed thank you for your time, never come back and quietly advise the extensive network of young people they mentor to avoid your company like the plague.

[jenscow]

Yes, I'm starting to realise that finding a candidate who's able to problem-solve something basic really is "luck of the draw".

[antoinevg]

I feel like you misunderstand me entirely.

You're going to have a really hard time finding good hires if you restrict yourself to the pool of people who can "problem-solve something basic" according to your definition of "something basic".

Maybe ask: "How can this person help the team ship working software that solves the problem of our customer?"

It's less adversarial and opens your recruitment up to that pool of folk who have literally decades experience answering that question.

[jenscow]

It's more like: There are so many candidates with impostor syndrome. I don't want to hire another turkey.

So, I will come up with a little problem which is something related to the work they'd be doing - like, a real thing they would have done if they where hired a month ago. (hmm, I wonder how they would have fixed jira-123)

I'm not looking for "the answer" - I'm actually hoping they don't know it (if they do, great: here's another...), but.. do they have what it takes to solve a problem? How much hand-holding would they need? Am I able to have a technical discussion with them? Even, where are they on the passive<->arrogant scale?

This, among other questions, will answer "How can this person help the team ship working software that solves the problem of our customer?"

Job history and qualifications don't tell me this.

If a candidate feels they're too important or experienced to do this, then by all means walk away.