How I interview developers

Or, do unto others as you would have them do unto you.

Interviewing is one of the riskiest activities a team lead or technical manager is involved with as a standard part of their responsibilities, the consequences of which has the potential to leave a lasting mark on a team. The gap between a dream hire and a nightmare hire is wide and stark.

As an activity however, recruitment tends to be sporadic and infrequent. If it’s something being performed day to day you quickly accumulate experience. If it’s once or twice a year, or every couple of years, it can take quite a while to start learning from our mistakes.

I also feel this is an area that because we may feel unsure attracts a lot of posturing and seeking of magic bullets. A desire for processes that will simply drop out good results from them regardless of our performance within them. This has I feel led to some odd practices toward recruitment in our industry that are I feel self defeating.

So I thought I’d share how I interview people, and why.

Determine the possible size and shape of the role

I try and keep requirements to the absolute essentials in order to do the immediate job. I don’t know what I will find, and I limit my options if I start artificially filtering candidates too stringently. I am prepared and hope to be surprised.

I avoid looking for any qualities that aren’t actually going to be exercised. This may sound like an odd thing to say, but I feel it to be very important. I seek those qualities that are actually going to be required, rather than because they sound good. It’s an artificial constraint to start filtering candidates on the basis of communication and presentation if those qualities aren’t going to be stretched.

I list instead the different ways a candidate may contribute to a team. If we have a couple of gaps, no really good tester or anybody with QA experience. Maybe we have too much bias toward the back-end and are finding friction working with the designers. Maybe an existing person could use support as we experience pain every time they’re on vacation. I talk with the existing team and other managers about this, and develop a view of the different kinds of person that may be attractive for us. This may be narrow or it may be quite broad especially if the hire is simply to add capacity.

Sifting CVs

I avoid doing this without another pair of eyes involved, even if only cursory. Invariably I rope in a senior dev to also go over CVs independently of me. There’s too much opportunity for one individual to skip over or sell short an aspect of a CV. Equally it’s easy to miss a warning sign. The senior dev can whip through the CVs quickly as they’re only looking to catch what they feel to be potential mistakes on my part.

I am looking for breadth and depth, with both depending on the seniority of the role. I look for different languages and platforms. A range of employer types. As much diversity of experience as possible, because ultimately I have begun the process of trying to find a developer that is able to learn and grow over the course of their career, engaged with a job they enjoy. While I am happy for a developers career to have points of focus and themes, I tend to steer away from CVs that express only experience with one of the currently dominant development stacks. All approaches have weaknesses, and they have no point of comparison or counter experience from which to compensate.

I find CVs that simply list every technology the developer has ever been sat in the same room as difficult to consume as they don’t relate to me the developers competencies. I don’t ignore such CVs entirely, but I don’t find them as useful as CVs were the developer has engaged in some critical thinking about what they feel is most important to present and give emphasis.

While it is a definite bonus to encounter CVs with some personality expressed in them, it is only a bonus, and I don’t regard badly those who don’t. Some people feel it inappropriate and potentially risky to inject personality into a CV, and not without reason. I feel it then unfair to expect it, but as I say it is a bonus when it’s there.

Those CVs that make available source code for review are the most useful CVs I can receive, but unfortunately are very rare. They allow me to from the very beginning of the process to determine whether or not the candidate is capable of programming in a way I find appropriate. Nothing else on a CV will provide me with this information. At this stage I don’t need to review the code, a quick scan of a repo will tell me if there is enough substance to the candidate to warrant speaking with them.

I don’t regard it as a black mark if a developer doesn’t cite source code, as it’s not the norm in my corner of the industry. I am however going to need to put eyes on some code the developer has produced at some point and if that’s right at the beginning, well early feedback is always good.

I make notes for each CV citing the reasons for either wanting to speak with the candidate or not. Whoever I’ve roped into also quickly giving the CVs a once-over can challenge any of my reasons.

From this I have a rolling list of candidates to speak with.

Phone screening

