Hiring a web architect shouldn’t be about the most popular technologies

I’m not going to pretend that creating questions for job candidates is easy. But there are some questions asked that are inexcusably bad. Today I’ll write about a pet peeve of mine: asking web architects whether they know about the latest cool toys that developers use. There are many examples of this, from questions on the flavor-of-the-month JavaScript framework or questions on some command-line tool that no one uses, but the worst example I can think of is asking a web architect about CSS Sprites. Before I get into CSS Sprites, though, I’ll need to take a step back to make sure we have a common understanding of what it takes to successfully deliver software and what that means for performing an effective interview. Since many of the assumptions underlying my recommendations are counter-intuitive to many people in IT, I’ve included links to other blog posts so you can read more where appropriate.

The most important aspects of project success

I wrote earlier about how to create job interview questions. Basically, you need to outline what needs to happen to achieve success, then break that down into KSAs (knowledge, skills, and abilities), then ask questions based on the most frequently-occurring and most important KSAs that show up on your analysis. So, we will need to start by looking at the most important things you need to get right in order to give your software project the best chance to succeed. According to Software Estimation by Steve McConnell, the most important factors that determine the success of your project are (in order):

1. Product complexity
2. Requirement analyst capability
3. Programmer capability
4. Time constraints
5. Personnel continuity (turnover)

I’ll come back to this later in this post, but I will point out that the skill of the developers comes in third on this list, behind product complexity and quality of requirements. Use of software tools, a staple for technical interviews, falls all the way to #10 on McConnell’s list.

Problems with the typical software management structure

One of the assumptions I’m making in this article is that if you’re going to be cutting-edge on your technology choices, you’ll be cutting-edge in your management structure as well. I know that’s not a safe assumption, so here are some signs that you’re using antiquated leadership team structures:

1. A business analyst (BA) talks to the business user to understand what the business user wants.
2. The BA then creates documentation outlining what is needed, including designs and mockups.
3. These suggestions are then given to the web architect. Depending on the team, some back-and-forth may occur based on what the technology can do.
4. The web architect then makes technical specifications based on the design.
5. The web architect then brings the designs and technical specs to the developers, and the developers start writing code.
6. Throughout this process, a non-technical project manager is overseeing the project to ensure the team is staying on track to meet time and budget needs.

Let’s count the problems with this process:

1. The technical team needs to know what the business requirements are in order to effectively make suggestions about how to create the best product for the money. Having a BA between the architect and business team severely hampers this process.
2. The best solutions are almost always designed by people who know both the business problem at hand and what’s possible with the technology. All too often, the BA understands neither of these and just gets in the way.
3. The web architect doesn’t have direct access to the business leader, meaning he/she must make assumptions as to what is actually needed and make design decisions accordingly.
4. When a project manager on a software project doesn’t have hands-on experience in software, it becomes almost impossible to correctly identify the underlying issues when problems surface. As a result, the project has a good chance of going sideways if issues occur.

A better leadership structure

As I’ve described in previous articles, the smoothest-run projects I’ve been a part of have always been led by a single person on the business side who could make decisions on behalf of all stakeholders and a single person on the technology side with a good understanding of the business problem at hand AND the technologies being used on the project. That puts a lot of responsibility onto the shoulders of the technology leader, but that approach leads to better communication overall and better solutions.

The technology leadership position is best filled by an architect – someone with enough technical experience to understand what the technology is capable of, but with enough business understanding to be able to implement solutions rather than merely fulfilling requests. Small projects can usually be run by an architect with the aid of project management software. Larger projects may need the help of BAs to create documentation and project administrators to track progress, but there should be no ambiguity in that the architect and primary business stakeholder are the primary decision makers on the project.

Additional duties

One last thing before we get into why CSS Sprites specifically are such a problem in job interviews: any good web architect, at least one that serves as a trusted advisor to business leadership, must know what new technologies are available to solve problems in new and more efficient ways. When I say this, most hardcore technologists will think of minor improvements (like CSS Sprites), but in reality most of these improvements do more to help the developer’s self-esteem than to improve the end product in a way that is noticeable to the end user. No, instead I’m talking about larger industry trends, like helping both business users and the development team understand how artificial intelligence can be used to deliver a higher quality solution at a reasonable cost.

