How Not To Get Hired For A Tech Job

Once in a while, I toss my resume out there on Dice to see what the market’s like and what opportunities are out there; you never know, right?

It always amazes me how terrible the process is and how it’s so hard to find a job that’s just right. Among the top of my lists for pet peeves — in so far as head hunters are concerned — are:

• A total lack of reading skills. I put the resume and profile together to help save time not just for me, but also for the head hunters. No need to send me a requirement for a position in California, you know, espeically when I’ve listed NYC and Princeton as my preferred locations.
  
• A total lack of courtesy. While my profile asks nicely to use email as the preferred contact method, that doesn’t stop head hunters from calling. More annoying is that some just keep on talking, and talking, and talking…for me, it’s a waste of time to listen to them read requiremets to me; I can read just fine, thank you. 
  
• Asking invasive questions. I always get the “So how much are you making now?” question and I hate it. None of your damn business buddy! Your client can either meet the salary requirements or not…why in the world should I tell some total stranger how much I make? The bottom line is that whatever my current salary is has no bearing in the conversation. If a client can’t meet my salary requiremets and the job just isn’t that interesting, I’m not interested.  Not only that, it’s not like whatever number I give can be verified easily; asking this question is pointless because you’ll get a batch of people who’ll just make up numbers anyways.  What if I said I made a million dollars last year?  Would anyone believe me?  What if I said I made $500,000 last year, would anyone believe me?  What if I said I made $250,000 last year, would anyone believe me?  Then why should anyone believe any unverified income number over the phone (isn’t this how we got into this sub-prime mess)?

Well, anyways, once you make it past that morass, then you have to deal with the actual companies and phone interviews. This is where the fun begins (no, really)! I, for one, love being teched out. There is nothing more enjoyable than a match of wits to see if the person on the other end of the line can actually out tech me (and believe me, it would make me incredibly happy and excited if that were the case).

My new favorite part of the process is when the interviewer gets to the “So, do you have any questions for me?” part. Instead of asking boring, standard fare type questions, I’ve decided that this is my opening to gauge the technical skill of the developers in the organization.  There is positively nothing more satisfying than doing some in depth tech grilling to kind of figure out whether an environment is right for you. I’ve kind of come to the conclusion that I can really only be happy where I can be out-teched; you know, an environment where I can learn from those around me and drive me to continue to dive into the technologies.  It’s a way to make sure that you’re going to end up in a position where you’ll feel challenged and look forward to learning and solving new problems.

In any case, here are some grilling points which I’ve come up with:

What’s your approach to designing data access?

I like this question because it tells me a lot about the interviewer. In my opinion, data access is essentially the core of any application; it must be simple in design and easy to extend. It must be easy to understand and easy to use by the application layers above. Yet it must not be so basic that it’s raw and verbose.

The worst possible answer is a response with any mentioning of datasets (even worse – and an absolute deal breaker – if that’s not prefixed with “strongly typed”).

Ideally, I’d like to hear something like:

• “We usually build a domain model built on top of Microsoft Enterprise Library.” Most companies don’t have the liberty of working with open source libraries. Enterprise Library is at least a baseline. The great thing about it is that it’s very well documented and a well understood quantity.  Pluse, having EL as a base encourages or enables at least a baseline level of uniformity in the code.
  
• “We use NHibernate (or substitute another ORM/persistence library).” I realize that not all companies and all projects have the freedom to use open source 3rd party libraries, but it’s nice to see if they do or have used them in the past.
  
• “We’re using LINQ.” If you get a response like this, you know you’re dealing with a group on the cutting edge of technologies and you’re dealing with a group that doesn’t mind the challenge of designing around new technologies; the developers probably read up on this stuff and work on it in their spare time. This is a group that you want to work with.

The answers to this question offer a rich view into the development resources that a company has and whether they have a strong indication of the Not Invented Here syndrome.

I tend to think that it takes a more advanced developer and development team to understand the landscape of libraries out there and how to utilize them since learning a new library is usually far more challenging, not to mention productive, than hacking together an inferior custom solution. As such, I also like to ask the following:

What’s your approach to runtime logging?

It’s a shock to me that many consultants I’ve worked with in the past either:

• Incorporate no runtime logging or tracing capabilities into their code or…
  
• Roll their own logging library.

If you’ve been writing applications without logging, then you haven’t written any applications of any worth. If you’re rolling your own, it means you’re not interested in delivering value to your clients by wasting their time and money or, even worse, you don’t know any better; you’ve never spent the time to look into the various off the shelf logging options. log4net would be a great answer, but Microsoft Enterprise Library Logging Application Block would be awesome as well.