I prepare a series of open-ended questions to ask the candidate on the phone. I plan on the screening interview to take up to 20 minutes, but I’ll cut it short if there is no traction with the developer.

After exchanging pleasantries with the candidate, I confirm what they’ve been told about the position by any agent or HR, and clarify broad details.

I make it clear that this is a quick screening interview, that if we move forward they will be afforded an opportunity at the next stage to engage in a full interview process. It is explained to them that they’re going to be asked a series of mostly quite general questions that they’re probably going to have reasonable answers for, and that the emphasis is on what a thing represents to them, rather than trying to guess the answer I’m looking for.

The candidate is told that at this stage and any future stage, they are able to correct themselves if they feel with a couple of minutes hindsight they’ve just said something stupid, and that doing so will be seen as a strength not a weakness.

A chunk of the questions will be very general indeed and will tend to be along the lines of “what does XML mean to you?” There’s a huge range of possible answers to that question without getting into right or wrong. What answers the candidate gives will start to tell me about their background and the sort of work they have been doing. Do they talk about data-modeling, serialisation, interchange, schema, configuration? Do they mention the word “extensible”, and does it mean something to them? Maybe they talk about how and why they prefer JSON. They may similarly be asked “what does OO mean to you?”, again with the range of possible answers wide open and likely to tell me much about the candidates world view.

I avoid phrasing questions in a way that is likely to encourage the candidate to try and guess what the answer is that they think I want to hear.

Just a couple of questions will ensure basic awareness of what is going on around the developer on a particular platform. So, for a .NET position I may ask “what is a lambda, and how might you use it?” or “what is an extension method, and why might you use it?” These questions are intended primarily to see if the candidate is paying attention to basic developments on their platform. They afford the opportunity for the candidate to volunteer a view on injecting strategies, or perhaps to comment on their extensive usage in LINQ. Because the questions don’t focus tightly on right or wrong, they allow the candidate to give me an insight into their background.

I expect senior developers to be able to give succinct and while not necessarily complete answers considering the context of a quick phone screening, to some degree defining answers.

I expect junior developers to be able to kick the ball in the direction of the goal, and to hit the target on a couple of occasions.

I’m not overly interested at this stage whether or not I see eye-to-eye with the candidate in their answer to an open ended question. It doesn’t much matter to me if the candidate favours NoSQL over RDBMS, it is interesting to me if they have a reasoned view on the usage of the two. If I ask them what technical sites they use for news, I’m more interested to see that they do exercise an interest in the broader industry, if they happen to be looking at a different end of it than I, that’s not terribly important.

I value honesty, and I’m greatly encouraged if the developer is able to simply declare “I don’t know” when they don’t.

From this I have a rolling list of candidates that I feel warrant investing the time in a proper face-to-face interview.

The face-to-face interview

The face-to-face can take as little as 30 minutes for candidates that are obviously out of their depth, to as much as 3 1/2 hours where things are going well.

There are a couple of things I want to achieve in the face-to-face interview above and beyond the predictable exchange of information about company history, duties, roles, and work history, the order of which isn’t terribly important and will depend a lot on the candidate and how the interview progresses.

I need to eliminate as much of the candidates fear as possible

It’s beyond clichéd to say “fear is the mind killer”, but it really is. Very few people perform well at all while afraid, and those people that do I may or may not want working for me depending on other aspects of their character. Moreover many people start to exhibit odd or uncharacteristic behaviours when they experience pronounced fear without support.

This is where myself and any potential reader may diverge for legitimate reasons.

There are roles where it is legitimate to test if the candidate can deal well with highly stressful situations. Consultancies and agencies that parachute bodies behind potentially hostile enemy lines, on their own or with minimal support. In these cases the candidates ability to code while terrified may have some merit.

