Having spent too much of life on both ends of interviewing people (mostly as the interviewee lately) I've seen and experienced a world of different styles. The intent of a first interview is usually to separate the ditch-digger from the real coder.

Most of the interview techniques suck.

Interviewers often begin with asking the interviewee about programming basics, to describe object-oriented programming concepts, to describe simple language constructs, or the like. The assumption is that the ditch digger doesn't know anything like that. Of course, an experienced programmer might be good at coding but not be able to answer theoretical questions, or be good at complex concepts but spend little time with language or framework features that the IDE takes care of. Basic knowledge is also no guarantee they know how to use it. I once new a guy who aced a Java Certification test but was utterly incapable of writing even the simplest actual program.

So, OK, you say, it's just a phone screen. Now we will make them take tests, talk with some managers, perhaps solve some Pirate Puzzles or even survive a battery of intense interviews from bored (and sometimes cruel) developers. Then we will sort out the tired, the poor and the huddled masses, oh wait, wrong concept. We will then hire the brightest, smartest person in the world!

Yet after all this massive effort on the part of many people in the organization, you still wind up with programmers who are average or worse in delivering real applications.

Clearly finding the right people is more of a crapshoot than most companies would admit to. The one thing you really want to know is "will the candidate be able to write functional code, deliver it in a reasonable time, with good quality and maintainability". Sadly that's the hardest thing to figure out without actually hiring them and seeing how well they do. I do see more people these days doing contract-to-hire.

In my experience on the hiring side, the quickest type of screen to see how well they might function in real development is to pick a random entry in their resume that appeared to be significant, and ask them to describe the requirements, the technologies, the choices, the history and what their precise role was. The assumption is that someone who actually did a real project could describe it in great detail. For me, I can still remember all the details of virtually everything on my resume, since most of them took months (or in couple cases years) out of my life. It's is very hard to riff some random details and fool a competent engineer or even manager. I want to know how intimate do you know something you say you did for a fairly long period of time, even if it's a few years in the past. You may forget the syntax or some method calls, but not something that you spent months doing.

The process of programming is a lot of little details, many of which have to be mastered and reused in most projects, even as the technologies and environment changes. Dealing with managers, requirements, plans, code management systems, testing, QA, debugging, making choices in tools or frameworks all are things you do in most projects but the details change. I want to know how the candidate thinks about the work of programming, and how they have done more so than some intimate details about a language or tool or API. These things change from time to time, the ability to actually deliver does not.

I think very little of the bottom-up approach that many companies take. They focus on weeding out the ditch-diggers and then hope some deliverers survive. I would rather find the deliverers and let the others weed themselves out.

Of course this isn't a perfect solution either, nothing is short of having people work for you for a few months and see if they can deliver. I would rather know that a person can articulate what they have done on projects and understand the process of delivery (which of course means designing, coding, testing, debugging and understanding what to do) and work the interview from that perspective.

After all, no one ever asks a ditch digger to define dirt, they want to know if they can dig it.

My Tags: programmer jobs

In the past year I've written two complete java web application frameworks from scratch; one like Wicket, and one (Blogfiche) a more traditional MVAC framework with an alternative syntax to HTML. So why am I building another one?

Am I nucking futs?

The answer is always the search for more programmer productivity, flexibility and reliability. Blogfiche (which runs this blog and other things) has proven itself to be flexible, reliable, and for what I use it for, scalable. Digg and Reddit traffic don't faze it, even though it runs on a shared (and rather overloaded) server. The alternate HTML syntax is fun to use, much less irritating than HTML if you write by hand:

    if(headlines:sizenot0)[
      div(class=articlebox heads)[
        loop(post|headlines)[
          p[a(href={post:url})[{post.title}] span[{post.created:datetime}]]
        ]
      ]
    ]

So why do another one? Mainly I want to be able to build an entire web application without any recompilation, yet still have good performance in production. I am using the solid foundation of my Fiche framework (built on the servlet spec) including its automatic caching of web content. On top of this I intend to support Javascript (Rhino) and Groovy (and anything else interesting) and see what I like better. Although I can use the alternative HTML syntax, I am building a view technology on top of regular XHTML to make it easier to use examples from the web.

Something like:

  <head>
    <title>{title}</title>
  </head>
  <body>
  {if(test)}
    <p>Test</p>
  {else}
    <p>Not Test</p>
  {end}
  </body>

For database support I will continue to use iBatis, if I can properly reload the sqlmaps when they change, or maybe try something new like couchDB, or even build something similar to ActiveRecord. There is a lot of possibilities here; the primary point is to be able to update code and database use without compilation.

I am not trying to replicate PHP or ROR or whatever flavor you might enjoy. Software is an infinitely malleable clay; you don't know what you can do unless you try something.

Again with the why? Why not, I enjoy it, I like productivity, challenges, and I have time while I wait in absolute contractor hell; at least my mind is working and I can avoid going absolutely bonkers waiting on people to make a #@!$#@decision.

My Tags: web frameworks fiche

lift Web Framework

Given how much I love writing frameworks (the one running this blog for example), it's cool to see someone is working on a framework using scala. It's still an early alpha, but it's interesting to see how one can leverage Scala's interesting OO-Functional hybrid language.

My Tags: scala web frameworks

I just turned down being interviewed for a contract position due to the client's demands for an invasive examination of my life which even exceeded what I had to do for a Secret security clearance.

Here's what they wanted me to fill out before a phone screen was even done:

• The usual employment stuff
• Detailed job history
• Authorization for investigative consumer report (salaries, lifestyle, friends, etc)
• Authorization for credit check
• Authorization for drug testing
• Authorization for fingerprint and criminal background check

Every form had my address/social security number/birth date on it and would likely be faxed to some subcontractor. There were no assurances of protecting my privacy on any form. Faxing these forms to the recruiter would open me to all sorts of identity theft since I have no way to measure the honesty of everyone in the chain (or even know who they might be).

I can understand an employer/contractee's need to verify that I am not a crook or likely to steal something after making a tentative agreement to hire me, and then where I have at least some idea of who is in charge of the information (like an HR department).

In the early 80's I qualified for a Secret Security Clearance from the DOD, and it actually had less requirements than this simple contract (which is not a defense company, just a financial services company like ones I have worked for in the past). In that defense job I was hired and then began the clearance process (although I had the clearance I never actually needed it). The FBI did all the work; whatever you might think of the government, at least they already had all the info I gave them.

So I've said no to this one, unless they decide to change their tune (sometimes people make demands they are willing to negotiate on), I will continue to work with other contract options that are less invasive.

I have nothing to hide that would concern anyone, but defending your privacy and personal information is all about avoiding giving others the opportunity to rip you off. You have to balance giving out enough to satisfy a reasonable request to the risk of losing your identity.

I'm not willing to risk all for a chance at a job.

My Tags: jobs security