So, I updated the site today adding two new features that I have wanted to add for a long time: Last Beer and Last Tweet.

Last Beer is a peek into the last beer that I consumed and checked into on Untappd.  Don’t know about Untapped? It’s basically foursquare for beer and if you aren’t using it, you are really missing out.  I’m a big fan and regularly use it to track my beer consumption and history.

Last Tweet is, as imagined, the last thing I tweeted, retweeted or replied on twitter about.  It’s about as basic as it comes.  I am a huge twitter fan/user and if you are not, you should be.  Twitter is where it’s at and Facebook is incredibly lame.

The really cool thing about these two features is that they are both built and running on node.js.  What’s more, Last Beer uses the Node Module node-untapped which I wrote back in march as my very first node module.

I will say that getting node.js up and running in my hosting environment was a big PITA, but only because my hosting environment in a shared hosting and running server processes is a big no no there.  I ended up having to buy a VM and run it there.  That meant a fair bit of research and what not on which service was better and cheaper and all that, but I finally settled on one in April.  Once the server was provisioned getting node.js running was trivial.  It’s really been a pleasure to work with once you figure out what you want.  Perhaps I will blog about the experience in more detail at a later time.

http://untappd.com/user/arei

So, I have, from time to time, been asked to interview various candidates, despite not having much say in the hiring process in general.   Mostly, I’m asked because my employers want me to tell them if the candidate is technically competent or not.  But for me, technically competency is only half of the picture.  I want competent, but I also want passionate, and that, is by far the hard trait to find. Passion is the difference between merely writing code and breathing code, the difference between a cog and a creator, the difference between collecting a pay check and committed to the future.

To that end I have developed a series of questions that helps me narrow the pool some.  These are questions aimed at gauging beyond competency, but the passion one brings to the team.  Without passion, you are just a robot and robots are a dime a dozen… (especially in government contracting).

So, here are my top five interview questions for finding the kind of people with which I want to work.  These are all related to software development, but I’m sure you can adapt these questions to whatever industry you work in. I don’t really have an opinion on your industry, so you are on your own.

Question 1). Describe the coding you do outside of work.

The answer a candidate has for this isn’t nearly as relevant as the fact that they have an answer for this.  A candidate who is not programming outside of their work structure is, generally speaking, not in love with what they do. If you don’t love what you do you might as well not be doing it, you are certainly not worth my time of investing in you.  I will give some credit to someone who describes what they would like to be doing outside of work, but they cannot find the time because of family.  I know families take up a butt load of time, so I respect that.  Often times when I am interviewing this question is asked obliquely in the form of “What’s your Github account.”  It’s the same thing really, although this will also let prospective employers view your work directly as well.

Question 2). Tell me what websites/sources you regularly read in order to stay current in your field?

This is a great question to separate the amateurs from the experts.  If you are not reading multiple regular sources to stay relevant in your field you might as well retire. Every field and industry has sources devoted to keeping you up to date in your field, follow at least three and stay on top of it.  When a candidate fails to answer this question I pretty much stop right there.  This is even more true for technology people than others, but can be applicable in other fields.  For example, my fiancee Jennifer is in Acoustics and she regularly reads science journals to stay on top of her field.  Technology just makes it easier as there are thousands of sources.

Question 3). “I see that you list Library X on your resume.  How would you change X and make it better?”

This is one of those dual purpose questions… You can answer this technically, but any answer you give will also show whether or not you have passion to make things better.  I can judge both by your answer here.  The worst possible answer though is “I really love the way X does this and wouldn’t change it at all.”  If you don’t want to change X you probably aren’t using X very much.  Actually, there is a worse answer than that and that is the answer where you fumble around trying to find an answer which tells me you lied on your resume.  Fail.

Question 4). “Who are some of the movers and shakers in your field that you like and why do you disagree with them?”

Again, this question goes to whether or not the candidate is staying current.  But more importantly, it delves into the candidates opinions and ultimately, passionate people have strong opinions.  You might not agree with them, but you cannot fault their passion and commitment to a point of view.  The follow on questions from this one can really be intense as well and give an interviewer a great chance at delving into the prospective employees views.  Don’t miss out on the chances this question can open up.

Question 5). “What’s the worst thing you’ve ever written and why?”

A great question that challenges the interviewee to examine their own work and then defend it.  This can be followed up with all kinds of interesting question to get at problems or desires, success and failures.  Passionate people not only recognize their failures, they have loads to say about how they would change things.  A person who doesn’t think they have improvements to make on their own work, is one I don’t want to work with.  Continually striving to better oneself is a must.

