Looking For a WordPress Theme Developer

In case you hadn't noticed, the OpenGamma web site doesn't really have a lot of content on it. We intend to change that.

We've got content broadly ready to go.

We've got a designer working on HTML templates for the content.

We're looking for a freelance designer to convert everything to a WordPress theme for a (mostly static) site that will definitely include a blog.

Nope, you don't need to be in London. You could be virtually anywhere in the world. Send an email to jobs or info or even kirk, all at opengamma.com.

OpenGamma is Looking for a Browser-Based Software Engineer

We've already put this up on our jobs page, but I wanted to highlight the job posting to my readers.

OpenGamma is now looking for someone to build up our browser-based software engineering efforts. We've got a super-strong set of server-side software engineers who are well versed in building the back-ends of applications (and delivering data to front-ends in browser-friendly ways). We've got people who are very familiar with extending well-defined applications to support new functionality. What we don't have is someone who lives and breathes the browser.

That's where you'd come in.

We want someone who can come in, and make sure that we present the platform that we're building in the best way possible to end users, delivered through browser-based mechanisms. You'd get a clean slate to work with, and the chance to work against what we know will be the limits of what browsers can do. And at no point ever will we ask you to support IE 6.

While we're building financial technology, we don't think you need to know a single thing about the financial services industry to take on this role; in fact, we think our ideal candidate isn't coming from finance at all (judging by the quality of web applications we've all seen in finance). Anything you need to know you'll pick up on pretty darn quickly.

We'd prefer someone local to London (our new offices are in the Bankside area, with views of the Tate Modern). If you're based outside the M25 and need accommodation for telecommuting, we don't need you in the office every single day.

We're a well-funded startup, we're building technology that has the potential to disrupt an entire industry, we have exceptional people to work with, we have a no-bullshit stance on bureaucracy, and we all have an equity stake in the firm.

Take a look at the more comprehensive spec on our web site, and if you think you or someone you know would be perfect, contact us (jobs at opengamma dot com).

Recruitment Agencies: We are not open to unsolicited profiles or CVs for this role without an existing MSA signed by OpenGamma.

OpenGamma Set To Welcome Stephen Colebourne To The Team

As you can read from Stephen's blog post on the subject, he's coming to join the OpenGamma team in the beginning of March.

On JSR-310

Just to reiterate what he said in his post, one of his first duties at OpenGamma will be to get JSR-310 to at least reference draft status. When we started building our platform we made a very early bet that JSR-310 would be the ultimate future of dates and times in Java. That decision has brought a lot of power on working with dates and times for us (for example, we haven't had to build our own system on top of java.util.Date that every financial firm I've ever worked for has done), but we think that with a strong, concerted effort we (as a community) still have a chance to get JSR-310 as the defacto and dejure future of dates and times in Java.

Stephen mentioned earlier on the mailing list that a lack of time outside work has contributed to the slow-down of JSR-310. We're giving him time and resources during the working day, and waiving ownership of the code that he produces.

We're not hiring him just to work on JSR-310, but it seems obvious to me: financial software probably depends more than other software on having strong tools for working with the multiplicity of date and time rules that proliferate in finance. If giving Stephen the time he needs to finish off JSR-310 gives us those tools in a standardized way that the whole community can benefit from, that's far better than building Yet Another Proprietary Date/Time System.

On Non-Financial Hiring

When I mentioned in passing to a few people that Stephen was joining the team, they were quite surprised, because they thought from my original blog post on OpenGamma hiring that we were only looking for financial industry professionals. That was true at the time I posted it, but it's not true today.

If you take a look at the current OpenGamma Jobs page, you'll see that we put far more prominence on pure programming skill these days than financial industry expertise. Sure, if we have a choice between two candidates, identical in every way and one comes from the financial industry and one doesn't, we'll choose the one from the financial industry. But people are unique. We never see two candidates that are identical in every other respect.

And that's why we're eager to hire people who don't come from finance. We're building software that's complicated enough that we need the best across the entire software development industry. Unlike a common attitude I encountered by recruiters when I first moved to the UK, we're not under some assumption that the only people who are any good are the ones working at a Tier-1 bank or a hedge fund.

We made an offer to Stephen because he's a fantastic software developer and architect that we think will make an immediate and long-term impact on our success. We're thrilled that he's decided to join us.

We're Still Hiring

So if you were on the fence before, or you thought that we only wanted someone with N years of experience at some bank somewhere, think again. We want the best, no matter what their background. Email us your CV.

More Adventures In Unethical Recruiting

Let's run through an entirely hypothetical situation for a second.

You're a recruiter. You find out that there might be a newly funded financial technology startup that's hiring, perhaps by looking at Blog Posts or LinkedIn Profiles. You think "hey, that's a great opportunity to get some business."

You then proceed to start calling engineers and telling them that there's a recently funded financial technology startup in stealth mode that's hiring, and they'd be brilliant to work for, and get some strong expressions of interest, including CVs.

You then contact the CEO of said company through LinkedIn and say "Hey, I see you're hiring, and I've got some candidates that are already interested!" The CEO might in theory point out to you that you in fact do not have a Master Services Agreement or any other contractual relationship with said startup, and that he's not interested in any candidates that have come through that might trigger a financial payout with a firm with which the startup lacks a pre-existing business relationship.