It is I feel crucially important to be extremely careful to consider what qualities we are scrutinising the candidate for, and whether the manner of our scrutiny will actually expose those qualities. To scrutinise for qualities that aren’t actually a requirement is simply to apply an artificial and erroneous filter upon prospective developers. While my team members will have stress as part of their working lives with me, and they will have bad days, they will never be facing these things without my full support and the full support of a team that they respect and trust. Asking candidates to jump through arbitrary hoops is a counter-productive and abusive practice, that speaks more to the insecurities of the interviewer. Dehumanising people is rarely a good solution to a problem especially so in people-centric processes.

I make it clear what it has been that has impressed me about them and why I have invited them to interview. I also make it clear that given the current market for developers, they’re going to get a job, the question is whether that is with us or another company.

The candidate is told I am not interested in testing their ability to perform well in interviews because their job will not entail sitting interviews… Again in a more consultancy oriented environment it may actually involve similar… If they experience a brain freeze, go blank, experience a mini-panic attack, it’s okay and not terribly important to me. They wont be judged if the circumstance of the interview causes a bad reaction in them. Interviews are tricky, and a bit weird. It’s okay if they are a bit weird as a result.

When candidates realise that you’re not going to torture them, and that coming in for interview today might actually end up an enjoyable experience, they often become very grateful. You can see the look come across their face the moment they think, “nobody is going to try and shame me here”. This needs to be reinforced throughout the interview.

In most cases, and invariably in every case where the candidate is successful they will relax at this point and change gear.

It is my belief that most of us share two common fears in an interview. The first is simply that we will experience shame. The prospect of shame bends nearly all of us out of shape. Those that it doesn’t tend to have quirks of personality that may not make them healthy members of a team, but that’s out of scope of this piece. The second fear is that we’ll be misunderstood. That we wont manage to show the interviewer the best of us. These fears can distort the person in front of you to the degree that you’re no longer getting useful information about how they will actually perform within your team.

Therefore the candidate is told, that if at any point of the interview they simply want to tell me something about their work history or a cool thing they’re proud of, that they should simply volunteer it. They are instructed that they should not find themselves walking away from the interview wishing “if only I had told him about X”.

The probation period

Early on in the interview I tell the candidate that we exercise a x month probation period, and that we take it seriously. There is nothing to be gained by the candidate misrepresenting themselves or being disingenuous in trying to “win” the position, it’s not in their interests or ours. They should relax, and just be open and honest with us.

Best and worst

I ask the candidate to tell me about about a project they were involved in that they feel proudest about and why. I ask them what are the things from that project they are most enthusiastic about carrying forward into future projects.

Then I ask the candidate about a project whose involvement with they are least proud of. What their mistakes were, and how this project has informed their practices since.

This is a crucial stage of the interview. It is vitally important to me that my developers at a simple level are able to cop to their own mistakes, hopefully correct them, and most importantly learn from them… I am tolerant of mistakes, but not their repetition… Developers who sweep their mistakes under the rug and hope nobody notices are a liability. Developers who do this are also likely to engage in disruptive behaviour in the team in order to cover for their failing.

Understanding our failings is also essential to the process of learning. If we are unable to reflect upon our mistakes we are unable to learn from them. If we are unable to share those mistakes with our peers, it becomes an obstacle to learning with them.

There are very few outright failure criteria in my interviews. The candidate who attempts to dress up a strength as a weakness… I try too hard… will be challenged gently but firmly on this point. If they pull off a convincing U-turn, I wont hold it against them as the conventional mode of the interview process encourages the candidate to misrepresent themselves. If they are unable to reflect upon past mistakes in a simple and honest way, the interview probably wont proceed its full course.

When did that work for you, when did it not work for you, becomes a recurring theme of the interview.

The code test

I don’t normally do on the spot code tests.

In ideal circumstances the candidate will have code available for me to review, and we’ll do that together. This hopefully is an example of their programming unconstrained, and an exposition of what they consider to be their best.

I am interested in seeing their best. Their worst code will look just like my worst code, which is terrible. I want to see their best as it’s their best I intend to get out of them. Seeing their worst code does not tell me anything at all about their best code, it is therefore next to useless to me.