I’ve never gotten to a point yet where I’ve been able to pop this next question, but I think that nothing would be a better indication of “this is a place where I want to work and these are people that I want to work with” than if I got a satisfying answer to this:

Are you familiar with Inversion of Control/Dependency Injection? Do you use any libraries to implement it?

This is a great quesiton because there are some design challenges in software, particularly around extensibility and orthogonality, that can really only be cleanly addressed by using the Inversion of Control (IoC) pattern. It enables the creation of far more extensible frameworks, libraries, and applications.

Low level developers on simple projects have no need for IoC or they end up writing a lot of code that’s not extensible or modular. The more complex the application and the greater the need for extensibility, the more important IoC becomes as part of the glue that makes it all work together without a huge mess of dependencies.

If you get a response of “We use Spring.NET/Castle Project/Unity/CAB”, then you know you’re not dealing with some junior programmers. (CAB isn’t really an IoC/DI container, but it utilizes some of the concepts of IoC).

Speaking of late binding, I’m also thinking this would be a good question as well:

Are you familiar with the Fusion Log and why you would need to use it?

Only developers who’ve worked extensively with late binding would ever have a need to enable this and you can tell the experience level of a developer if he/she can even give you a straight answer on what late binding is.

If I could make it past that point, I’d pretty much surely ask:

What’s the difference between an interface and an abstract class? Which do you prefer when you design a framework or application? Why would you choose an interface over an abstract class? Why would you choose an abstract class over an interface?

In general, I don’t like being asked or asking low level nitty-gritty questions like “Can you explain how CLR garbage collection works?” or “How many generations does the CLR GC have?” or questions like “Explain the ASP.NET page lifecycle?”; these questions aren’t useful in the big picture and most of it can be looked up.  These are just mere facts, the knowledge of which, doesn’t indicate much.

On the otherhand, knowing the similarities and differences in iterfaces and abstract classes and how to use them properly gives insight into a developers approach to object oriented programming.  It’s a great question and a tough one as well. Nothing would be more awesome than a reply of “Well, according to Cwalina and Abrams in ‘Framework Design Guidelines’…”.  Knowledge of interfaces and abstract classes is foundational to an understanding of good object oriented design and programming. You cannot write a well designed object oriented system without the judicious use of abstractions.

Another great question along these lines is:

Do you or does your team use any code generation tool?

I think that in general, it takes a great deal of thought to utilize code generation.  It means that the developer or team in question understands the value proposition that it brings to development.  Of note:

• It leads to more consistent code which means that in the long run, it’s more maintainable and easier to document; it leads to repeatable and predictable results from every developer on the team, regardless of whether they’ve been writing code professionally for 10 years or 10 months.
  
• It leads to less error prone code since it’s easy to fix small errors across the board by fixing the templates or the driver.  For example, writing data contracts by hand is extremely error prone since it’s easy to forget to put a [DataMember] attribute on property which needs to be serialized.  Generating it from a template mitigates these types of simple mistakes.
  
• It increases productivity by allowing developers to get away from writing the plumbing and focusing on the business logic and UI, places where the ROI on code generation is lower.

It indicates to me that the developer or team is able to bring abstractions to the next level; not only are they abstracting in their object models, they are also abstracting the very act of coding.  To successfully utilize code generation means that the developer or team is able to see the big picture and not just a class here and a class there.  The develper or team has analyzed the code, identified the patterns, and encapsulated those patterns into templates and drivers.  You know you’re dealing with a high level team if they properly utilize code generation tools to reduce the amount of time spent doing grunt work.

Well, I’m sure I’ll think of more if I can ever get past these questions. But overall, this outing has been disappointing.  In general, I don’t think interviewers take well to a technical grilling; whether they are unprepared to answer these types of questions or they simply don’t know the answers, it hasn’t been too promising.  For me, it’s important in gauging the technical competance of my potential colleagues and the type of technical training/staff development that the company provides and/or encourages.  It’s one way to avoid ending up in a company staffed by 5:01 developers.

I still haven’t figured out how to respond to the “So what year did you graduate” question, as it’s clearly a form of age discrimination but I’m not sure how to call someone out on that yet.  More importantly, it implies that the groups and personnel are not necessarily organized by merit, but by seniority or, even worse, cronyism.  I think next time, I’ll just be blunt about it and ask if the interviewer realizes that it can be construed as age discrimination.