So there are my five questions.  As with all Interview questions, these are incredibly leading question which allow for a great deal of follow on and discussion.  And they are meant to be that way.  A single interview question isn’t an end, but a beginning to a discussion.  Ultimately, these question do not guarantee that you are going to find the perfect person.  Rather, they serve as a guide to allow you to delve into the depths of what really excites a person about the work that they do and the work you envision for them.

And there isn’t a score here for questions they got right.  All of these questions lead to discussions that will reveal the characteristics that I am trying to get at, namely whether or not the interviewee is passionate about their work.  Each interview is obviously different and have to be judge differently.  In the end it really comes down to a gut decision.  The hope here, however, is that these questions can lead you to better gut decisions.

The goal here is to determine a persons passion, their excitement for their job, because a person who lacks that kind of edge is really not worth the time.

Yes, it’s true. Dependency Management Pisses Me Off. Jason van Zyl over at Sonatype needs to be kicked in the groin… repeatedly. (Sorry, I don’t really know Jason and it’s not nice to say such things, but I wanted to really hammer home the point. Jason, I apologize to your testicles.) Seriously, when did we become so amazingly lazy that saving a JAR file into our SVN repositories became a big deal?

Now, I don’t want you to just think I’m some raving lunatic out there on his soap box shouting into the wind despite the accuracy of this picture; I want to at least pretend that you are not going to scream “TL;DR” and actually read the damn posting, so here is why Dependency Management pisses me off. Feel free to reply back to me on Twitter (@areinet) and I will engage you in some spirited debate. And I promise I won’t hurt your testicles in the process.

1). Dependency Management adds unnecessary complexity. Are we not just talking about saving some files into our SVN repository after all? Why is that so hard? And who on earth thinks that writing and changing a pom.xml file is actually easier than this? Also, there are people who would say that you shouldn’t be committing built objects into SVN (or whatever) and that we shouldn’t waste disk space. To these people I say this: Disk space is cheap. Seriously, the going rate for a HD is around 9gb per $1 USD. I assure you, no matter how many JAR files your project needs this is incredibly cheap.

2). Dependency Management puts someone else in your build loop. When I build a project, I want to rely on as few people as possible to fuck things up. Yet Dependency Management injects a completely incalculable third party into your system, and that’s just for one dependency. Sure, that dependency is always there, but with external dependencies, your are practically begging for your build to break because John Bozo three countries away from you removed six bytes of code from that one project you were relying on. Now, of course, you shouldn’t be using LATEST in your dependencies, but I really don’t want to rely on the fact that our build people are smart enough to realize this. If I just committed the version I wanted to the repository, none of these problems happen.

3). Licenses Change. When your build person goes out there and changes a version number, do you think they actually read a license file? Let’s assume for the sake of reality that people are incredibly lazy… now, do you want to take the risk that so and so actually read the license? And that the license didn’t change? Seriously, it would take me about six seconds to change the license on some sub-project you use and then commit it. And suddenly the sub-project owns all of your IP simply because you used them. Now, the legality of that is a debate for other scholars than I, but it could certainly cause a mess. The only thing stopping a sub-project from doing this,is the hassle of suing your ass into oblivion… And we all know that people are getting more and more litigious every day.

4). The Internet is, by it’s nature, unreliable. Do you really want to rely on the fact that the internet providers upstream from you are not going to screw something up right when your absolutely must deliver build has to get run? Seriously, the more people that have input into a process, the more likely that process is to get derailed. I do not want to think that my ability to deliver is dependent on whether or not Anonymous is going to cause a world-wide outage in protest over SOPA (which sucks by the way). Sure, you can run a mirror of x repository and spend your time maintaining that as well, but wouldn’t you rather spend time, oh I don’t know, outside? With a girl? playing WOW? Doing anything else?

So the point here is this and this is the TL;DR for you lazy people as well… Dependency management adds both complexity and unpredictability to your systems and this is not a good thing. A Build process is about Rigor, and Dependency Management is antithetical to rigor. By using a Dependency Management solution you are willingly signing up for problems and extra work. Who wants that? When given the choice between that and just storing the files I need into my repository, I will choose the latter every time.

Now, I do think some dependency systems are way better than others. The node.js NPM system is amazingly clean, but it’s still begging for the problems I outline above. So, maybe not that awesome. It is easy to use though, wish Maven were half that easy.

So, that’s it. That’s why every time my coworker comes in and raves about how awesome Maven is I just point at his crotch and start laughing. I mean, really, Maven? Awesome? You got to be an idiot to think that. (My apologies to my coworkers.)