[hvidgaard]

I'm on the fence about that. Interviewing a senior developer, my experience is that it's still necessary to gauge their ability to code. Some can barely do it, I kid you not!

An if you claim seniority, I expect you, if not to know merge sort, then to understand it quickly and make a simple implementation and assume boring stuff like the length of the array ect. It is not difficult. It would be a great example to demonstrate programming proficiency and if you didn't know merge sort, how you grasp new problems.

I would put more weight on architectural discussion though.

[scarface74]

Notice I said I have no problem with pair programming type interviews.

When I interview developers, I have a simple skeletal class based on a real world problem we’ve had with failing unit tests. They have to make the unit tests pass. Then I give them another set of requirements and unit tests they need to make pass without breaking the first set.

When I interview QA people, I give them a version of the FizzBuzz test. I tell them they have a website that implements FizzBuzz. How would they test it. I want to see answers like this:

https://twitter.com/sempf/status/514473420277694465

[hvidgaard]

That works too, but the means to the end is less important than the result. I'm sure I would get the same from your approach, as I would with a simple programming problem question - algorithmic or not. Most of all it's a litmus test to see that they in fact know how to think in code. I really don't care if it's in C#, Haskell, or pseudo code - that's their tool of choice as long as they show the ability to solve a problem logically in code.

I purposely try to make it less dependent on environment and syntax because it's not important for the candidate to show that they can. I always interact with the candidate and try to get them to implement enhancements or edge case handling that's missing.

It's a minor part of the interview we get over with in the first round. But if they asked you that and nothing else I would've walked away too - no one with a clue have been involved in that process anyway.

[scarface74]

I very much care that they know the tools and are not just a good developer. I need someone who can hit the ground running using our choice of language. Learning a language is easy. Learning to use the tooling efficiently and learning the ecosystem takes time. I'm not hiring developers to write algorithms. I'm hiring developers who know whatever language we are working in. I'm not going to hire a PHP developer no matter how good they are if I'm running a C# shop. Why would I? I can easily find C# developers.

If they struggle writing code and don't know the syntax when given an IDE, why would I hire them?

[hvidgaard]

I'd rather have a developer with a solid understanding of FP, CI, integration testing, good programming practices, structure, refactoring ect., than one that knows the tools and tooling inside out. Ideally I want both, but if I have to choose it's the former. We have other developers that can get them up to speed relatively quickly, and they'll start with established projects anyway.

[scarface74]

So now you’re wasting money on not only the new hire, but also taking time away from your existing employees.

Besides refactoring is a lot different and the tooling better for statically type languages. Good programming practices is also about idiomatic programming that comes with experience in the chosen language.

[hvidgaard]

If I had to choose, the former is more important to me, and it works for us, I've not had a bad hire yet in a market where getting new developers is difficult.

Refactoring with or without tooling in static or dynamic languages, is about recognizing a piece of the code base that should be refactored and what the goal is. Tool and language can make this easier or harder, but that is again, something you can train them in and all new developers get a mentor for as long as they need, even senior developers.