Now you're in a bind. The CEO flat-out says that he's not willing to sign any type of contract with you, but you've already told the candidates that you can get them introduced to the firm. You've been caught out in your lie.

I suppose what you could do is come clean with the candidates and just tell them the name of the firm and its CEO so that they can get in touch directly. In fact, the CEO might have even suggested this as a way forward for you. But I doubt you're going to do this. If you were interested in acting ethically, you might have contacted the CEO before lying to candidates.

I think more likely what you're going to do is tell the candidates that the CEO isn't interested in them in particular. And for that, and the situation that led to this mess, you earn a merit badge in Unethical Recruiting to add to your stack. You've also earned the wrath of said CEO, who will proceed to make sure that the reputations of both yourself and your firm are effectively ruined with everybody said CEO knows.

Hypothetically, of course.

OpenGamma Is Hiring

People who have been following the blog for a while, or my twitter feed, will know that I've co-founded a startup called OpenGamma, that we've received a significant equity investment, that we're working in the financial services technology space, and that we're so stealth we don't even have a web site. And now I'll add another nugget of information into the mix: we're hiring.

Immediately, we have head count for one person, and I'm describing what I'd like for that one hire below. However, we're always open to finding someone good, so no matter when you find this post, if you think you might be a good fit for the company, send your CV over; if we can't hire you right away we'll let you know right away, but our headcount requirements are changing constantly. We might not be able to hire you right now, but if we think we might have room later on, we'll let you know.

About OpenGamma

Let's completely ignore whether you're a good candidate for the role that we're looking to fill. The #1 question you should be asking yourself, without even knowing what we do, is do I want to work with these guys? Hopefully this section can fill you in about who we are.

OpenGamma was founded by three people: your humble author, Elaine McLeod, and Jim Moores. Of the three, I'm the only without a PhD, and Elaine and Jim remind me of this on a regular basis. I'm the CTO and Acting CEO [1]; Elaine is our resident quant; Jim works on our core engine. We've known each other for years now, and bring a combined 30 years of technology experience (13 in finance) to the table.

The team has already grown beyond the three of us, and by the time you read this we'll have one more person working on-site and one more who's agreed to join. So you'd be coming on board when we're still quite small, but that's one of the major attractions for a lot of people. We believe that since you'll likely be spending more waking hours with us than your family or friends, it should be an enjoyable, social atmosphere (one of the earliest decisions we had to make was which local pub to adopt [2]).

We're well capitalized, having just closed a Series A equity investment by a major international Venture Capital group [3]. We have an office in the London Bridge area [4], from whence we can easily make lunchtime trips to Borough Market [5]. We have fast computers and big monitors and good (unfiltered) network connections and tons of Diet Coke and all the types of things that mean nobody's banging his or her head against "if only I had X, I could code better/faster."

What we don't have is meaningless policy, bureaucracy, procedures, politics, or other stupidity. We don't have a dress code. We don't have any paperwork other than expense claim forms and what we're required by law to fill out. We believe that the only policies we need are "do the right thing." We believe the only procedures that are worth having are the ones that help you, and us, execute better. We believe in hiring the best, enabling them to perform, and trusting them.

About You

I probably don't know you. But I can guess a lot about who you are, if you're going to be a good fit for the team at such a critical early stage in OpenGamma's life.

First of all, you know something about Front Office or Risk technology in capital markets. Ideally, you've worked for a broker-dealer or investment bank in your past, and might even be working there now. While this isn't critical for every hire we make, it is for this one. You get a thrill out of working under the constraints that modern trading software requires, and you like producing software not just for its own sake, but to solve business problems.

However, you're not 100% happy working for a Big Bank. You've beat your head against policies, procedures, internal audit, external audit, anything that stops you from doing your job effectively, one too many times. You're sure that it doesn't have to be that way. Maybe you started out trying to change things, thinking that one person could make a difference to the organization, and gave up. Maybe you just thought "that's how it's got to be" until you discovered the wide world of technology outside your bank. But you know that you don't want to work there anymore.

You like technology; it's not just a 9-5 job with you. You read tech blogs [6], user-contributed sites like Proggit, Hacker News, and DZone. You post answers on Stack Overflow. You research new technologies even though you know your employer would never let you use them, because you find them interesting. You go to events like CloudCamp, Pub-Sub, and BarCamp. You probably code in your spare time.

