Resumes, Hiring, Yada Yada Yada

I'm sitting in my comfy chair, found in my little piece of wine country heaven. I'm sipping from a delicious can of "Peter's Brand Dutch Classics" Pilsner style ale. I just want to kick out some thoughts on hiring, resumes and what not. I work with computers, being that I attained a degree in computer science from a four year university. Now in the short time I have actually been in the "industry" I have seen curious things related to employment in general.

First I will start with resumes. These are strange to me. I mean when it comes to computer work, specifically software engineering, how can a piece of paper accurately describe what you are capable of doing or what you are worth? Maybe it can, maybe it can't. Given a resume I will immediately have the mindset that this document is unlikely to provide any solid information. With out even taking a look at it. I've seen many resumes already in my field that for lack of better term "SUCK". Mine included... You can write in detail about projects you have worked on; but the hard problems you have faced and conquered, those that test your mind and patience, rarely come to light. It feels awkward to write a story in a resume, and for good reason. The story is often bland and not telling of concrete achievements. The reader, after reading paragraphs of story, will know you created some product such as "Shopping cart for my last employers website". But where is the actual difficulty in creating said product?

If you really want to give the reader the understanding of your real worth you must show them you can do things, amazing things, and that you have beaten hard times before and finished with good results. How can you do this? I have some tips, but by no means am I an expert. Just a guy with some interest in this dilemma. A resume should be thorough but brief. Next time you are working on a resume try this: list the places where you have worked in the last five to ten years. For each place of employment list out the three hardest problems you had to solve while employed at respective places. Now write up these problems as simple problem, action, results format. This data should be top to listing all the "words" you know.

On "words": Most software engineer resumes have boat loads of words that are supposed to give the reader the idea you know x y z. These words do not actually give the reader any real idea of what you are capable of. I mean anybody can become a J2EE Python Ruby Rails Hibernate Struts master, without actually having solved a real problem.

For the graduate: If you do not have experience in anything, meaning you have not really solved any problems then you are probably not worth much. Now this is not likely to be the case. During my collegiate schooling I solved many interesting and difficult problems. If you are graduating use the hard problems you had to solve in school projects to your advantage. In my case I could have listed "Created AI for solving mine sweeper using computer learning" and "Created scheduling algorithm for safe and timely operation of multiple elevators". These are not easy problems, and giving a brief and thorough treatment of these problems should allow the resume reader to see you in a proper light.

In taking this "problem solver" approach to resume writing you will not need to write long stories about projects you worked on. You will high light the problems that lied within some project(s) and how you were able to solve them. This will help the reader so much more than "Created SOAP layer to ecommerce business object layer, using XFire and Hibernate with all content encoded in UTF-8", or worse "Java J2EE Struts Hibernate Ruby on Rails XML ...".

Now on to my second deal, hiring. This one is tricky. You need good people, and there are never enough of them. Regardless of what it is your company does in the software engineering field you will never be able to get enough people that have exactly that experience needed for the task at hand. Think round peg and square hole, now scale that up to every shape possibly imaginable. Each company only has a small set of unique holes and each possible job candidate has a certain 'peg' shape. You end up often making hires of pegs that do not fit your companies holes, but in hopes that they will be able to fit at some point. The sooner the better. So for that peg to change its shape it should be highly adaptable. You should be sure of this quality in a peg/candidate this when making the hire.

I think the best way to be adaptable is to have the basic and intermediate knowledge of your field down pat. For me this is being able to identify the best algorithms and data structures to use in a given situation, or when to choose the usage of a MVC web framework over simple Servlets. Things such as fonts and encodings are very important, especially in these days of i18n. Being able to describe and properly use HTTP, TCP/IP and other ubiquitous protocols is very important. The ability to pick up new languages quickly and effectively is something that speaks volumes about your understanding of your field. Recursion, why do you not understand this? There is no good answer if you do not. Object oriented languages are here to stay, so you should be able to give reasons why you would use an interface rather than an abstract class, or describe what delegation is.

Once you have that peg which fits said hole, do not ever let them leave. I know this is not really possible, at least not in a country like the US of A, but you should be doing whatever it takes to ensure that these people stay. Turnover kills in our industry, like few others. The knowledge gained by a software engineer is akin to that of a powerful business type. The business type knows all the contacts, all the players in his industry and if he leaves you may have to kiss good bye to some of those important relations (or contracts) that keep your company afloat. Now the software engineer (or IT Programmer Analyst or whatever) knows all the business systems, the software that keeps your company running. If that person leaves you are losing the person that knows how to get what is needed from the software for your business to run. Yes you can replace him, but you will need time and money to get those "contacts" back, and have things running in proper order again. There is nothing you can do to alleviate this problem. It is possible you will quickly find someone to replace the person, someone with exactly the knowledge needed to do what that person did. Not likely though... most software used in a company is purposefully altered to do things particular to the company of example. It is not an exact match to any other software running in any other place.

So what can you do to keep people. I can't even begin. Some people get bored. Some people don't like their co-workers. Some need more money. Some have personal problems and just can't keep working. One thing I can suggest is honesty. If your company is one that is openly honest, meaning that employees can always be honest about themselves and others, you have a good chance of doing well. Honest companies will address problems pro actively. Honest people/companies are self conscious in not taking on more than they can finish. Honest people/companies make thorough assessments. The honest farmer does not sow 15 acres when he knows he can only reap 5, the honest framer does not begin building a barn when he knows he only has supplies enough for a shed.

RESTlet, POST and the HTTP Location Header

I spent a few hours this last weekend trying to get POST working in a RESTlet application I am developing for work. The problem is that RESTlet abstracts the fact you are using HTTP completely. So in my code I could not grab a HTTP response object and set headers directly. Not a big deal as long as the process of POST'ing in RESTlet is documented. It is not though... I'm reading up on REST and trying to build a well done implementation. That means using the HTTP location header to return a new resources location on POST. I dragged my nets across all documentation RESTlet and could not figure this out. I new it must be doable so I just started pushing the api methods and such, trying to find something. Finally I figured out what is needed. Here is a code snippet:

/**
* POST a document to resource. Should create a new resource with a new and
* unique UUID.
*/
public void post(Representation representation)
{
insertNewResource(representation);
getResponse().redirectSeeOther("http://www.domain.com/new_resource_location");
getResponse().setStatus(Status.SUCCESS_CREATED);
}

So what you see above is the simple way to create a new resource via POST. The 'insertNewResource' method would be your code which creates the resource in your underlying application. Once that is done you must use the 'redirectSeeOther' method to set the HTTP location header. You also will want to use 'setStatus' to properly notify the client that the resource was created.