As an interviewer or a senior software engineer who would want to hire someone new to your team, would you expect a person with a solid grasp of algorithms or a person who has good experience in the stack you are using? If both, what would be your priority?

It may depends on why I'm hiring him/her. If our stack actually need a good knowledge on algo, i'll prioritize it, and let him time to learn the stack if needed.

However, I'll accept if he knows well our stack

@Jakuho thanks:)

I agree with @Jakuho that it is definitely dependent on the situation. In general, though, I think most stacks take care of the heavy algorithmic stuff on their own, so experience with the stack would be more valuable.

As the others have said, it depends on the situation.

In my opinion, willingness to learn and passion will outweigh knowledge in a specific framework almost every time as one can mold the developer into something more than just what they were hired for.

But at the same time, if this is a senior position, one might need someone with the talents they offer, for example if it's a consulting gig and they're going to be around for a few months at most, the knowledge of the framework obviously matter more.

Just my 2c. We've had better luck hiring the passionate people vs the people who were technically sound but drab in the office.

I would always prioritise algorithms over familiarity with some stack (although its not that important either, problem solving ability and attitude is #1) picking up a fairly standard stack is trivial and if the stack is more complex than the systems built on top of it then something is seriously wrong.

Stack. Most jobs I feel like require just the basic knowledge of algorithms and you learn some of them with experience anyway. So experience with the stack seems like the better choice as they can start working right away. Most companies do not want to spend their money on educating juniors and would rather them spend their own on their own education, so even if some of you guys want to go for algo, it is unrealistic mostly.

@catadoxa thanks :)

As the varied previous answers suggest, you have to ask yourself:
- what is this person going to do on a daily basis exactly? (what do you need to complement your team?)
- Based on this, what skills does this person need to be successful in this job?

That should get you started.

You should interview him based on what his day to day will be. I’ve been to interviews in the past and questioned heavily on algorithms, but the entire time I’m sat there thinking “You going to ask me about JavaScript or .NET at some point because that’s what you’re hiring me for”. If the role requires frequent development of high performance algorithms then ask about them, but if you’re hiring for an iOS developer ask about that.

Unless we’re doing anything mental and super bleeding edge comp-sci wise I wouldn’t care too much about algo, plenty of pseudocode / implementations exist out there, and let’s be honest, unless it needs to be a super concern, space / time complexity simply aren’t that much of a priority off the bat.

I’d instead look for:

- Good grasp of the language (or similar)
- Soft skills like communication
- Knowledge of the stack: cursory fine if willing to learn

I’d then likely test for basic things like:

- Control flow
- Exception handling / management
- Comprehension of Boolean logic
- Functional paradigms e.g immutability, purity etc - even if not working in a functional language.

And then I’d want to see them design a solution, I want a dev that’s equally comfortable architecting as implementing for the broadest possible use to me / the team.