I’m sure at this point that many of my readers are thinking that the responsibility for artificial intelligence belongs to the data science team. And yes, that’s true, but only to a point. Remember how I said that projects need a technical architect overseeing how everything fits together? Without a single technology leader to maintain continuity and direction, your project risks turning into a hodgepodge of misapplied technologies. A non-technical project manager or business analyst is not equipped to oversee the whole product.

What’s a CSS Sprite?

Ok, now that I’ve covered some conceptual background, I can finally go over what a CSS Sprite is and why it’s useless useful. Whenever you load a web page, your browser needs to go back to the server to get any images that should be shown on that page. Sometimes this may only be 2-5 images, but in an image-heavy site, this could mean your browser would be going back to the server for more information many more times, which is slow and cumbersome.

To solve this problem, web developers came up with a solution that would combine several needed images into a single one, then use CSS to show only the portion of the image that is needed for that section of the page. (That’s a rather bad explanation. Click here for more information if needed.) It’s faster and more efficient to load a few large images than dozens of small ones.

There is a downside, though. Because several images are placed into one side-by-side, a front-end developer has to be more careful in order to ensure there isn’t half of one image and half of another showing up in a single space, or that images aren’t cut off when using different browsers or mobile devices. It’s more work to build and maintain.

That sounds useful. Why not ask about that in a job interview?

Ok, I’m hoping by now that doesn’t actually sound useful to you. It seems to me to be the perfect example of developers putting in a feature that helps their self-esteem more than the perceivable product quality, but if you’re still not convinced, consider the following:

As a reminder, the two most important factors in whether your project succeeds have nothing to do with writing code. Granted, the study referenced by the book was done before the rise of agile methodologies, so in theory product complexity should no longer be as much of an issue. But too many business and technology leaders think that you can run daily meetings and call your releases “sprints” and that makes what you’re doing “agile”. No, a real project leader must be able to sell the true benefits of agile – including helping craft a solution that follows Albert Einstein’s adage: to simplify the solution to ensure the product is as simple as possible, but no simpler. (Click here for a post about how software development teams all too often fail to do that.) Then, as mentioned earlier, the architect must be able to understand the needs at hand from a business point of view in order to design the right solution. More interview questions should center around these concepts. So, if questions on topics like CSS Sprites are asked of an architect during an interview, one of the following is probably true:

1. The position is an architect position but is within the bad management structure I outlined above
2. The position is not actually an architect position, but rather a senior-level developer with another title
3. The company really has no clue what a good architect looks like and is asking whatever questions come to mind

That doesn’t mean that technical questions shouldn’t be asked. But most of the technical questions that are asked should focus on the aspects of software products that actually do make a noticeable difference in value, such as creating reusable components (more reliable and lower cost than constantly building from scratch) or top-notch error tracking and notifications (which means errors get found and fixed immediately). A good architect should know about the existence of the latest tools in case they do solve a particular problem on the project, but again, applying every tool everywhere is a sign of bad judgment and candidates that display this quality should be considered cautiously.

Final notes

To be clear, just because questions about CSS Sprites shouldn’t be asked of a technical architect doesn’t mean that questions on CSS Sprites are bad for everyone. Back to my very first point, you should ask questions directly related to the job at hand. It’s all about context. A front-end developer working on sites for people with slow connections should absolutely know how to create CSS Sprites. But if you need your architect to know something like CSS Sprites, which adds little-to-no value to the overall project, then either:

1. You’re not using your architect’s skills well, which is a sign you’re not ready for your technology team to work with the business rather than for the business.
2. You’re not running your project well, and you should be getting your “I’m sorry it doesn’t do what people want, but I did what I was asked to do” speech ready.
3. Your sense of Return on Investment (ROI) is skewed, and you don’t really understand what’s most important for your software product to succeed.

Let’s stop having our architects hide behind business analysts and project managers, so they can design better solutions. Let’s stop focusing on technology and hoping that we can add business value without understanding the business context. And let’s stop asking irrelevant questions during job interviews.