Do "business logic" skills and a framework replace the need for "low-level algorithm" skills?

Question

When interviewing people I ask some lower level language and algorithm type questions. Nothing too tricky, but I am surprised how often I here programmers who claim to be senior level say they mostly work in a framework (that maybe they designed) and don't typically have a need to do low-level coding.

Some of the questions I ask:

• The classic FizzBuzz
• Determine if two date ranges over lap
• Reverse a linked list
• Find a missing number in an array
• Write a date as roman numerals

Sure, I don't expect these things to come up in daily development, but I still think they are fundamentals that a developer should know how to do. My experience is that a majority of my programming effort is mundane adding a field to a grid or validating user input, but there is still a mix of needing new and optimizing algorithms and data structures.

As frameworks (both internal and standard) and languages get more mature do the basic algorithm and data structure skills ever become irrelevant? I don't think so, and besides problem solving skills and tenacity, that is what I look for in a developer (Short of the developer having domain specific experience in our small industry, which is rare.)

Edit: This only represents a portion of the technical part of the interview. There are other interviewers and other parts of the process.

Answer 1

If you are looking for problem solvers that can quickly work through problems, then there is nothing wrong with asking these questions. But, if the developer can explain how they would use built-in features of a framework to solve the problem, you should accept those answers as valid as well.

I'd caution though that there is a difference between someone who can hack out a solution and someone who is able to analyze a problem for similarities to existing problems and discover common solution patterns. Maybe basic design pattern/software engineering questions would be more appropriate.

Answer 2

Do the basic algorithm and data structure skills ever become irrelevant?

The short answer is, No.

The practical answer is more complex. Given the rapid evolution of languages and frameworks, the method for finding overlapping date ranges (as an example) that I learned 10 years ago is completely useless in my favored language today.

When I am looking for good help, or valuable team members, I place a much higher priority on problem solving skills than on anything else. I would much rather have my people be able to think creatively, and then go look in a reference for 'How to reverse a linked list'.

There has to be a balance in the good candidate, but I tend to err on the side of: Currently under-trained, but a good head on their shoulders.

Programming books are cheap.

Answer 3

There's a phenomena I keep coming across where someone becomes "Senior" by sort of "being around" and being able to fix basic code, knows their way around parts of the crummy codebase because they wrote most of it, and just sort of lingers in a kind of momentum-driven mediocrity. These people can usually, sort of get by. They don't improve things much, because they don't recognize where things are broken or could be better. They're unlikely to be terribly creative.

Do you really want to hire someone who can't program fizzbuzz? I don't think a senior developer candidate should have to rattle off code to implement a red-black tree (shudder) but you're not asking for too much. Personally, it pisses me off that so much of the industry is this way, and that people claim to do the same work as me without what I consider to be basic competance.

Answer 4

Nothing too tricky, but I am surprised how often I hear programmers who claim to be senior level say they mostly work in a framework (that maybe they designed) and don't typically have a need to do low-level coding.

It sounds like their skillset doesn't match up with what you are interviewing for. Otherwise you could just ask them to solve a problem in the framework, or something similar to it, and see how they do with it.

I can't imagine a software development job where you would never have to do low-level coding, and I am having trouble imagining what it would be like to be a software developer who couldn't code FizzBuzz in their sleep. The skills required to do virtually anything at all in a programming language are (I believe) a superset of the skills required to think for five minutes and then write down the answer to FizzBuzz.

Answer 5

No.

Smart and gets things done may still require a lot of other skills

Knowing the business is one thing, but knowing the framework's limitations will require knowing low-level details.

Also, communication skills always have been and are increasingly important, regardless of your area of specialty.

Answer 6

Tough question. I used to think anyone who couldn't code in assembly language was not really a programmer. If you couldn't cope with writing to memory mapped hardware or a port, well, what the heck could you do? If you couldn't do sphere-to-sphere collision in discrete time, what hope could you have of doing any physics at all?

I've seen a lot of low-level coding become, essentially, useless. I imagine that the front of what is useless is like a wave moving along up the beach.

Let's face it. A lot of programming now is knowing what's available in the APIs you use.

Answer 7

It always depends.

Knowing the characteristics of algorithms and data structures can become irrelevant if your company is based on churning run of the mill business apps. For 90% of the cases, I think knowing the difference between a binary tree, linked list, and hash should be useful.

If your products have loose specifications, it is possible that a framework can abstract complexities so that knowledge of lower level details are unneeded.

When your requirements become rare or specific, you will need to dig downwards.