You live within a reasonable commute of Central London. While at some point in our future we'll be happy for full remote working, we're not there now. You might need reasonable accommodation for your personal or family situation (and we're not just legally obligated, but happy to do so), but you have to be able to make it to the office on a regular basis.

Most importantly, you've gotten this far and thought to yourself "Wow; this sounds great! Kirk, tell me more!"

About The Role

So about this role. I can't tell you that much about it without bypassing the Great Shield Of The Stealth Startup, but here's your buzzword bingo section:

• You need to know Java. It doesn't have to be your preferred language, but you need to know it.
  • +1 if you came to Java from a C/C++ background.
  • +1 if you got sick of Java-the-language and started working with other JVM-based languages.
  • +1 if you've worked with low-level APIs like the post-1.5 concurrency libraries and the IO and NIO systems.
  • -5 if it's confined solely to web applications.
  • -10 if you've only ever used a traditional full J2EE stack.
• You need to be conversant with modern software engineering, architecture, and methodologies.
  • +1 for every agile technique you like to use
  • +1 if you understand the difference between agile and Agile, and prefer the former
  • +1 for IoC and use of Dependency Injection containers like Spring
  • +1 for rigorous use of automated test suites
  • +1 for dedication to continuous integration
  • +1 for every functional language you can still code in (Scheme from your SICP days doesn't count here)
• You need to be familiar with a standard Front Office/Risk Technology stack. By this I mean message oriented middleware, enterprise-class databases, distributed systems.
  • +1 for every Trading System you've worked with
  • +1 for every source of market data you've worked with (Reuters, Bloomberg, Exchange Feeds, etc.)
  • +1 if you've setup your own MOM infrastructure
  • -2 if you used XMPP rather than a real MOM infrastructure.
  • +5 if you've worked with AMQP
• You need to have some familiarity with analytic libraries for financial models. We don't need you to be a quant, but you should have worked with pricing models in the past.
  • +1 for every chapter in Hull you've managed to get through (and +2 for every problem you managed to do successfully without resorting to the solution book)
  • +1 for every pricing model you've seized from the quants to improve performance or stability
  • +10 if you understand why Correlation is a rubbish analytic for pricing credit derivatives (even if you can't work through the math)
• You might be familiar, even if you haven't used them in anger, with some advanced technologies not every bank has rolled out yet:
  • Clustering and Data Grid technologies like Terracotta or Coherence
  • Hardware accelerated computation like GPGPUs and FPGA-based acceleration cards
  • Shared-memory or shared-flash clustering systems like Violin
  • Key-Value stores like Project Voldemort and CouchDB

Risk/Reward

Here's what OpenGamma can offer you:

• The chance to work for an organization designed to allow you to produce great technology.
• No bureaucracy.
• An equity stake in the business.
• The chance to learn about working for an early-stage startup first-hand.
• A tech team filled with the smartest, best people we can get. In fact, if we can't find the right person, the role stays unfilled.

However, there are some things OpenGamma can't offer you:

• Job Security. We're well capitalized, but we're still a startup. If you want/need a guaranteed job for several years, we're not for you.
• The Chance To Hide. What you work on is going to be seen by everybody else in the firm on a daily basis. Moreover, you're going to interact with customers. You're going to interact with the public at large. No room for shrinking violets, and no room to coast on your teammates, I'm afraid.
• Hedge Fund Cash Compensation. I believe in fair compensation for excellent staff; London is an expensive city, and if you're good enough to work for OpenGamma, your fixed expenses have largely grown commensurate with your banking salary income. We can offer good compensation, but we can't and won't match what you'll earn in a good year for an Investment Bank or a Hedge Fund: your equity stake is to make you whole over your employment at OpenGamma, and to make sure that everybody has aligned interests.

How To Apply

If you still think we might be a good match, send an email to jobs at opengamma dot com with your CV, and a description of why you think you're a good fit for OpenGamma, and we're a good fit for you.

Note: Recruiters/Agencies Not Welcome To Apply. We're not working with recruiters as of yet, so please don't contact us with a story about a candidate whose "profile" you're "exclusively representing." Any agency-provided CVs will be deleted unopened and unread.

Update 2009-10-28: We are now working with external recruiters, so if you're a candidate who just read that after a recruiter contacted you, ask to see the job specification. If they have it, they're definitely working for us.

Footnotes

[1]: I'm CEO during this, the most formative period of OpenGamma's lifetime; I'm not wedded to the role, and it will become quite clear to myself and our board of directors when it's time to bring in a permanent CEO. Until then, I'm it.
[2]: The Trinity. Best one around, even though it's farther from London Bridge station than the office.
[3]: Yes, I'm coy about who it is. No, I'm not going to tell you unless you get to the phone discussion stage. Yes, we have valid reasons for that.
[4]: If Old Street is Silicon Roundabout, can we be Silicon Bridge or something?
[5]: Shame that it's 1/3 shut down these days...
[6]: Like this fine screed. That guy's really good, if a little opinionated for my liking. He should calm down a little and go back to writing about tech stuff rather than politics and personal attacks on industry figures.

Big Banks: Embrace Entrepreneurial Techies

After I had been made redundant by Investment Bank A, and before starting at Big Bank B, I interviewed with a Large Teutonic Bank's capital markets division, for a permanent role in London. This was to be a tech lead and architect on a massive greenfield project, where a key part of the role was to bring in "fresh blood" who had worked with some new technologies that the development manager was considering. It required spending quite a bit of time investigating technologies for potential inclusion, doing trial and error, and general research time as the project developed due to the issues of scale involved. Because it involved a lot of real-time updates, massive database work, and distributed systems development, the hiring manager though I'd be an excellent candidate. So did all the other senior architects in the group.

I was turned down for the job by the boss' boss. The reason? "He's too entrepreneurial."

I was recently chatting with another London Techie who was interviewing for a permanent role with a Large Yanqui Bank, and he had a similar experience. The hiring manager liked him and his experience, he got through the gauntlet of developers on the ground who would work with him on a daily basis, and he had to go through the "formality" of the HR interview before they could extend him an offer.

He was turned down for the job by HR. The reason? "He's too independent."

Once is coincidence, twice is a trend.

Entrepreneurial Is An Insult?

So let's consider the two of us. We're both active in the technology community outside of work hours: we blog, we go to meetups, we speak at conferences, we work on open source technologies. We've both established that we're able to apply ourselves at a strong level technically, and are able to pick up new technologies on a regular basis, both in and out of work.

You might think that these would be useful traits. You might think that these are in no small part why the hiring managers wanted to hire us in the first place. You'd be right: they realized that they needed outside skills, and some of them cutting-edge skills that are difficult to get inside the sclerotic community of financial services technology, and that they needed to pull in people who Think For Themselves. But The Organization stopped them.

Apparently both Senior Manager and HR Drone viewed us as unacceptable risks (in fact, it was spelled out precisely why I was a risk: in 5 years, I might not want to be in the same role on the same project). We would think for ourselves, we would seek out new challenges, we would rock the boat.

The fact that these tendencies lead inexorably to us having the skills necessary to perform the jobs has never apparently crossed their minds. They somehow think they can find non-independent, non-entrepreneurial technologists who are familiar with cutting-edge technologies and are able to do proper trial-and-error with design, architecture, and vendor selection. Really? How's that working out for you?

If you're worried that these candidates might eventually want to, gasp, leave the firm, on their own terms (e.g. before you make them redundant), isn't that the price you pay for having a pool of talent you can draw from to get "fresh blood"? If everybody in the world works for the first firm that hires them for the rest of their lives, how would you be able to hire people?

If you're worried, ultimately, that these candidates might lead to uncomfortable situations as they challenge the status quo, are you not implicitly recognizing that your status quo is broken? And that, more importantly, that you want it to stay broken?

Embrace The Uncomfortable

I have a friend who has the theory that the wages techies earn working for Big Banks is compensation for the work and culture they have to endure. I'm not sure I disagree. But you can still find a way in a stultified culture working with boring projects to embrace technically skilled, entrepreneurial techies.

Entrepreneurial techies like facing new challenges, and continually want to apply their skills to making things better. Surely a Large Teutonic/Yanqui Bank has a lot of challenges? And surely hiring someone because they have the skills to design and build a greenfield project implies that they have skills that probably wouldn't be applicable 5 years down the road as the project is in maintenance mode? Why not allow the employee to continually find challenges internally?

Because speaking for myself, I find working on new challenges inside an organization superior to having to find them outside the organization. Your institutional knowledge, built up over extended work periods, is valuable to both sides; your reputation makes it easier to Get Things Done; your domain skills are continually built up. This makes it easier to apply your skills inside the same organization than constantly switching organizations. Why not encourage that by allowing the techie, every couple of years, to switch to a new challenge where their skills and attitude will make a bigger difference?

Independent-thinking techies of all stripes can also be used to help fix the broken parts of that same culture. With enlightened management, someone pointing out that "although this is the way you've always done it, it doesn't have to be like this" can be exactly the type of kick that an organization needs to actually realize that it's fallen into a process/culture-trap, where the wrong bits of the organization are self-perpetuating rather than the good bits. Questioning what's going on, thinking independently, that's the only way that you can ever break out of the bounds of group-think.

Independent, entrepreneurial techies can actually make the biggest impact in the organizations that fight against them the most: they're the ones that need them the most. Use them as agents for change, challenging assumptions, challenging entrenched attitudes, challenging technical group-think. Otherwise, your worst employees (the ones who can't really get a better job elsewhere) win, and you as an organization fail.

Epilogue: Teutonic Bank Is Still Hiring

When the recruiter told me why they had gone dark and ultimately rejected me, I knew that they would never find a candidate that would satisfy both the hiring manager and his boss; they had completely mutually exclusive requirements for this hire. I told said recruiter "in 3 months when they realize they haven't been able to fill the role and come back asking if I'm available, whether I have a job or not, I'm not available."

It actually took 4 months for that call. I wasn't available.

Recruiter Tip #1: Don't Block Your Phone Number

(Part of a series I'm starting on how to be a better technical recruiter).

One of the things that's most annoying about dealing with technical recruiters is that they all (well, almost all) block their phone number when they call you. I'm not entirely sure the reason for this, except that maybe they think that if you know it's a recruiter you won't pick up. The problem is that at this point, the only people that ever call me who don't have Caller ID enabled are technical recruiters, so a Blocked number automatically triggers "this is a recruiter" in my mind.

If you want to stand out as a candidate-friendly recruiter, don't block your number. More importantly, have the caller ID you present be your direct line, not the main line for your company.

Here's why you want to enable caller ID:

• If I'm actively looking for a job, I may field 5-10 calls from recruiters a day. Some of them I want to talk to, some of them I don't have time for (if I'm rushing to an interview, I want to take a call from the recruiter that put me up for that interview in case it's a change of plans; otherwise, I don't have time for you). Help me figure out whether I want/need to take your call when you make it.
• When you call me, I can easily take your phone number and put it into my phone so that I can call you back easily. If I'm out and about, I don't have paper and pen handy, so just telling me your phone number is largely useless, since I can't take it down. I can call you back much more easily if you give me your number.
• Many recruiters don't leave messages. I want to know who are being annoying and calling me 5 times a day without leaving a message so that I can put them in my bad list. Vice versa, if I get 5 blocked calls and one of them is you and you're thoughtful enough to leave a voice mail, you get kudos.
• I have Visual VM on my iPhone. That doesn't help me replay your message when every single voice mail pending is from Blocked.
• If I can't pick up the phone because I'm in a meeting or something, it makes it very easy for me to see it's you and email you back saying "hey, was this urgent or did you just want to check up on me?" Remember, in finance we have to plan on privacy in advance.
• If I'm a hiring manager, I expect the vast majority of recruiters calling me are cold calling me trying to find out if they can recruit for me. I want to pick up the phone for the recruiters that I'm actively on a search with, while ignoring the ones I'm not. If you're working for me, I want to know that so that I can pick up the call while sending the others to voice mail. So if you have an agreement with my firm, you have no reason not to announce your presence before I pick up.
• Rather than a main line, I want to be able to call you back directly. Particularly if I'm dealing with different recruiters from the same firm, one of whom I want to talk to and the other I don't.

If your IT staff tell you that they can't unblock your number or can't set it up so that your outbound number is your direct line, they're lying.

You have nothing to lose here if you're behaving ethically. So stand up with other ethical businesses and announce your caller ID.

Purity vs. Pragmatism

I was being interviewed for a new job last week (yes, I am actively on the market), and had a very interesting, frustrating run-in with one of the interviewers (disclaimer: by mutual acclaim, the role and I decided we weren't right for each other; you'll figure out why shortly) at a large bank.

We Frustrate Each Other
The frustrating part of the interview came when I realized that The Interviewer (we'll abbreviate it to TI, not to be confused with the hip-hop artist T.I.) and I were disagreeing on virtually every point of philosophical substance. But that was just a manifestation of a broader disagreement that I think went to the core of why the two of us must never work together: we fundamentally disagree with the core principle of software engineering.

Let me explain with a few examples of where we differed to try to explain what was going on (no, this is nowhere near an exhaustive list):

• He believed that checked exceptions in Java are always wrong; I believe that sometimes they're useful and sometimes they're not.
• He believed that you should only accept or return interfaces (and never a concrete class) from a module; I believe that you pick and choose between interfaces and POJOs depending on the context.
• He believed that setter-based Dependency Injection is always wrong and that only constructor-based DI should be used; I believe that you pick the right one for the context.
• He believed that you can only ever use DI with a DI container like Spring or PicoContainer; I believe that it's an architectural principle that can applied with or without DI-specific tools.
• He believed that you cannot consider yourself a practitioner of agile methodology without rigidly adopting a Formal Agile Methodology (Scrum, XP, whatever); I believe that the whole point of agile methodologies is that you pick amongst the parts that help your team develop better software faster.

What's the major differentiation here? Purity.

Purity
TI's approach to every major difference between the two of us fell down on the side of rigid, unbending application of a principle in the interests of purity. My approach is far more fluid and contextual.

Purity in any endeavor (art, design, architecture, music, religion, software engineering) is attractive because it strips away all thought and all decisions, and in doing so, pushes a concept to its ultimate expression. I can understand the sentiment. When I moved into my flat, every single surface was either white (floors, walls, ceilings, some doors) or gray metal (stairs, shelves, other doors). It's a minimalist, pure aesthetic, and it removes all distraction and makes it very simple to make decisions: there's nothing subjective about additions.

Sometimes, purity is exactly what you want. It focuses you, and allows you to fully explore one concept to its extreme (how white can you get the walls and floors? can you get them the same white even though you have to use different paints for different surfaces? can you keep the floor white even though people walk on it and put furniture on it?). Even the exploration of pure silence has begat its own groundbreaking work.

Purity in Software Engineering
Taking a purist approach to a software engineering matter allows you to nail your banner on the church for all to see: I believe in X, therefore X is always correct; by applying X to every situation, I prove the superiority of X and validate my initial conclusion that X is superior. This comes up a lot, particularly in architectural discussions:

• Asynchronous Messaging is great! Let's use it for everything!
• An RDBMS is great! Let's use it for everything!
• REST is great! Let's use it for everything!
• Google Protocol Buffers is great! Let's use it for everything!
• Cubes are great! Let's use them for everything!
  
• Lisp is great! Let's use it for everything!
  

The converse also happens:

• XML is crap! Let's banish it from the world!
• RPC is crap! Let's banish it from the world!
• Solaris is crap! Let's banish it from the world!
• RDBMSes are all crap! Let's banish them from the world!
• TCL is crap! Let's banish it from the world!
  
• Lisp is crap! Let's banish it from the world!
  

Purist decisions are easy. They don't require thought. They don't require constant critical evaluation.

And that's why I view them as intellectual cowardice: by limiting your choices intentionally, by limiting the scope of tools at your disposal, by closing your mind off, you reduce the amount of thought you have to put in. But as engineers, as craftsmen, we live by our minds: we are paid to think, and the more we're paid, in general, the more thinking we're expected to do.

TI could replace himself with someone far less experienced by simply writing his own DSL that works on the JVM that doesn't allow you to do any of the things that he thinks are wrong, and forces you to do all the things that he thinks are right. It wouldn't be that hard. Then he can simply hand that off to someone and say "here you are; a language that obeys every one of my edicts perfectly; you are sure to do an excellent job now that I've handcuffed you to my beliefs."

[Aside: if TI's beliefs realy were so universal as to allow him to view me with revulsion for not sharing them, why isn't there already the TI programming language? Are you to tell me that there isn't a programming language which targets some target environment (JVM, CLR, raw x86 machine code) that forces the practices that he likes and forbids the practices that he doesn't? Really? Does that tell you something perhaps? Because it's not like we have an absence of programming languages these days. And it's not like it's that particularly hard to write a language and target one or more existing VM environments, so all the hard work is taken care of already.]

In Defence Of Pragmatism
I'm impure. I'm about as tainted as you can get. And you know what? I think that makes me more effective, rather than less. Because what I get out of a lack of purity is pragmatism. The two can't coexist particularly effectively: I think you fundamentally agree with one or the other.

Pragmatism allows me to look at a problem, carefully consider the advantages and disadvantages to each potential solution, and then determine the right approach to each particular situation.

Pragmatism allows me the flexibility to do things that I know in other circumstances would be wrong, but in that particular one would be right.

Pragmatism allows me to have a bag of tricks rather than one, and pull them out as I see fit.

Pragmatism allows me to gradually refine my beliefs by using both my favored and unfavored approaches in a variety of circumstances so that I have evidence and backup behind me when I express my opinion.

Pragmatism allows me to work with a variety of code written by a variety of people and engage with it constructively as it is, rather than seeking to rewrite it before I'd be willing to touch it.

Pragmatism allows me to decide where to focus development efforts based on what's most important that day: sometimes rushing a feature into production to make more money, sometimes spending time testing the bejebus out of a small change before I make it.

Pragmatism forces me to build software which is easy to maintain and consistent in its internal architecture and clean in its modularization and consummately tested, because that's the only way to maintain a complex system over time. Pragmatism also tells me that if I know the piece of development is only there to run a single time, focusing on all of that is wasted time better spent elsewhere.

Pragmatism allows me to assess the strengths and weaknesses of my team, and the constraints of my customers, before assessing the correct development practices that will result in that unique group of people producing the best software possible with the fewest resources in the shortest possible time. Pragmatism forces me to understand that no one methodology could possibly work for all engineers, all customers, and all projects.

Pragmatism allows me to focus on one and one thing only: getting the job done well. Do what it takes, but get it done, and make sure it works properly. And that's precisely what we're here to do as software engineers: engineer software. And engineering, unlike art, design, music, or any purely creative endeavor, requires getting something done that works. We're not in this business to craft a purist expression of an idea. We're here to build things that work.

The irony is that many purists get that way out of a misguided belief that they're being pragmatic: buy choosing a single technology or technique or methodology, they've chosen the One True Solution and don't have to consider the same decision with over and over. Furthermore, they've made sure that those people working for/with them (particularly the lesser skilled ones) don't do The Wrong Thing. But that means that they've closed their minds off to the chance that they've chosen incorrectly. Or, even more appropriately, that there is no one right decision.

That's why purity and pragmatism can't coexist: purity requires that you ignore the results in favor of an ideological ideal; pragmatism is all about pursuing results for their own sake.

And that's why I think TI and I couldn't work together: I'm a pragmatist and he's a purist. The two of us were bound to clash, and at least we discovered it quickly.

But in the end, I know my approach is right. I'm proud to be a pragmatist.

Except when it comes to TCL. Man, I wish I could banish it from the world.....

Programming Problems and Technical Interviews

I've been involved in quite a few technical interviews over the years, and one thing that invariably (and rightfully) comes up is the programming problem. I view this as an opportunity to see if someone can actually code, rather than just talking about it. The real issue here is that the interview room is not the same environment as a developer will be using: you don't have a keyboard in front of you, you don't have all your tool suite available, at best it's a first order approximation.

That being said, I think any technical interview which doesn't provide the interviewer with a chance to evaluate the candidate's actual coding skill is just wasted time; while we need to think, write, and discuss, software engineers are paid to provide working code. Your job as an interviewer is to determine whether the candidate can do that subject to your standards and requirements. Your job as a candidate is convince the interviewer of that fact.

So what are the basic ways in which I've seen this hurdle laid out?

Read Me The Code
This is the most obscure one, but it was part of my phone screen for a job at Google back in 2002 (disclosure: I was offered the job, and like an idiot, turned it down). Essentially, I was given a programming problem over the phone, given about 10 minutes while I was on the phone to write down a solution, and then had to read it out to the developer on the other end.

I didn't really get this as a concept, and I still don't. Is he mentally picturing the code as I write it? Writing it down himself to make sure that I'm getting the semicolons and braces correct? Why even bother? I'm not a fan of this one because I don't think it actually tells you anything about the candidate other than whether he can get his hand around describing syntactic elements of programming concisely over the phone.

I've chalked it up to an obscure Google-ism, or an interviewer experimenting with a new interviewing style (we've all done it).

Whiteboard/Pen-and-Paper
This is the most common form, and in it the candidate and the interviewer get together in a room and the candidate writes some code longhand, whether on paper or a whiteboard or anything else. I think that this is a relatively valuable exercise for simple programming problems, because if you can't write out something that works elegantly for a simple problem, then you probably don't have an excellent grasp of your underlying language.

But the key thing here is that you have to engage in a dialog with the candidate about their solution, particularly if you think that there are tools or techniques or language features that they didn't employ. I've done this several times when someone had a strange solution only to find out that they didn't remember the exact syntax for using a language/library feature, and so they wanted to make sure that they did something that they knew to be correct. Because you don't know what the interviewer is looking for (and how much they'll mark off for mixing a brace or semicolon), you are at a loss to know what precisely to optimize for.

Furthermore, you have to be clear about what you're after here. Some problems are more conceptually difficult, and ideally the interviewer should be looking for your thought processes, and whether you can come up with a coded solution to the problem (damn the curly braces). Other problems are far more simple conceptually, and the interviewer should be seeing if you can write up a simple routine that is production quality longhand. Where things go awry is when interviewers want you to simultaneously come up with a solution to a really complex problem, and have every single syntactical element and edge case perfect in the first go. Gotcha-problems fit into this area as well (As a candidate, I get it; you've solved this problem in the past; you're ever so clever, and I should be thrilled to work with someone so brilliant as you; did this really teach you whether I can work with you effectively?).

The main problem with both of these approaches, though, is that they're not realistic. You don't write code by hand anymore. You definitely don't read it over the phone. These exams test (to some extent) your raw programming ability and familiarity with the syntax and libraries of your programming languages, but they don't show how well you can actually engineer software. For that, you need one of the following methodologies.

In Advance Programming Problem
I employed this as a low-pass filter while interviewing candidates at a previous employer, and it worked out pretty well. Rather than doing a phone screen at all, we had a relatively simple programming problem (in our case, XML walking) that we wanted a compilable, runnable solution to. Shouldn't have taken anybody competent more than an hour to do, and we wanted to see the style and nature of their code. What tools did they use? What language features? How did they document? How did they break up the problem? How did they package up the result?

This served two purposes: firstly, it weeded out the chaff that didn't really want to meet with us at all (if you think you're doing us a favor by even talking to us, you're not going to want to program in advance); secondly, it showed us a real-world example of what you can do with your chosen tool suite. Because it was so small, there were no excuses for providing something that didn't compile, didn't run, didn't produce correct output, or was ugly (all of which we got). Real software engineering involves spending time on niceties that aren't about the basic code execution path. Did you care enough to provide us with something that shows that you can do those?

Pair Programming Problem
Another financial services firm used this with me, and was the first time I saw it. Essentially, I came over to the interviewers computer, was asked which IDE I wanted to use (this was for a Java job, so I had my choice of Eclipse or IDEA), and he opened it up empty (new workspace for you Eclipse people). He then gave me the programming problem, and watched and talked to me as I worked through the entire end-to-end process in front of him.

I really liked this at the time. It was far more realistic than pen-and-paper could have possibly been, and also showed him how optimized I had gotten my workflow with my tool suite. It also allowed us to explore far more serious software engineering concepts like unit testing (I wrote the tests as I went along) and test coverage (making sure that my tests covered all inputs and results). I think this is actually an extremely strong way to check how well a programmer can work in a real-world scenario, and is far better than pen-and-paper development for languages like C#, Python, and Java, which have far simpler project setup times (though I think you could do it for a simple C/C++ test as well). That's the key thing here: you're watching a developer work with a real-world tool suite.

Programming Death Race
This was the most extreme form of any of these that I've ever had to do, and was extremely intense. I was given a Java file which contained four empty method bodies with documentation about what they were supposed to do, and told which ones I had to fill in. I then had 60 minutes to do two programming problems, returning the resulting Java source file, which they had an automated system to compile and run through a test suite.

These were not simple, reverse-a-linked-list problems. Each of them could easily have taken far more than an hour to do. And they were conceptually difficult as well (I'm not going to disclose the precise problems because I don't want to ruin their methodology), meaning that you have to actually think. A lot. There's not a lot of time to properly think and code a really complex solution when you know you're under a deadline!

While I completed the test successfully and got past that stage of interviews, I couldn't help thinking that it was all a bit much. I ended up providing a solution to one of the problems that was fully functional, but didn't actually look as elegant as I would have liked, because of the serious time pressure. Perhaps part of their goal was to see how fast you can get your head around a complex mathematical problem, but I felt like what it was rewarding was how fast you can churn out a solution, regardless of the underlying efficiency or elegance.

The firm was quite open that they would far rather have a hundred false negatives than a single false positive, which is why they intentionally made it so difficult, but something to me still said that proving someone can function at that level of intensity isn't necessarily the same as that someone can function on a consistent marathon pace. Then again, in financial services, if you can't function that quickly when things are going wrong and you're losing money every minute, it's probably a bonus for the employer to know that.

My Recommendation
I think I like the In Advance Programming Problem as a general concept (low-pass filter, and weeding out people who aren't really interested in the job), but I'd probably mix it with some of the stuff from the Programming Death Race: fixed time limits and automated testing. I just wouldn't make it as conceptually tough. That's better spent in person working through someone's thought processes.

But for the in-person work, I would definitely choose the Pair Programming Problem over the Pencil-and-Paper one any day. It serves the same purpose, but it also ensures that you're seeing how someone actually works. We don't code on paper anymore, we shouldn't assume that tells us whether someone's a competent programmer anymore.

If you want to test someone's thought processes, run through a conceptual problem. That's an extremely useful thing. But if you're going to ask for code, make sure that you either specify that you're looking for pseudocode, or that you don't care about the details and just want to see the rough order code. Otherwise you're at risk of taking a very valuable test (can the candidate think about problems in a reasonable way) and turning it into a trivia test.

And if you're not doing a real-world programming test, you should. Too many candidates have gotten good at the depth-of-a-tree or nth-Fibonacci-number level of problem without having any real concept of proper software construction as a discipline. Does your interviewing methodology go beyond that and try to determine whether the candidate is someone you'd want to share code with? If not, figure out how you would. Pencil-and-paper coding doesn't.

Technical Recruiters Need To Wake Up

In case any of you missed it, the financial markets are kinda imploding these days. And there are a lot of companies failing. This means that there's a fair number of people looking for jobs, and not that many places on offer.

This has recruiters going positively apeshit as they try to find some way to earn some money fast so that they don't also lose their jobs. This is troublesome for them, as most recruiters aren't actually very smart at all. So many of them are cold-calling employees with no job that they're trying to pitch, trying to find out if they're looking for jobs. Which is pretty horrible. And big firms that are looking to target from people like Lehman are using their own internal channels and doing it in bulk at the moment, and they don't want to get CVs from you.

So if you're a financial technology recruiter, you're pretty hosed at the moment, and trying to do anything just to survive.

But if you're a recruiter who's actually smart enough to google me before picking up the phone, lemme give you a few little secrets about what it's like to actually work in technology in Financial Services in London, so that hopefully you won't come across quite as uninformed as you actually are.

First of all, we all work in great big open plan spaces. Techies usually have a little more room than traders (unless you're (un)fortunate enough to actually work on the trading floor itself), but we're packed in pretty tight as these offices are pretty expensive and you want to maximize your utilization of the space. That means that every single person around you can hear every single word you say. There is no privacy in a financial services company unless you plan for it in advance.

Even worse, if you're calling me on my desk, if I actually work on the trading floor itself, I have a recorded line. Do you people even understand that? I've told recruiters I'm on a trading floor with a recorded line, and the idiots won't shut the hell up. You people have never worked in such an environment, but on these systems, virtually any person can listen in to any line they want without anybody knowing. These is no privacy, expected or actual, on any of these lines. If I'm on one, all I want to do is get you to shut up as fast as I possibly can in the most polite possible way so that if someone picks up the line they don't hear me talking to a recruiter.

I was even in New York on a trading floor and a recruiter called me from London (I was in New York on business). In our New York office, they're really strict. No cell phones on a trading floor. That means that if you call me on a cell phone, I either have to get you off the phone right away, or I have to leave the floor, which means everybody knows it's a personal call, and since it won't sound to others (remember: no privacy) like I'm talking with a friend or family member, sounds dodgy. I said "I'm actually in New York at the moment and on a trading floor, so I can't speak. Can you send me an email?" and the idiot just kept blathering on and on about something positively stupid, and after a trader actually pointed at the cell phone in my hand, I just hung up on him.

Moreover, many of us don't like talking on the phone at all. You do. I get that. I fully understand that you spend all day on the phone and like it. We don't. Most techies do a lot of work over email and IM and other non-spoken communications mechanisms, in part because of the interruption effects (you can control when you actually are focusing on IM and email; you can't control face to face spoken communications). I am supposed to pick up my phone when it rings, because it might be someone actually important. It's you. I'm busy. I don't want to talk. Just email.

I can respond to emails at my leisure when I'm not busy. Phone calls I can't. And if you call and I'm in flow, I have about 10 seconds to get you off the line without coming across like a complete asshole or else I lose flow. And if you ever make me lose flow, I will hate you to the end of my days and suggest you go talk to and attempt to recruit the most braindead people I've ever worked with to make you seem like a right moron and get sacked. And don't think I'm bluffing. I've done it.

What all of this means is that you really shouldn't ever try to pick up the phone to me. Pretty much ever in fact, but never ever ever should you cold-call a financial techie during work hours. [Don't want to talk to people out of hours because you'd rather be down the pub with your mates? Not my problem. I'm not the one trying to convince gainfully employed people to go somewhere else for employment. You are. Suck it up or quit being a recruiter.]

Even more, if someone indicates to you in the first gambit that they work on a trading floor (which I've done), here's what you should do:

1. Shut up. Immediately. That's your sign to just shut your bloody trap. It means that the person you're calling is telling you in a polite way that they can't talk, at all.
2. Ask for an email address (though ideally you've already got one).
3. Send your contact details to their email address.
4. Iff they want to talk to you, they'll call you. If not, ideally they'll politely email you "thanks but no thanks."
   

Deviation from this indicates you really don't get it, and it's not worth my time to speak with you at all.

But that's actually quite surprising. I've never met a single recruiter in London who's actually worked as a technologist. At best, I've found some who actually understand what we do and how we do it. They're few and far between. Prove you're one of them before you try to talk to a techie. Because when we sense you're just another CV hunter trying to justify your existence in a super-tough job market, we're just going to tune you out.

Note that in all of this I'm trying to be polite to recruiters in every interaction. That's because I want to know that if I actually was looking for a job, I don't have a notation in my record in your database of "is a total asshole" that will screw things up for me.

But no matter who I am, right now, if I've got a job, chances are pretty darn good I'm not looking for another one if I'm not working at an affected institution (which for the record I'm not, although things are changing every day), so you've got a pretty low chance of your cold calling working. So just accept that I'm going to be polite while declining your opportunities, and leave it at that, okay?