I’ve been interviewing with several large companies for a  role in software development management. I got through to the panel round of interviews with a nationwide retailer to work with their e-commerce presence.

Prior to this, I did a little homework and did what I often to do gauge the maturity level of a company’s website, looking for any obvious issues, the kind of technology used, and evidence of UX/UI consciousness.

I found some glaring issues, such as terrible page load times stretching up to 8 seconds, which is a huge no-no. In addition, page analytics from GTMetrix gave it a failing mark, as did Google’s page speed insights. A product page took a whopping 180+ HTTP requests to load — a number I’ve never seen before (most sites keep it to under a third of this value).

All are red flags that indicate the need for attention – the page will take time to load, causing a penalty on Google, not to mention customers will drop off; and the extra load on servers would potentially cause scalability problems.

The interview was with my future (non-technical) boss and with several of their existing web front-end developer team members that would have been my subordinates. After the normal pleasantries, the developers proceeded to fixate on my thoughts about the latest in front-end technology, rattling off a list of technologies and whether I had used them or not (some I had, some I hadn’t).

I stated that frameworks and technology change and by necessity, there is always a need (and desire by developers) to keep trying new frameworks, but there are some issues with the frameworks that exist today that need to be understood in the context of the larger whole.

These issues have to do a lot with the size of frameworks. It is too easy to pull in an entire framework to do something as small as styling a button (e.g. Bootstrap) and now you’ve impacted your page load speeds by some fraction of a second.

One interviewer was critical about my experience with one of the older UI frameworks that we used in my previous projects. But a framework is just a framework – a simple way to avoid the tedious Javascript programming needed to pop up a dialogue box or a panel or a lightbox – there really isn’t much magic to it. There is nothing that a framework provides that cannot be achieved by a good programmer.

Some frameworks take a complete ground-up redesign from one version to another, rendering prior knowledge completely useless, or even dangerous. Interviewing or hiring on the basis of knowing Angular 3.0 or this or that is silly. You need to figure out if the person you’re hiring can adapt to new technology as it comes out.

I went on further to emphasize that a lot of front-end design is necessitated by having to bow down to Google’s presence, and that several technologies are currently incompatible with good SEO – SPA (single page applications) built on frameworks like Angular are terrible for SEO, and not a good candidate for building out sites that benefit hugely by having their catalogue pages indexable for customers searching for products.

I went on to say that a single page product view is enhanced by bringing in other critical customer-facing information, such as in-stock information through better investment in backend and web service systems and established means such as web service and AJAX calls to bring information to the user; and that the latest UI frameworks, while fun, don’t replace the need to deliver these fundamental features, when the goal is increasing conversions.

The feedback after the meeting: I did not know enough about the latest technologies – thanks for showing up, but we’re passing on you. While somewhat miffed, I was actually relieved, because that was not the kind of organization I would have liked to work with if that was the deciding factor.

Lessons to impart:

1. Do not have your developers push a “shiny is better” mentality onto your hiring decisions. Sure, always keep abreast of the latest technology and see how it can apply to your business, or to the efficiencies on your dev team.

Remember that we’re solving problems, not having fun with one pet framework or another. A good, decoupled architecture will allow usage of different frameworks or technologies to solve problems as needed irrespective of technology – this is Amazon’s approach.

But do not forget to keep pushing the fundamentals – page speed, functionality, SEO-friendliness, user experience. Not one of these elements would have been improved by plugging in the latest JQuery/Angular/ReactJS/Polymer/Web Component framework. What is needed in this case was a roll-up-your-sleeves focus on reducing some of the code bloat on these pages. These frameworks may speed up development (great for programmers, probably product owners and stakeholders), but have the downside of slowing down responsiveness for the client.

Somewhere an architectural decision went wrong with this company’s site and needs to be solved immediately.

2. There is a fundamental problem in current interview processes. I’m sure some good candidates will drop out of a process that relies upon a scorecard of technologies. Fewer but harder questions need to be asked, deep-dives into specific areas such as architecture, or more self-awareness and reflection needs to exist in the minds of the interviewers. An interview cannot necessarily be factored down into a bingo scorecard of technologies. Some testing of ability should be there as a minor formality.

The prospective candidate should talk to the team to assess the environment, the challenges, and exhibit some leadership or analytical skills.

Interviewing well is a skill — not only for the candidate, but for the prospective employer as well.

I would have, for example, been happy to whiteboard a few things, understand the situation, maybe outline a potential plan, just given a few specific details on challenges, or heck, a scenario.

This is where you can start gauging someone’s ability to think and problem solve, and get a glimpse of how they would be to work with.

I always itch to be in a room with a whiteboard and pen and to want to jump up and start drawing stuff.

3. Is it appropriate for staff to interview their future manager? Does a sports team interview their future coach? I don’t think so. I think it is a very big mistake contained in a cosy, touchy-feely, inclusive wrapper.

Will staff be amenable to a new manager who has increased oversight when they have been happy with a lax environment? Is there a particular management style that you require from the manager that the staff do not understand? Can the candidate ask frank questions about existing staff issues and things that he/she will be required to fix? The whole issue is fraught with complications.

Did my comments on adhering to fundamentals and being cautious about adopting new technology not resonate with those that are keen to be using the latest, but show a considerable blind spot with regards to the fundamentals of good UX (as proven by the 3rd party statistics)?

4. If you’re a non-technical boss, how do you interview a technical person?  I raise this question as this was probably the rationale for including the team members.

Naturally, I addressed the working style with the future boss, but I sensed a distinct deferment on the boss’s part to the technical folks to conduct the interview. There was very little “managerial” level talk.

I feel a manager in this situation should try to assess in the candidate the ability to keep up with technology and to keep an open mind on adoption, to act as a bridge and enabler between the various departments (marketing, development, operations), and to get a sense of how he/she will manage his subordinates, a sense of communications ability and political tact.

5. Technology moves on. Knowledge becomes outdated in mere months. Leave a manager to trust the subordinates who are in the trenches to play with new stuff and to recommend stuff that is worthy of consideration, and to know what sort of effort would be involved in doing so. Make sure the manager can create this environment. It’s great if the manager can also be somewhat hands-on, but the developers are ultimately the ones who will have to do the implementation anyway, so they need to be the ones with a large amount of input in this.

Regardless of the outcome, it was a very, very instructive process. I wish them all the best of luck, of course, but, boy, I really wish they had done a better job of the interview. Those nasty page load times indicate that lots of work needs to be done, and quickly.