[cdicelico]

I'm sorry, but I don't care what you do—if you work in tech, you need to be able to demonstrate an ability to think algorithmically in order to solve problems with a computer. It's a) not acceptable to get by in tech without knowing anything about computers and b) not rocket science—anyone can learn!

[drdrey]

What you're saying is true -- but at the same time it is a bit awkward that there are things you need to work on for interviews only. For instance, I have never had to use linked lists in an actual dev job (~6y experience), but they come up so often in interviews that you just have to practice things like loop detection

[stmw]

It's a little awkward, but not so bad if it's within basics, like linked lists - which one may be rusty on but will generally know or re-derive - rather than really specific algorithms. But that's just a starting point, then it's about the interview and the communication and the interaction - exactly like the examples above of talking to real users or colleagues.

[user5994461]

I have to ask. What roles were you in? and what languages did you develop in?

[drdrey]

I was working on LLVM (C++ compiler) for 3 years and Java server backends the other 3 years. Those were the main products, with a side of Python, Groovy, Bash and JavaScript. In all fairness, I suspect LLVM uses linked lists internally for things like instructions in a basic block, but that was a level of abstraction under me.

[stmw]

Me?

[user5994461]

the poster who said he never had to use a linkedlist in 6 years.

[stmw]

Ah, I see. I guess it all depends on the meaning of "use",

[oldandtired]

This is less useful than you think. What you need is the ability to look at a problem and solve it. Understanding the problem is a lot harder than most people (technical experts) realise.

Far too often, the technical expert solves a problem on the basis of their current solution space tools and not what the actual problem requires. In other words, they cannot think outside of the solution space box they are stuck in.

Knowing that there are all sorts of algorithms available for all sorts of variations of problems and knowing where you can get the information to implement a solution to your problem is a lot better than being able to reel off one or two algorithms and not know that there are other solutions.

Over the decades, I have become involved with various projects that were created by "programming guru's". They knew the systems involved and made solutions that showed off their "guru-bility". The problem - well the systems were a nightmare to make changes to. They used "industry standard" practise and supplied a solution that forced people to change how they did their business, without actually considering the business at hand.

One such system was built using dynamically generated SQL. Had the original "guru" actually thought more carefully about the problem in hand, no dynamically generated SQL would have been needed and making changes to the system would not have been difficult. In that particular case, I was there doing "after the fact" technical and functional specs. As part of my package of documentation, I included a specification for rebuilding the entire system so that it would be very easy to maintain and change and the runtime for each system run would have been (on my estimates) reduced to about 5% or less on then runtime of 25 hours.

To get everything back on track generally required rewrites (sometimes complete rewrites) to be able to extend these systems.

It is our responsibility to enhance the end-user experience not make life easy for ourselves.