I’ll underline that… I need to know what their best code looks like, not their worst.

Unfortunately most developers currently don’t have repos to show, and indeed this has tended to be why recruitment processes in the industry have gotten so bent out of shape. So bent out of shape that many companies wont look at source code when made available by developers focusing only on their own tests, which in turn demotivates developers from maintaining projects to present to prospective employers. It’s a vicious little circle we’ve established here.

If the developer doesn’t have code to show, I will negotiate with them a mini-project that looks something like what they’d be doing for us, but feels comfortable enough for them to feel confident about giving a good account of themselves. I’ll try and base this on what they’ve related to me in interview, so if they’ve raved about design pattern X, then we’ll find a project that allows them to demonstrate it. With senior devs we’ll negotiate a kink of some sort that will stretch them a bit.

The test is outlined in such a way that the solution is neutral and doesn’t tie it to our company, allowing the developer to reuse it as a demonstration of code with other companies if they’re not successful with us, meaning they get something out of this test process and aren’t just sinking time into us.

Given that the candidate represents well in other aspects of the interview, what they have available in terms of code to show, or what they produce in the code test will often be the deciding factor between them and other candidates.

They can do this test either in the our office or at home. I don’t much care how much time they want to spend on it, if they want to invest a lot of time in it, good. Why would I stop them? The more they do, the more I have to consider.

Ad hoc questioning

While having general discussions with the candidate about their work history and competencies, I will drop in ad hoc the sort of questions that would normally be given in the form of an oral or written test… “Tell me, what’s the difference between a value type and a reference type?”… While the developer is engaged in hopefully animated discussion about things they want you to know, they forget to be afraid of such casual questions as things are evidently going well.

Over the course of an interview I can ask all the questions I want of a candidate without them ever feeling interrogated if I simply ask the questions the same way I would to somebody I was having a friendly conversation with, because that’s what is happening.

Second interview

Often there will be second interviews, but not always. It’s really more a matter of revisiting candidates where there is perhaps a choice between two or three strong candidates.

Second interviews will invariably involve other managers and members of the team, focus on how the candidate may fit in with the company, and will tend to look like follow-up interviews in a lot of places. By this point the candidate is likely to have a good level of confidence, be enjoying the process, and have a strong sense that things are going well. Starting to dig robustly into the candidates practices, work history, or how they work with others, especially if it is a senior role, is quite possible at this stage without freaking the candidate out.

If after a second interview it’s not clear to me if a candidate is the right choice, then they’re evidently not, and the process needs to continue.

Avoid the expectation that good developers think like me

Many of the best people I have worked with are nothing like me at all.

When I look back at a younger version of myself, I am ashamed at the number of articles of knowledge which I would insist all “good programmers” should know, I had in fact only learned myself six to twelve months prior. Things that I encountered from candidates in interview that I didn’t know were invariably classified as pointless detail that distracted from the core tenants of a good programmer.

It is important that candidates remain current with trends in the industry, but I’m not aware of any current trend to have emerged in my corner of the industry that wasn’t an established element of development cannon in the broader industry at least a decade prior. In every case I can think of, when I have learned a new concept I have been coming to the party at least a decade later than a whole bunch of other developers in another corner somewhere.

Over time I have learned to be careful not to expect the candidate to coincidentally be learning the same things as me, in the same order, at the same time. It is an unreasonable expectation and is the execution of a bias that can filter out potentially suitable candidates.

This bias produces a broader impact on the industry in that it can artificially reinforce trends. In commercial development communities a concern with best practice can quickly become an unreasoning group-think.

Imagine a case where I have been spending the last six months reading material on CQRS. Over that period I share the ideas with my team, and they start reading material. Excited and enthusiastic material. We convince senior management this is the way forward, and for our next application CQRS will be one of it’s core pillars.

We happen to be recruiting into a position on the team and we’re presented with two promising candidates, both of whom have sufficient skill and experience to fulfill day-to-day duties and expectations.

