Hiring “off-platform” - what are the indicators for successful candidates?

Question

When looking for candidates you often want to have people with direct experience with the technologies and platforms you are using today. However, that may not always be a possibility. The particular requirements may involve niche tech, outdated tech, or your team has already drained the local area of everyone with that particular tech (not everyone works in Silicon Valley, some of us work and live in some smaller metro area for reasons unrelated to the profession).

So often that can leave you with hiring people who are "off-platform" like Dot-Net people for a Java project, or Cobol programmers for an iPhone app (or vice versa). Or even just a language switch, from Visual Basic to Scala or JavaScript to C.

My question is what qualities, attributes, and experience would you look for as in interviewer to indicate that the candidate can successfully switch platforms or languages, and what are the indicators as to the level of success and timeframe.

Also, decent "war stories" related to this would get a solid upvote from me.

Answer 1

As someone has has always been hired "off-platform" (to work with technologies I was not entirely familiar or had experience with), I can think of a few things:

• Does the candidate have a history of working with various technologies?
• Does the candidate seem passionate about programming in general and seems interested in learning to work with your platform?
• Does he have experience with similar technologies? If he has developed programs similar to what you do with a different platform, the risk is low.
• Has he researched a bit about the platform before being interviewed?
• Can he answer generic programming questions?

Any programmer worth the title should be able to make the switch pretty easily (mastering the particularities of each languages takes time though) and should be up-to-speed quite fast.

Answer 2

Well, anyone with a logical mind who's able to think in abstractions can pick up the basics of just about any programming language and become proficient at it within a couple months. (Those criteria rule out a whole lot of people, though, unfortunately including a lot of professional coders.) But becoming truly good at a language requires study and experience, the sort you only get by using it every day for a few years. So if you can't find anyone with the skill and experience you're looking for, look for the basic aptitude and the rest will come with time.

According to Joel, a good test for the aptitude to understand coding is the ability to "get" pointers and recursion. According to Jeff, the tricky bits are assignment and sequence, recursion and concurrency.

And from my own experience, I'd add one other criterion: manual memory management. If someone can't keep their memory from leaking without using a garbage collector as a crutch to lean on, they don't know enough about how dynamic memory works to keep from inadvertently writing memory leaks with a garbage collector. (Which is actually a lot easier to do than it sounds.)

Answer 3

You're looking for a slut, not a serial monogamist. You want someone who is used to interacting with many technologies at the same time--these people have a very different mindset than specialists. Someone with 5 years of C++ and then 5 years of Java is probably not as good a choice for your .net project as someone with 2-3 years of C,Java,iPhone,Ruby all at once.

Sure, almost anyone can eventually pick up a new platform and eventually become as productive as they were on their old platform, but someone who's used to keeping track of three or four at a time has clearly built a much more comprehensive logical framework for managing the different sets of information and will probably pick up on something new much more quickly.

Also, people who are working with lots of technologies day to day tend to be the kinds of people who get very deeply involved with the projects they're working on and make contributions all over the place. Managers naturally pigeonhole people based on their skills in order to use them most efficiently. Someone who actually contributes to, say, the HTML/js frontend, the Java backend, and the iPhone app for a product is clearly not only trusted to have his fingers in everything, but is also capable of doing all three effectively enough that his manager allows it.

Answer 4

This one is very brief from my point of view:

• Problem Solving
• Ability and Willingness to learn

Even when hiring someone with topical experience in the tech you are using these two points make up the largest part of if the person is going to be a good team member.

I can easily answer a question about how you do x in tool y, but to try and force someone to see the problem correctly, or go find the correct answer themselves if nobody on the team knows it is something that sometimes just cannot be done.

I would rather have people who get the logical problems and have a desire to find solutions than someone with some prerequisite years of experience in the specific tools at hand.

The best hire I ever made had no experience other than gcc and we were a .net shop. He was fresh out of school and had brought a program that was a computer opponent version of the ancient Egyptian game senet. I asked him why he chose such a obscure game for his project and his answer was that the binary tree for possible outcomes was something he could verify by hand if needed. That was a very interesting preemptive solution to a problem and pretty much sold the interview.

Answer 5

I offer this largely as a counterpoint to @blucz's contribution.

