First off, this is my <sarcasm>long-awaited</sarcasm> return to blogging on this site. It’s been almost 2 years to the day since I put up my last post. Sheesh, that’s been way too long. Thing is, I’ve been busy writing books and lots of code, and I also do a lot of ad hoc “micro blogging” on https://gist.github.com/getify/. Oh, yeah, and then there’s my twitter addiction. And I also now teach lots of JS workshops and classes. In fact, that’s kind of my new passion.
Anyway, this blog post is just a quickie kind of rant, and I know at the outset it’s probably going to come across rather rude and stuck up. So, sorry for that in advance. I’m really just calling it like I see it.
LOL
Right to the point, then. Technical interviews are bogus. They suck. I’m convinced of it now, for no other particular reason than that I actually spent some time thinking about what it would be like if I left the glorious world of self-directed employment and went back to a “real” job. I was imagining what the interview process might be like, and I realized just how silly the concept of someone trying to technical interview me would be.
Honestly, and I hope I’m not spoiling the milk (or whatever the appropriate colloquial phrase should be), but if you’re considering interviewing me for any position, and you plan to try and test my technical chops during that process, there is no job I want badly enough which I would spend time sitting through that. I’d probably just chuckle and say, “just look at my github and my gists”.
Actually, I don’t care if that spoiled the milk, because if you find that tech interviews are how you best judge candidates, you’re not the kind of organization I want to work for. I want organizations that hire everyone based upon proven public track record and not based on writing up for-loops on a whiteboard.
Code > everything else
That’s the main point that I’m trying to make: my open-source code, which I work on fairly frequently, is the best resume I could possibly give, and it’s also the best technical interview you could possibly do of me. Spend some time and look at my public gists and my other repos, and I think you’ll get more than enough sense of my technical chops.
If that doesn’t do it for you, then take a look at all the blogs I’ve written here over the last few years. (Yes, I’m going to get back to blogging, but not necessarily on here. Haven’t decided yet. Gist blogging with markdown is so much nicer than the wordpress crap I have installed here.)
I’m writing more blogs even right now, and I should have several released soon’ish. Read those. They best represent the technical chops I bring to the table. If that doesn’t do it for you, look at my couple of books (I have others in the works). Or look at the book I’d really like to write (if I can get funding).
In fact, another great place to look at my code is on my jsPerf profile. Want to see what kind of code I write when I’m caring about testing JS performance? It’s all there.
Or, look at my Stack Overflow profile where I occasionally help answer people’s questions (or sometimes, ask a few of my own). That’ll let you know more about how I problem solve.
Speaking of problem solving, definitely look at the issues lists on some of my more well-known github repos, such as LABjs. Look not just at open issues, but at a variety of the older issues, and you’ll see more than enough about how I govern my OSS projects, how I triage bugs, how I conduct myself as an open-source citizen, and what sort of respect I try to give other devs.
Maybe you’d like to take a look at the 40-50 conference talks I’ve done over the years. I’ve got slides, videos, audio recordings, and demos posted from all those talks. Tons of great info about me.
Need references? I’ve taught hundreds of people JS and HTML5 and Web Performance optimization, so I’m sure I can find a few who can attest to what I know and how I can teach it.
The good, the bad, and the ugly
Of course, I can also be blunt. I’m not always the most tactful. Sometimes I’m a downright jerk. So search around for posts from me on various standards lists, bug trackers for browsers and projects, etc. I upset a lot of people with how brash I can be. You’ll want to look at that, too. Just know, that comes from a place of passion about what I do and care about. I’m sure I have more people who don’t like my style of communication than those who do.
I also don’t know everything. I’m not a generalist with a broad range of skills and an eagerness to chase any new technology. I’m a specialist in JavaScript, HTML5, middle-end architecture, and web performance. That’s my sweet spot, especially where they overlap. I’m not terribly useful outside of that zone, though. I’d get bored easily. Yes, that means if you want me to do CSS for your site’s buttons, I’m not a good fit.
Point: finding out all sides of me as they’re exposed online is the best way to decide if you should hire me. That’ll give you both an idea of tech and culture fit long before I walk through the door.
Both ways
If I am ever in a position to hire tech people for my team, I assure you I’m going to insist on this same mindset. It goes both ways. Not only do I think this is better for me as a candidate to say, “Hey, just look at my commit history”, I think the organization I might theoretically be working for and hiring for will also be much better if I get only people that have actually proven themselves over time.
I care about open-source, and that’s why I invest so heavily in it. There’s an ethos and a passion and a commitment that this community often implies. And THAT is the kind of people I want to work with. And I think that’s what will build a stronger tech team.
UPDATE: I have been asked by a few people how (if at all) I could “interview” people if they don’t (or can’t) participate in OSS. Let me just share my thoughts on that specifically:
I think that looking at how someone behaves during a few hours of “intense” interviewing is a very low-fidelity way of judging how they handle problem solving, etc. So, my indictment is on that process as a way to judge someone’s tech skills, reasoning, problem solving, etc.
The best way I can see to judge those things is by looking at someone’s OSS activity from a period of time. If that can’t happen, the next best thing is to emulate that in some way. For that sort of a candidate, if I really felt they had potential, I would have to invest quite a bit more time in creating a scenario where I could more accurately judge them.
I would basically set up a private repo with some code already in it (maybe just a dump of some part of my app), and get them into that repo. Then I’d file a “bug” against the code, and ask them to work on it. And I’d conduct, over a period of several days or a week or two, an exchange back and forth with them over that, and I’d do code review feedback on what they committed, etc.
Basically, I’d run them through a microcosm of the normal OSS process and see how well they handle it. IF ALL THAT PASSES WELL, then I’d proceed to bring them in for in-person interviewing, as I describe immediately below.
Level-set
Will this take a lot longer, and will it miss out on some undiscovered talent, and blah blah? Sure. Maybe. Who cares? That’s the way it has to be.
The current state of affairs of bottom-feeding keyword sucking ambulance chaser recruiters placing people, and the current state of “hey, can you write a palindrome checker using only `do-while` loops?” technical interviews are proof that this area needs to be shaken up.
In-person?
Do you also need to conduct a real interview? Sure you do. All I’m saying is that you need to get tech and culture fits out of the way during your screenings before you bring them in.
What then is the point of the real interview? Find out how comfortable the person is with other people. Sit them down with current employees and have them pair-code on some stuff for a few minutes. Take them to a real team meeting about some feature or bug and see how they do in the meeting.
I am not ONLY who I appear to be online. I am a real person, and my in-person communication skills are different (in good and bad ways) than my online skills. You have to hire the whole candidate, not just their online persona.
But if you don’t like their online persona, or they have no proven online track-record, I just think that your little 45 minute quiz interview is not gonna work.
And I think this realization is part of embracing the new state of open-source development. What I’m suggesting now wouldn’t have been feasible even 3-4 years ago. But this is where we now are.
So, don’t try to hire me with a tech interview. Don’t even call or email me until you’ve looked through my online track record and you KNOW already that I’m gonna be a good fit. Save yourself and myself a lot of time. Do your homework. Find out how who I really am, and get a good idea of what I want to be doing.
Then, and only then, give me a call.