Candidate A has read the same material, is as enthusiastic as us, thinks the idea of being able to roll back events and replay them is killer, and would love nothing else but for their next project to involve CQRS.

Candidate B has heard of CQRS but isn’t overly familiar with it. They seem to understand the core concepts as it’s explained to them, and are intrigued, but express the concern that it seems a little overly complicated for the baked goods ordering system we’re building next. The thing they’re excited about the past year seems to be the use of the actor model in Scala which they’ve been playing with.

Everything else being equal, which candidate is more useful to me and my team?

Unfortunately there isn’t a right or wrong answer to that. There are pros and cons which is to say risks to both candidates in terms of how they integrate with the team. Candidate A will likely integrate with the team more smoothly, but is likely to simply amplify what is already in the team. If we have full certitude we’re right, we’re likely to prefer this option. Candidate B however, if they possess a sufficiently flexible personality has the potential to add a perspective to the team that it doesn’t currently possess.

My personal value judgment is to seek out Candidate Bs with sufficiently flexible personalities. It is more important to me that a candidate is capable of appropriately challenging assumptions that are presented to them, than it is for them to echo back to me my own views, reassuring me that my choices are correct. If Candidate B has a perspective or experience in areas that are absent in the team, then they start to become really interesting.

It is also more important to consider what the candidate has been doing, rather than if they have been reading and agreeing with the same material as me. It’s remarkable the number of developers who have a strong opinion on things they’re not actually doing.

Give me somebody playing with actors in Scala over somebody talking about CQRS, even if the later is what I’m excited about (I’m not as it happens it really is just an example).

It’s time consuming

Tough. It’s my job, and if I don’t get it right it can cost my company dearly in a myriad of ways. We will live with our choice of candidate for years, there are few other jobs that a team lead or technical manager perform that are more important.

One might argue that a recruitment process such as this will not scale, to which I would suggest if each team has a team lead that takes point on recruitment for that team, whether you have 2 teams or 12 will make no difference as the activity is in parallel.

If what one means to say is that an organisation in the pursuit of more efficient allocation of resource has teams leads acting merely as line manager for 3 teams each, and they simply don’t have the time to do their job properly, then that is a problem of the organisations own making and has more to do with them overworking their team leads that it does the scaling of process.

If I am distracted with a recruitment process my senior devs pick up the slack, it’s good practice for them, and indeed what they are there for. If I have a senior dev interested in gaining more experience they can pick up some of the screening. Recruitment is a good time to carefully stretch your senior devs skills, and I see it as an opportunity for their personal development.

Want to know if a candidate will fit in with the team?

Take them for lunch with the team. If it’s a really important hire, take them all for dinner. My team gets a jolly, feel involved participants (because they actually are) and nothing will give me more information about how a candidate may fit in with my team than putting them all in the same place in a relaxed setting, shutting my mouth for a while, and watching how they all get on.

We can test for a thing, which is to say observe its simulation within an artificial context, or we can actually just observe the thing in a natural context.

The candidate that seems brilliant but gives me concern that they may be too shy and reserved, I may find at lunch outside an interview room is relaxed, outgoing, confident and expansive… People can act in very unnatural ways in interviews that do not correlate with their behaviour in other aspects of their life. Again, I need to be mindful of what the interview is actually testing.

The pitch and pay negotiations start upon first contact

My experience tells me that the majority of developers will balance two simple criteria in choosing their next position. The first being how much does it pay, and the second how much they feel they will enjoy the position. How those two factors are balanced will depend on the developer. Many developers will take less pay for a job they feel they will enjoy and grow in.

The candidates first impressions of me, my company, my team and our projects are every bit as important as my first impressions of them. The more weight I put on this side of the scales, the less money will need to be placed on the other side of the scales.

This isn’t to suggest a recipe for underpaying developers. Coming very closely after the priority of acquiring the best developers I can get my hands on, retaining them is my second highest priority, and salary most definitely plays a role in this. The issue is that if the candidate is any good and has any significant experience, one has to assume they are entertaining other offers. There is always going to be somebody paying more than me, and I have a duty to my company to get the most I can from budget.