You want somebody who concentrates on a few tools at a time, and learns to use them well. The fact that somebody tries to use many tools at once and believes he multitasks well doesn't mean he does (in fact, there's substantial evidence that the opposite is true).

The fact that somebody works almost simultaneously in many areas rarely means that they've shown excellence. Rather, it means they've never done anything quite bad enough to get fired outright, but no one team lead/manager/whatever really wants them either, so whenever a chance arises, he gets shuffled off on somebody else. Especially in really large companies, this is sometimes done with bad intent, with managers trying to make themselves look better by undermining their peers. In other cases (especially at smaller companies) it's a sincere attempt at finding a niche for somebody who seemed intelligent and enthusiastic, but whose real performance has fallen short of expectations.

Of course, there are exceptions to any rule, but keep in mind that they are exceptions. When somebody claims to be able to do everything and contribute everywhere, chances are really good, that in reality they can't do any of those things well, and haven't contributed anything positive anywhere.

Answer 6

My viewpoint most closely aligns with GoodEnough's as I've been in the same situation he describes most of my career, and I have some further depth/breadth to add.

Your best possible wager on an "off-platform" hire would be a Jack-of-All-Trades-and-Master-of-SOME. You need the guy to be a rock star in at least one or two of his areas because you need to be sure that he has the capability of exceptional work. You don't want a utility infielder type (can play every position but only as a mediocre replacement for the guy who really owns the it). He'll end up causing you more problems than he solves.

What you're looking for on the resume is a bunch of different platforms (with specific versions), a bunch of different languages, and projects complex enough to merit some really heavy design considerations. Just because the guy worked for a Fortune-100 company doesn't mean he worked on any mission-critical projects. They could've all been little internal department apps that nobody ever saw in the light of day. Make sure they have some significant business importance. If the guy's a real rock star, he'll gravitate toward the gnarliest projects. And regardless of how well he "talks" his game, if he doesn't have any big, nasty projects on his resume then he's not a rock star.

In the interview, you're primarily looking for a nimble thinker who is able to explain even the most complex of his former projects to exactly the level of detail necessary for you (and whoever else is in the room) to understand. Ask questions at different "altitudes" and expect the answers to be in the same altitude you asked them. Present a current challenge you're experiencing (or have already solved) and ask him for a similar example from his past and how he solved it. His story ought to resonate with you. If it doesn't or if you end up more confused after his explanation than before...then he's not the one.

And now for two very specific war stories. One with a good ending. One not so good.

Back in the day I was a Vignette consultant (hired gun, not employee). I was on a gig in NYC, and that company had partnered with a consultancy in Buenos Aires to extend their footprint internationally. I flew down to BA for a week to teach a roomful of ASP programmers (.NET wasn't yet a twinkle in Bill's eye) how to do Vignette.

So if you know anything about VIGN, you know that the special sauce for that platform was its ability to dynamically pull stuff out of a DB and then cache static HTML files on the web server docroot. Huge performance benefit vs. always pulling dynamically. And in order to most effectively architect the caching strategy, you had to "pack the OID" which means concatenating various primary key values into a single element in one portion of the URL of the cached file.

At the time, ASP programming was either POST-heavy (everything stuffed into the header) or GET-heavy (big ugly query string of vars). So as we went through the week, I continually hammered on them to replace their POST- or GET-centric design thoughts with pack-the-OID thoughts. Most of them seemed to get it, but this one guy was a real stubborn mule. Up until the last day, all his design exercises still looked like they were right out of the ASP cookbook. It wasn't until the "final exam" on the last day did that guy ever design an app with a packed OID. But of all of them, that guy ended up being their strongest VIGN guy because once he got it, he really got it. Just took a while for the light bulb to go on in his head.

The other story is much shorter. Big credit card processing company. Half a million lines of C talking to another half a million lines of COBOL. One camp (the C programmers) really wanted to implement CORBA. "Just need to stuff the C code in some CORBA-compliant wrapper, and we're off to the races," they said. The other camp wanted to rewrite the C in Java. Now this was in early 1997, so JDK 1.1 had just been released. As their "example" they (the COBOL programmers, ironically) wrote a massive several-thousand-line example java class of "how easy it would be to rewrite". Moral of the story: don't ever let your COBOL programmers write Java without Object Oriented adult supervision.