Being able to make a clean interface, as in a clean API, or useful one, is a data structures/algorithms problem and often a distributed systems problem. Many API's are technically impossible to use correctly. For example they might not let you do two things atomically that need to be. Or they might suffer enormously because they don't version their information properly, resulting in client/server disagreements over the nature of reality that are impossible to avoid. Or you get components that are impossible to interrupt cleanly or shut down safely.

It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.

In my experience, architecture requires broad but not deep knowledge of data structures and algorithms. The best architects have both, but even very good architects struggle to remember algorithmic tricks on the spot and write detailed code without tools or references. People who can do that easily are often the last to think of things like fault tolerance.

You don't have to be some string algorithms weenie, but the kind of people who "absolutely hated" algorithms problems in my experience, some of it personal and some of it vicarious, are bad at making architectural decisions with far-reaching consequences. It's overlapping subject matter which uses the same kind of aptitude. It's not that to be good at architectural decision-making you need to be prepped for an emergency Google Code Jam.

A more charitable interpretation is that they absolutely hated "constant internship interviews".

In my experience, algorithm interviews aren't even very good at measuring aptitude for algorithms. Recent study and aptitude for the format have too much influence. Asking candidates about architecture has been much better at predicting their aptitude for architecture.

I don't necessarily disagree with that -- what kicked off my reply was the statement, "Honestly, it sounds like you may be geared more towards software architecture rather than software development." (And, you know, rereading that sentence removes any doubt I had about the correctness of my initial response.)

If you can rigorously ask architecture questions, and don't let people get away with hand-waving, that sounds fine. I've been asked good architecture questions and I've been badly asked bad architecture questions too, so... it depends on the question, and how you ask.

Designing something on an architectural level really isn't always a data structures and algorithms problem. Take the web, for example. REST isn't complicated, but it does the job and it opened up more possibilities than any other invention since timesharing.

As other commenters have noted, choosing an architecture for a system may have more to do with vision, common sense, and even imagination. And the web is such a great example of this, maybe the classic example. As you probably know, it's possible to write a webserver without having a clue about fancy data structures or algorithms. It's the imaginative composition of pre-existing features that creates the architecture.

Another example would be the extensibility of Emacs through elisp. Consider the notion of hooks which essentially allow utility functions to be customized by the user. It's a purely architectural concept.

Or the Unix philosophy: small utilities that read and write text, linked by pipes. Really no algorithmic complexity to it at all.

It feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems.

Vision and a perspective that differs from the norm are a lot rarer and potentially more valuable than the ability to apply software engineering principles. Architecture, in the broadest sense, is precisely the area where these "outside the box" contributions are likely to be valuable. Consider the invention of the Wiki. It came out of the pattern language world, it was a hugely beneficial innovation, and it has almost zero data structures/algorithms complexity behind it.

I'd even argue that the examples of pitfalls that you list are more clerical matters of systems programming than cases where architectural design principles are lacking.

(And even the professionals who can reliably grind out working code for large systems can get the architecture spectacularly wrong, as the case of the X window system: http://web.archive.org/web/20170920104011/https://minnie.tuh... )

>t feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems.

I really needed to hear this thanks.

Calling an idea problematic is a tell that he's not really concerned by matters like whether it's correct or not.

Web servers and clients, for example, are a case where I've seen bad architecting cause months of damage. An Emacs function hook or advice system, likewise, requires care in terms of when the hook is called, and what the rules for their scoping are. It's a bad software architect that thinks they can just slap callbacks on something.