Again experience tells me that most candidates will not reveal other offers they are considering. While some candidates will come back to negotiate a better pay offer, a large proportion will not, and with those you have effectively engaged in a sealed-bid. You’ll be notified of their decision. In these cases having treated the candidate like a human being from first point of contact up until they make what is a life impacting choice for them and potentially their whole family, can be a compelling factor.

With good candidates, you aren’t just interviewing them, they are also interviewing you. You want smart people, well expect them to be smart.

My job is two-fold, to ensure my company prospers from the activity of its developers, and to ensure my developers prosper within the company. This is a mutually beneficial relationship if it is to work well over time. If by the end of the recruitment process the hopefully smart candidate is to accept this as genuine and authentic it needs to start at first point of contact, and remain consistent.

I treat my team members as humans, which is to say individuals with their own motivations, hopes, fears, insecurities, and aspirations. I treat my candidates the same way. Just because I don’t know them very well, does not make them less human.

This isn’t a case of it’s nice to be nice, making good choices and encouraging the best from people rather than the worst has a direct and marked impact on productivity and staff churn which can be very costly and sometimes outright crippling to a businesses ability to achieve and maintain momentum.

Treating candidates as humans is smart and the effort involved pays dividends whether your contact with them is for minutes or years.

Why I like XSLT.

I first fell in love with XSL in 1999, when Microsoft rolled an XSLT processor into MSXML. I got my hands on the works of Shakespeare marked up in XML and started playing. I found it so shockingly easy to transform a whole play into HTML with XSLT handling the heavy lifting of flow control. It was love at first sight.

I still use XSL today for my own projects, and for a good handful of years there while WebForms were still squeezing the joy out of life, and before the MVC.NET Borg collective had arrived to assimilate everybody, for five glorious years myself and my development team at the time used XSL extensively. Then it all went away.

Since then Razor has come to dominate, almost to the exclusion of anything else on the .NET platform, with similar templating pervasive across most platforms. I’ve come to terms with the current of the stream being simply too strong to swim against. My closest of colleagues whom I’ve persuaded over the years to entertain a wide variety of bizarre ideas and technologies have remained a stonewall of refusal. So this is why I like XSL.

This may ramble a little as the reasons why I use XSL are a cohesive whole, making it difficult to tease apart the considerations as individual pieces. Indulge me while I give it a shot.


Arguably the big shout for XSLT is the breadth of its support. If you’re writing software commercially, there’s undoubtedly an XSLT processor available on your platform. Just to have a quick eyeball at the outliers, there’s XSLT processors for Erlang, and here’s a tutorial on using XSLT with Delphi. The current popular platforms have had very good XSLT for quite some time, and .NET has a very nice optomised XSLT processor.

It’s not just on the server with XSLT support in browsers. The failure cases there are in areas unlikely to impact development.

I’m not aware of another templating language that has the range of support that XSLT does. You would need to consider Javascript as a templating language to get support as pervasive.

What could have been

If as an industry we had persisted with the adoption of XSL by now our front-end developers would be armed with HTML, CSS, Javascript, and XML/XSLT. They would be used to being handed an XML output on one side, and a design mock on the other for which they wrote the XSL stylesheet to get from one side to the other. Whether their work history had taken them through PHP, Ruby, Python, Java or .NET development teams would make little difference to them. They’d use the same templating solution wherever they went and would need to know little intimately about the platform on which the application was built.

Recruitment, developer quality, and management of front-end developers would be in a significantly different place than it is today, with front-end developers able to focus on what their job is, accruing common competence regardless of platform along the way.

“X years commercial experience with HTML, CSS, Javascript, XML/XSL, Creative Suite”, could be enough to plug in a front-end dev into any web development team… Having to then specify “With experience in C#/.NET, MVC.NET, Razor. Entity Framework a bonus” not only partitions you prospective pool of developers or jobs depending on which end of that you find yourself, it also shines a spotlight on the dependencies your view layer is carrying with it.

Separation of concerns

For me personally this is the big issue, and it’s not an issue that XSLT alone addresses. The piece The Importance of Model-View Separation is an interview with the author of StringTemplate and ANTLR which uses StringTemplate on its back-end. It’s a really good discussion with somebody taking a good hard look at just what it means to have a view layer that only deals with it’s own concern.

With a templating solution like Razor it is easy to both implement business logic, and to reach back into the application in ways a view simply is not meant to. This leads to MVC.NET applications that have views that are highly enmeshed with the broader application.

In an application using XML/XSL the result of a request operation is an XML view. A serialisation of end-state if you like. The XSL stylesheet can do little except transform this. There is no reaching back up-stream, and implementing business logic in XSL while doable is painful.

There is a clean fire-break between the handing off of the XML and rendering it as an XSL transform into HTML/CSS/Javascript, PDF or whatever. This line between two layers of the application are as clean as I have witnessed in any architecture, and makes breaking it an exercise in swimming against the tide.

The VmEntityName plague

A lot of MVC.NET applications use Entity Framework or a similar ORM, often with lazy-loading of members. By the time these “live” entities make it down to view layer their context has been disposed, and so their data-members can’t be populated. Even when lazy loading isn’t being used, we don’t feel good about passing these entities down to our view.

So we start creating a whole bunch of view-model objects for different scenarios, and the surface area of our application model balloons. Hydrating these view-model objects is a pain in the arse, so we employ and auto-mapper. We now have a wonderful little tar-ball of complexity that’s simply going to increase over time, stretching testing to the point where you’ve simply stopped doing it in any real sense.

An XML view-model

XML is really good at extensible representation of data-models. It was purpose made for it off the back of a lot of experience from SGML. I like that I can start with a simple unconstrained view-model that can be refined and tightened over time. I can layer different models with namespaces, and I can apply schema to the model if needed.

For large complex applications where the view pipeline is a significant portion of the application, in multi-tenant or white-labeling scenarios I can outright come up with a domain-specific language for the view-layer.


XSLT is intended to transform one XML document into another XML document. Any text notation can be output from XML, but it’s designed for XML-to-XML. This transformation is accomplished by matching on a point of context in a document, and then specifying output and recursion on the basis of this match. XSL is a functional language that makes it difficult to use in an imperative fashion. There is for-each and call-template but their use is strongly discouraged.

Transformations naturally lead to pipelines. The output of one stylesheet can be the input of another. So for example, the data-model is serialised to XML, the back-end devs then transform this to an intermediate presentational layer. Fornt-end devs are then responsible for rendering this presentational layer into HTML. If you need to actually layer your view layer XML/XSL will naturally extend in this direction. Razor wont.

Focus on API

The focus on XML as the result of a controller naturally focuses development on the application API, as you’re effectively creating an API for your own internal use. This XML API is what your XSL stylesheets use. Making this accessible externally becomes a naturally progression rather than a different activity.

Serialisation by threading a writer through an object graph is fast and provides a single pattern for serialising to XML, JSON, or whatever.


The clean fire-break between the view template and the rest of the application coupled on an XML representation that the XSL dev can’t reach back beyond means your view-temaplte is neatly sandboxed. A lot of effort has been made to ensure you can’t yield side-effects from the XSLT template except to produce output. There are far fewer sins can be committed in an XSL template than a Razor template. Doing the wrong thing is painful.

Null references in the view

If your view templating solution has issues with null references, it’s not a view templating solution. Defensive coding in a view template is decidedly more torturous than XSLT.

Ease of testing

The combination of portability, wide availability, clean separation of concerns, and not least schema, means that testing not only XSL stylesheets themselves but the XML product of controllers is about as easy as it gets. Mocking XML data-model representations is trivial.

Handing your front-end dev an XML mock and saying “this is what we’ll be producing” allows them to be working on the view presentation at the same time that you are working on the implementation.

And the down-side

There are many books and articles extolling the virtues of XSLT, but we can’t get passed a quite deeply ingrained loathing of XSLT and indeed XML in general in whole segments of the web development community. I have personally always found this a little odd in a bunch of people that have such a focus on HTML markup, but it is there and cannot be ignored.

Bill Venners When you hire a bunch of programmers it can be quite difficult to get them all to go in the same direction. One of the ways I think about architecture is that you can try to define it such that it is easy for people to go the way you want them to go, and painful, though likely possible, to go other ways. People will usually follow the easy route.

XSLT deliberately makes some thing difficult. This can be misidentified as a problem with XSLT rather than a problem with what it is you’re trying to do in a view-template. That being said, some issues are not about trying to do the wrong thing but are about some sharp edges XSLT presents in a current web development environment.

It’s XML

I can’t help but feel that if this…

<xsl:template match="item[@name='navigation-view']" mode="navigation">
<xsl:apply-templates select="records/item" mode="navigation" />

Had looked like this…


The history of XSL may well have been different. DSSSL a stylesheet language for SGML that XSL is derived from is a subset of Scheme. We can see here the origins of CSS also.

(element doc
(make paragraph
font-size: 20pt
line-spacing: 20pt
font-weight: 'bold
color: color-purple

If XSL had a different notation, we’d be all over it.

XSLT is verbose, and without good editor support it’s a right pain in the arse. I work largely on the .NET platform spending much of my life in Visual Studio. I have intellisense for XSLT, a good understanding of XML by the IDE, and even debugging of XSL stylesheets. Anybody working in a similar situation has little excuse to cite “pain in the arse to work with” as the IDE is handling the pain for you.

If you want however, you can be working on your templates with Notepad and a web-browser.

The fact remains XSL syntax is less friendly for the developer than most templating languages. Architecturally however, it’s hard to conceive of a friendlier templating solution. The “X” stands for extensible.

It’s harder to think about for imperative programmers

XSL is a strict functional language. It relies on pattern matching and recursion. These are things that can legitimately hurt our heads a bit coming from traditional imperative, OO backgrounds. I would suggest this pain passes with familiarity until it is gone. The gains from XSL continue to accrue over time.

Staffing can be tricky with XSL

Because of the unpopularity of XSL acquiring devs with experience can be tricky. Even those devs who have used XSL often don’t maintain or develop skills with it and was often a cleaning out the latrines type task when they came into contact with it.

Projects that are constrained with developer experience, where there is significant developer churn, or where the project is short lived… truthfully it’s not worth the hastle, life’s too short.

For long-lived projects, or where there is investment in staff and work-flow developing skills with XSL and architecting an adult view layer I would say warrants proper consideration. Razor looks like a quick-fix but as it muddies the boundaries around the view layer, it also muddies the skill requirements of your front-end devs and can make for a very uncomfortable working relationship between front-end and back-end devs. This often leads to developers spending quite a bit of time working on a side of the fence they aren’t particularly comfortable on. Either your front-end devs are working with C# and a view-model exposed as an object model, or your back-end devs are producing HTML and CSS.

The fact remains that today, staffing and training can be an issue with XSL.

An acquired taste

A diet of nothing but fast-food is bad for us. Picking nothing but fast-food technologies for our application stacks is bad for them. Razor is compelling because like fast-food it requires little if any effort on our parts. There are times when its expedience should win out as the right choice, there are many times however when it is rotting the insides of our applications, clogging its arteries and shortening their lifespan.

Many of the foods that are good for us we spat out as children because they had a strong taste. Often as adults these same foods go on to become our favourites, sometimes even becoming described as “moorish”. Sometimes the same is true of technology, and even when it’s not good food is still required for health regardless of our tastes.

If it were just a personal matter, no more than that need be said about it. Many of us however are paid well to make good technical choices for companies we work for. We should be careful that we are not making choices on their behalf based solely on our own personal tastes.