Salespeople have a reputation for being just about the worst people to work with when building software. Being in the CRM space myself, this is a constant topic of conversation. Usually the focus is around user adoption, as opposed to mundane complaining about salespeople caring about nothing but their commission checks. But it’s true, that’s all they care about. That’s why when pitching CRM systems to salespeople the pitch always revolves around increased sales\commission.  “This will save you time, so you can do more of what you do best, selling!” or “Not only will you have greater visibility into what your customers are interested in, but when they are interested so you can strike while the iron is hot!”. The thing is salespeople don’t buy CRM systems. Sales managers do. This stuff that we are telling the salespeople is usually post sale, during training, when we are focused on user adoption.  Good salespeople know when smoke is being blown up there a**, and this is a primary reason why CRM systems have abysmal user adoption rates (though it has gotten a lot better in recent years). Salespeople know that all this extra data entry is primarily for the sales manager’s reporting needs.

The traditional advice is that companies should seek a system champion. An evangelist, who is going to sell the system to users, and if he fails simply force the users to use the system. I feel this is somewhat misguided; systems that work shouldn’t have to be sold to users. When presented to users, it should have such a clear advantage over current processes, that the users themselves evangelize the system. Yet, how often do you hear business users praising the systems they work with? It’s almost unheard of.

It’s my belief that IT workers need to take ownership of this. For too long we have left business managers\owners to evangelize technology….

In a perfect world, up front at the start of such a project, the technology team would tell the sales manager, “If you want your reports, your sales people have to do some data entry, lets figure out a way to make the CRM system work for them, so they want to do the data entry because they benefit from that data too. Now let’s work together to figure out how to do that.” But this is rarely the advice given.

My initial reaction to Gene’s Article.

Some time ago, I read a great article, in which the author (Gene Marks) is “sick of the whining”, he tells business owners to take responsibility for their technology and getting the most out of it, he says:

“the problem with your CRM system isn’t usually about your CRM system.  It’s about you.  It’s the way it’s been setup.  It’s the way it’s been implemented.  It’s the way it’s managed.  Wake up.  Stop your finger pointing.  Enough with the whining.  Look in the mirror.  If you want your CRM system to succeed, then take a deep breath and do these three things….“

Gene is 100% correct on this, but what really hit home in this article is the following quote:

“To succeed, you also need someone like Kathy.  Hire that person or re-organize to create time for that person.  This should not be an IT person either – those people are not suited for this task.”

Ouch.  What really hurts about this is that it’s true. IT people suck at questioning business requirement correctness and suck even worse at questioning business requirement usefulness. The below image is from the ITSM Trends 2012: The State of the Dev-Ops Union report

91% of business system users don’t consider IT to be a true business partner, 91%! Even if this number is off by 20 points, it’s an embarrassment. We as technology professionals should be ashamed. Maybe business owners share some of the blame here. But the bottom line is, we work for them, not vice-versa. It’s our job to keep them happy, and we are failing miserably.

For 10 years, I worked in professional services. About 2 years ago, I joined a Fortune 500. I always knew this was a problem, but for me it was always a good problem. If I had to make a back of the napkin estimate, I would estimate that 75% of our Fortune 1000 customers worked with us for no other reason they when working with a vendor they didn’t have to deal with internal IT people.

Professional services firms understand how important it is to be a strong partner with their customer . Product companies understand this as well, probably even more so than professional services firms. All too often internal IT staff looks at business users as peers as opposed to customers.  This is what I feel is at the root of this problem. If IT looked at business users as customers they would make it their business to know everything there is to know about their customer and bend over backwards to help them achieve their goals.

Internal IT departments need to get on the same page as professional services firms and product firms when it comes to understanding business and only then can they provide proper guidance on the use of technology. They need to act as an advisor on business matters (not simply technological ones), they need to accept that business users don’t understand how technology works and therefore don’t always know what they need. Today internal technology people simply don’t know enough about the business they support to properly guide them.

Enter the Business Analyst, the individual who doesn’t fully understand the business or the technology. Most often the business analyst is reduced to a middle man between business and IT, not allowed to think but only to ask and document. More often than not the technology team understands the business rules better than the business analyst. I can’t count how many times I had to explain the intricacies of a formula or data integration to a business analyst only to get a blank stare back.  Often (I know I have had to many, many times) a developer needs to compose an email for the business analyst asking a very detailed question, only to have him\her forward it along to the business owner. A business analyst is not the solution. It’s not surprising that has come up on P.SE, see: “How much system and business analysis should a programmer be reasonably expected to do?“

A classic example of bad advice given by IT, and approved by the business.

I think the solution is clear. IT people need to take responsibility for understanding the intricate details of the business; it is my belief that any IT person should be able to conduct the job of the person they are writing a system for with a reasonable level of competency. Yes, if you are writing accounting systems you should be able to perform the job of an accountant. Yes, if you are writing marketing systems you should be able to run a simple marketing campaign.

This is the level of knowledge needed to build proper systems, and is the only way you, as an IT professional will understand the psychology of your user and can be confident that you are not only meeting the business requirements, but that you are meeting the intent of the business requirements.  This is the only way to insure that you are building systems are usable by your target audience, that your users want to use.

This is what I believe is what needs to happen to restore the broken relationship between internal IT departments and business users. It starts with you… step up, learn your industry, it will make you a better IT professional.

One final point, an anecdote really… Recently one of my old clients asked me help him to look into an issue with a Gift Card module I wrote for them years back. The system had worked flawlessly for years, until one day a customer complained that he didn’t receive one of his gift cards. While investigating I came across something very odd, the customer was buying gift cards with gift cards, over and over again… really bizarre. At first I thought, maybe his gift card was about to expire so he found a loophole, to extend the expiration. But no, he was buying gift cards using gift cards he bought the day before!! W.T.F.! This is what caused the glitch. I fixed it and went on with my day. But this odd behavior was bugging me, why would someone use a gift card to buy another one? Few days later I was talking to another person who worked for that same client and told her of the odd set of transactions. She immediately knew what this person was doing. A few weeks prior the Co joined one of those “Cash Back” affiliates, so basically this person signed up with the cash back affiliate, and every time he used  the gift card to buy another gift card he made 1% of the gift card value! So basically kept turning over the same $100 gift card making 1$ on each turnover! That’s one smart SOB! Anyhow the point is understating the business is also an important part of system security. Perhaps I knew a bit more about the marketing habits if this retailer, this sort of “fraud“ could have been prevented.

Recommended Reading: Quantum: Einstein, Bohr, and the Great Debate about the Nature of Reality

I always find it fairly amazing how many questions appear on Programmers.SE, and Stack Overlow, with the subject of “Which x is better?”. Equally, I’ve been involved in a conversation with co-workers and friends on many occasions where the subject line starts with “What do you think of x?”. The commonality of these two separate threads is that the x is always a language, framework, or tool.

I want to go out on a limb here, and state my conclusion at the start of my essay:

Learning a new tool does not make you a better developer.

Learning a new technique makes you a better developer, tools are just there for convenience.

I’ll start with an example from my own experience. I started off as an ASP.NET WebForms developer straight out of University. I quickly became very knowledgeable about the framework itself, learning how to force it to work for any edge-case I needed, and learning how to build extensions and re-use previous components effectively. I considered myself a talented developer, and was considered to be very highly skilled by my employers. Upon reflection, it is now clear to me that I was a terrible developer.

After a while, the ASP.NET MVC framework was publicly released, to much fanfare. I scoffed, safe in the knowledge that I could make any website faster, and with more functional stability, than any other developer that I knew could develop things in the MVC framework. I began to learn MVC, and being unused to the pattern, struggled to really understand the principles behind how to develop on it. I was a brilliant ASP.NET WebForms developer; I was a terrible developer.

A little while after that, my WebForms project came to an end, and I surveyed the carnage. Bad use of JavaScript was the really key example, because I didn’t understand that putting your JS inside the page and running it as-and-when a control was used was costly and slow. Code reuse in the backend was there, but not ideal, as many actions were done specifically for the page that called them, as opposed to sharing a common data access methodology. The UI code was bloated and ugly. I took this as a good opportunity to start using the MVC framework; clearly it could result in cleaner code, I had seen other coders achieve this for myself. I became an excellent MVC developer. I was still a terrible developer.

Eventually, I came to the realisation that the MVC framework was not ideal. It had some clunky and unwieldy features (such as Microsoft AJAX), and, while it could lead to very clean code, it often did not.^[1] It was around this point that I began to learn NUnit, and the principles of TDD; I quickly became a Unit Testing aficionado, and the code I produced jumped up in quality.

At around the same time as learning TDD, I began to investigate the Agile methodologies, and how they could help my development skills. This was the real turning point; I started using my own little Kanban board to manage a project backlog, and watched the quality jump again due to the increased visibility of what I would be building and the increased ability to group tasks with other important tasks. I’d used a technique that I’d never considered to be part of development, as it was neither a tool nor a language, to improve what I was developing. I had learned how something worked, not just how to use something, and it had made my code better.^[2]

Since that turning point, I’ve become much more introspective, examining my skills and trying to see if I really understand how something works, not just how to use it. I’ve written my own MVC framework in node.js to prove to myself that I understood not just how to use the MVC pattern, or how to code JavaScript, but that I really understood why the pattern pushes you to better code. In the process, I became intimately familiar with the HTTP spec, and now really understand how the web works, not just how to build things that run on it.

This brings me back to my initial conclusion. It’s clear to me, in retrospect, that I have progressed as a developer not by learning how to use ASP.NET MVC, or how to use jQuery, or how to use node.js, but by delving a little deeper; learning how to apply the MVC pattern in a different language with different principles; learning how the underlying framework of WebForms really interacts with the web browser, not just how to write a custom datepicker control.

It’s very easy to get entranced by a new tool. Perhaps you’re enamoured by the features of a framework, being certain it’ll let you build your apps faster, or more robustly. Or perhaps you’re certain that Silverlight will let you build perfectly acceptable rich client applications without having to learn a new language^[3]. I’ve done it myself many times. The trick is to realise that, yes, new frameworks are great, and you should broaden your horizons as much as possible. Just don’t forget that frameworks are transient, and tools become outdated.

We can really see this attitude at work in the recruitment area of the IT industry. Every job advert I’ve seen in the past year has “$language$ developer required”, or “$framework$ developer required” as its title, and contains a list of frameworks and tools that you are expected to have at least 3 years of experience in using^[4]. What recruiters and HR managers cannot seem to understand is that each and every framework, tool, and language, has a number of parallels.

Let’s take C# for an example. Yes, C# is very Microsoft-centric, and the .NET framework has a specific set of tools you’re likely to use, NUnit for example. However, at its heart, C# is very similar to Java. Yes, you’re going to declare an anonymous function in a completely different way, and you’re going to use JUnit, as opposed to NUnit, but any C# developer worth his salt should become fully operational in Java in a very short period of time.

On the other hand, your average C# developer may well struggle with Ruby, for example. Dynamic languages and static languages are so different in usage that they require totally different techniques and patterns to use^[5]. Dependency Injection? Don’t really need that in a dynamic language. Interfaces? Nah, not like you’re used to.

How do we fix this problem? Well, there are a number of root issues here. The first is developers truly believing that being intimately familiar with, say, rails, makes them a good developer. We fix that by encouraging newer devs to be multi-disciplinary. I firmly believe that the best way to enact change in such a broad area as development is from the bottom; if every new developer comes into the game believing that they need to be familiar with more than just the language, and framework, that’s directly in front of their face all day at work then many of them will go out of their way to learn a broader range of techniques, instead of just learning their framework of choice more intimately, or new a framework every now and again.

The second issue is the issue of organisational change. Most development houses do just one framework, and are very keen to continue to do so. On one hand this makes perfect sense, why change what already works? I recently had a conversation with a developer at another organisation about node.js: he claimed that node.js was perfect for every use case, I assured him that it was not^[6]. This attitude of one-size-fits-all is problematic, as developers in small companies aren’t going to be exposed to the broader range of approaches you’ll see in large companies where they recognise that sometimes you want your backend system to be written in a different manner to your API. This is, again, something that needs to come from the bottom. If you’re pushing your own boundaries, discovering new techniques, you’ll begin to learn which are the most appropriate for which scenario. Don’t always punt for the new and shiny, try and keep a level head and really think “do I want to use this tool because it’s the best thing for the job, or because I want to use it”.

The final issue is hiring. This one can only change from the top, so I implore those of you who are in a position to influence the hiring process in your organisation to look at a developer’s skills, not just their résumé^[7]. It still surprises me that most development houses either don’t have a development test, or have one that only deals with their core technologies, not the skills that lie behind their use. It would be amazing to see a community resource containing not just a list of “good questions” to ask, but of good skills to look for, and how to look for them effectively.

So, I’ve spoken about how I’ve developed as a programmer not by learning new languages, but by pushing my boundaries in other ways with new management techniques and improving my understanding of the underlying principles of the languages I do know. I hope that a few people who read this can look at their own skills and think “you know, I understand how to use this, but do I understand why?”. Real change is slow and difficult to enact, but in such a young, and social, industry we have an incredible opportunity to make changes as a community.

[1] I have seen developers write five thousand line actions inside a controller, through both laziness and lack of knowledge. Those of you with MVC knowledge should shudder at the thought.

[2] Don’t get me wrong, I’ve not yet hit the pinnacle of my development abilities, I doubt I’m anywhere near (or that I will ever really get there). Everyone has more skills to learn, myself included, and I dedicate a large amount of time to investigation of new things, and practise of the old.

[3] I once had a fairly involved argument with a colleague about whether Silverlight was worth using. I, unfortunately, lost, and the now-legacy Silverlight app has caused a myriad of deployment issues and at least one developer to leave the organisation.

[4] I particularly love ones that are “$cms$ developer required”. Those go straight into my trash.

[5] Yes, C# has the dynamic keyword. No, that doesn’t make it dynamic; dynamic in C# is just a slightly more ducky version of var.

[6] Batch processes was where I finally won that one. Anyone writing enterprise-sized batch processes in node.js has a serious case of myopia, in my opinion.

[7] I recently went to an interview where the only technical question I was asked was “What is the difference between “visibility: hidden” and “display: none” in CSS. This is not an accurate gauge of anything.

So you’ve been using Stack Exchange for a while now and, like most other programmers, expect to be able to customize the website. I’ve seen many feature requests on the main meta, and a large fraction of them never get implemented because:

• It’s not a feature that everyone will like — Stack Exchange tries not to provide too many customization options, so features that will be annoying to some won’t be implemented
• It’s a rather minor feature that may be only useful to some people (or will be used rarely), and not worth the developer time
• The developers are all busy working on something else

It could be something as simple as adding a small reply button to comments. It could also be something more elaborate; like a script that lets one manage and use a bank of boilerplate comments or a script that makes editing long posts easy.

Whatever it is, it’s not always easy to get a feature implemented. In many such cases, userscripting proves to be a viable alternate solution. For those who haven’t heard of userscripts, a userscript is a block of JavaScript code loaded into the browser by the user. It contains some metadata, including instructions for the browser on what type of pages it is meant to be loaded on. They’re very useful if you want to tweak the behavior of a website.

Tips for creating a userscript for Stack Exchange

Firstly, here’s the userscript template that I use:

// ==UserScript==
// @name Script name here
// @description Short description goes here
// @namespace Manishearth (This is to avoid conflicts with userscripts that share a name)
// @author Your name here
// @license GNU GPL v3 (http://www.gnu.org/copyleft/gpl.html)
// @include http://stackoverflow.com/*
// @include http://serverfault.com/*
// @include http://superuser.com/*
// @include http://meta.stackoverflow.com/*
// @include http://meta.serverfault.com/*
// @include http://meta.superuser.com/*
// @include http://stackapps.com/*
// @include http://.stackexchange.com/
// @include http://askubuntu.com/*
// @include http://meta.askubuntu.com/*
// @include http://answers.onstartups.com/*
// @include http://meta.answers.onstartups.com/*
// @include http://mathoverflow.net/*
// @include http://meta.mathoverflow.net/*
// @include http://discuss.area51.stackexchange.com/*
// @exclude http://chat./


// ==/UserScript==
function with_jquery(f) {
    var script = document.createElement("script");
    script.type = "text/javascript";
    script.textContent = "(" + f.toString() + ")(jQuery)";
    document.body.appendChild(script);
};

with_jquery(function($) {

// Your custom code goes here

});

The @include directives tell the browser which sites to load the script on. You may wish to tweak these to your needs. You may omit the with_jquery bits if you’re not planning on using jQuery, and instead just write your code after the // ==/UserScript== line. If the file is saved as a .user.js file and loaded into your browser (instructions for each browser here), then it will run the code on each SE site you visit.

Make sure you’re familiar with the Chrome Developer tools (or Firebug) as well. Remember that building a userscript is different from using JS for making a dynamic webpage. In the former case, there are many more unknowns, so one can’t always accurately predict how the page will react to your code. With this in mind, I find that it is easier to develop userscripts bit-by-bit on the console, instead of writing a large portion of the script at once and then testing it. I start by testing smaller code snippets on the console, and slowly assembling them into larger code snippets. Then I assemble the larger snippets off-console. This way, you can catch bugs before they get buried in large chunks of code. For example, while writing this script, there were a few issues with the predefined behavior of the preview and edit history that would have been quite hard to catch if I had written the code in bulk.   Another thing to remember is that Stack Exchange has many dynamically-created elements. If, for example, you want to add a  keyboard shortcut to the markdown editor, you will need to make sure that the corresponding event handlers are delegated. This post (and this documentation page, under the “direct and delegated events” section) are good places to learn event delegation via jQuery.

The Stack Exchange API is currently limited to mostly read actions, but it’s another useful tool for writing userscripts and apps. You may have to register for an API key, depending on the nature of the script.

A final, very useful resource is the unminified javascript. The normal Stack Exchange javascript files that one sees in the debugger  look like this (there is also stub,js, full-anon.js, and wmd.js), but by modifying the cdn in the URL to cdn-dev, one gets this page, which is much easier to read. The URLs may change — if the above links change, go to http://dev.stackoverflow.com/ and look for the URL of /js/full-anon.js in the source code or the sources tab of the Chrome developer tools.

Publishing your script on StackApps

StackApps is a repository of apps and scripts for Stack Exchange. You can just post your script by asking a question tagged with the [script] tag. Give links to the script source code, and instructions for installation and usage. Note that installing a userscript on Chrome is currently a slightly roundabout process, so it is advisable to link to the [script] tag wiki for further instructions. Here’s an example of a complete StackApps script post.

Some great userscripts

There are a lot  of  awesome userscripts on StackApps, which can be directly installed. Here are some of those that I find quite useful:

• Keyboard Shortcuts for Stack Exchange
• “Reply” links in comments
• Auto-scrolling in the preview for editing long posts
• Make a post printer friendly
• Better handling of the tab key for code indentation
• Boilerplate comment manager
• Punching users through the internet

Well, there you have it. You should now be able to tweak the behavior of SE to your tastes with relative ease.

Note: This is Part III of a three part series; it is recommended that you read Part I – The Basics & Part II – Marketing first. 

A quick Re-cap

I previously defined the Job search Sales phase as “Direct contact with a potential employer where, building on your marketing, you sell yourself as the perfect candidate for the job”. This is everything you do from the moment you get a person on the phone discussing a specific opportunity and afterward.

Also previously stated is that the Sales process looks something like this:

Sales

1. Develop\fine tune a targeted sales pitch for each response (These are no longer leads, These are now Opportunities)
2. Make first (direct) contact.
3. Recruiters\HR
4. Phone screen(s)
5. In Person Interview(s)
6. The Offer
7. Negotiation
8. Postmortem

Sales is a direct extension of marketing, the key to success in the sales phase is to back up everything you said thus far and then surpass it. If a potential employer is talking to you, it’s because he is interested what you said thus far and wants to hear more. Specifically they have two questions they want answered:

1. Do you really live up to your “hype”? i.e. What you claimed as part of your marketing.
2. Do you meet all the unwritten requirements?

Most interviewers suck at interviewing, I mean they just really stink at it. By that I mean they simply have no clue as to what they are doing. And when I say “Most” I mean “All”. When it comes to interviewing nobody knows what the f* they are doing. They rarely put any effort in choosing the right questions to ask, and don’t spend any time thinking about what they expect to learn about the candidate by asking those question. They will routinely interview 5 people (ask each of them and entirely different set of questions) then pick the “Guy who worked for Google”, even though they build POS Systems because obviously “Google is better at picking good people then we are”. They ask questions about skills that can be learned in less time than it takes to answer the question, Then disqualify the applicant for answering incorrectly (because they failed “the test”, this is a direct result of not thinking about what to ask and why).

Interviews are conducted by people with no training and no (or little) planning. Unfortunately this is just a fact of life; there is not much you can do about it. You are going to interview for jobs, and you will be rejected for no good reasons. Understanding this is critical, accept it as fact; and don’t let it affect your confidence.

The hiring process can be summed up as follows: Phone screen\ interview a bunch of people based off their marketing material, and then go with your Gut. (It’s a well-documented fact that employers will choose drinking buddies over talent). As flawed as this process is, it actually works surprisingly well.

Getting back to the two questions: Question one is an honesty check asking “Is this person lying?”. For question two, the interviewer doesn’t even know what the unwritten requirements are, and isn’t even conscious he is asking himself this question. These two may look like different things but they are not, simply stated likeability is the single most important unwritten requirement. If the interviewers like you, and clearly see that you meet all the written and unwritten requirements, you will get the Job (because their Gut will tell them that you are the right person for the job). Nobody likes a liar and nobody hires people they don’t like. Well most people don’t like liars…

<StupidStoryAboutIntentionallyHiringALiar>

While working for a professional services consulting firm, I was asked to help out with the technical assessment of a candidate. So I join the VP, practice manager and the candidate in the conference room and told the candidate “I want to get a good understanding of your level of knowledge of the different aspects of product X, so I am going to ask you a whole bunch of questions where you will get things wrong, that’s ok, nobody could know all this, don’t let it throw you off.” Asking him about one particular advanced feature of the product, I asked him “Have you ever configured feature X”, the candidate responded “Many times!” I say “Great, tell me how the feature works”, he then proceeded to give me a very plausible answer, good if I was asking him to design such a feature, yet entirely wrong in terms of how it actually worked, making it clear that he never configure or even used this feature, not once.

After the interview, in discussions with the VP and the practice manager, I expressed by concerns of the candidates ability (and audacity) to lie with such confidence.  To my surprise their reaction was “That’s what consultants do!! He’s a natural!” he was offered the job and accepted. (I eventually became good friends with the candidate as we worked very closely together. He’s a good honest guy overall) this is the kind of thing people talk about when they talk about “Cultural Fit”.  The VP and practice manager simply liked him.

</StupidStoryAboutIntentionallyHiringALiar>

The important thing to remember about unwritten requirements is that just because you may not be asked about them doesn’t mean you won’t be judged on those requirements (Subconsciously by the interview’s gut). If these requirements are not addressed at all, it will count as a strike against you. This is particularly true if another candidate does address them directly, forcing them out of the interviewer’s subconscious.

So what are the Unwritten Requirements?

Here is a list of the most common unwritten requirements:

1. Likeability – Likability, nobody hires people they don’t like
2. Honesty – We already covered why this is so important.
3. Communication Skills – Solid Communication skills are a MUST.
4. Confidence – being confidant demonstrates your ability to do the work. It also goes a long way to likeability.
5. Enthusiasm for the Job – Nobody wants to work with a miserable f*. Also if you like your job you are more likely to stick around a few years
6. Salary– Will you be happy with the salary?
7. Cultural Fit – This is very similar to Likeability, but extends to the working environment. (ie. Structured vs unstructured environments)

The rest of the unwritten requirements vary from job to job, you should be able to figure most of them out when you are analyzing the requirements to put together your elevator pitch (See Part II), the rest you’ll have to figure out along the way.

Make first (direct) contact.\Recruiters\HR

First direct contact is really a transition phase between Marketing and Sales, I discussed most of what you need to know previously. Everything previously stated stills hold true: you have 3 basic goals: (See Parts I & II)

1. Learn more about the position
2. Pitch your elevator pitch
3. Discuss next steps.

If you are dealing with a Recruiter

Dealing with recruiters is a marketing activity; treat it as such, that means you need to focus on efficiency. Never go out of your way to meet a recruiter in person. If they insist, offer a Skype interview, if they turn that down, politely tell them you just don’t have the time, and pass on the opportunity. (If they offer to come to you, accept)

If you are dealing with HR

Remember your 3 basic Goals; this should get you a phone screen with the hiring manager. Send a thank you letter to HR personal after speaking with them.

The Phone Screen

The phone screen is conducted by the hiring manager or a member of his\her team. This is the true start of the sales process. Insist on a phone screen even if you are offered an in person interview off the bat. (Say something like “Would it be possible to have a brief conversation with the hiring manager prior to coming in? I think that will go a long way in making the in person interview more productive.” – I have never had someone say “No” to this.) The Phone screens serve two purposes:

1. Confirm what you heard from the recruiter and \or HR, and determine if you are still interested
2. Prime the Interviewer for the in person interview

Get Confirmation of the details: The recruiter’s and HR’s goal is to get the position filled. The hiring manager’s goal is to get the position filled with a qualified candidate (in terms of written and unwritten requirements). Because qualified is something only the hiring manager cares about, often the Recruiter and HR “fudge” things to get you more interested. For example recruiters will tell you there is tremendous room for growth, or lie about travel requirements thereby increasing your Enthusiasm for the Job (an unwritten requirement) this is the time to set the record straight.Remember you are screening them too, if you are not happy with what you are hearing don’t waste your time with an in person interview.

Priming: The fact of the matter is that external forces effect how people think of you. If you are being interviewed 20 min after the interviewer got a raise, he\she will be in a good mood, and that good feeling will be somewhat transferred to you. If the interviewer just got reamed out by his\her boss because the server crashed and now the interviewer has to waste 20 min talking to “another looser candidate” you haven’t got a shot in hell of landing that job.

By priming the interviewer during the phone screen you are taking control of the interviewer’s first impression of you. He\she can’t see you so all his\her superficial biases are out, and he\she is left with nothing to judge you on except for content under your control (Assuming you don’t have a heavy accent).  Now that you control the picture, you can push the messages you want to get through: you have the expertise and experience they are looking for (your elevator pitch), and you are a great person to work with (your likability). You want to leave them excited about your candidacy and looking forward to meeting you in person. (Priming goes a long way in effecting someone’s Gut feelings toward you)

While on the subject of priming and likeability, here’s a Random tip: : Lighten the mood from hello, and keep the energy level up. Because of basic phone protocol, 98% of phone interviews start with “How are you doing?” This is great chance to lighten the mood, answer with “Great!” followed by some silly anecdote explaining the “Greatness of the day”, that gets the interviewer smiling. Score #1 on the likability scale plus puts the interviewer in a happy mind set.

Send a thank you letter after the Phone Screen.

The in Person Interview

If you did your job right during the phone screen they should be excited to meet you in person.

Here are my best Interviewing Tips: (Many of these also apply to the Phone Screen)

1. Dress Like an Oracle DBA – (Unfortunately some people still don’t get this)
2. The night before, review the requirements and all your notes, go through each and every requirement and think about how you experience can be transferred to meet that requirement. Research the company’s and understand their business model. that the Take your Elevator Pitch expand that out into a comprehensive Pitch covering every single written and unwritten requirement. If you don’t have a solid answer to how your experience relates to a requirement you had advanced notice of, shame on you, there is no excuse for this.
3. Know who you will be interviewing with : Research them (Check LinkedIn and Google them). Know their role in the company. That will tell you who are the real the decision makers are. It will also tell you who cares about which requirements. (I.e. The technical people will be judging your technical skill, Business people what to know that you understand the industry and that you are someone the can work with. Your would me manager wants to know the he can put you in front of a business user\client without having to worry you embarrassing him)
4. Build a Targeted story: At some time during the interview you will be asked to “Tell us about yourself”, be prepared for this, you should be able to start at the bottom of your resume and tell the story of your career, at each stop along the way (Every job change, every role change, every promotion) tell how you grew as a professional better preparing you for the job you are currently interviewing for.  For every position you should explain how that experience relates to the job you are applying for. (targeting specific written and unwritten requirements, the full bullet list created as part of your marketing strategy will come in handy here)        
5. Bring Print outs of everything.
   
   • The job ad
   • The cover letter you sent
   • Copies of your resume on resume paper
   • A copy of the Email that has the interview location and time
6. Arrive early, stop at a Cafe and review the requirements and your pitch, make sure you can pronounce everyones names, use the bathroom, chew some gum, and relax your nerves. Arrive at the interview location 5-10 min early.
7. Let them talk first, again tweak your pitch, if necessary
   • Start high level and go into details when asked.
   • Details are the key to believability and they show your breath of knowledge. This is how you showcase what you can do for them
   • Ask question that demonstrate your understand the business they are in, and that you know what they are looking.
8. Reinforce likeability
• Smile and joke a bit, mock there procedures if you can pull it off!
9. Ooze confidence, borderline cocky. This demonstrates talent and adds likability.
10. Communicate clearly. If needed ask for a few moments “To find the right words” (Avoid thinking sounds, “umm”, “err”, “uhh”, “Like, you know”.. it’s better to pause silently, this takes some practice)
11. Focus on the written (core) requirements but also remember the unwritten requirements
12. Think about the intent of every question; ask yourself “what are they really asking here”?
    • Answer both the question and the Intent, if you don’t know, ask what the intent is.
    • If you answer only the intent you look like a Politician avoiding the question, also you may be wrong about the questions intent.
    • Example: if the interviewer is asking “At your last job did you use Erwin?” The interview is really asking “We use Erwin here, how comfortable are you with it?” – Infer your experience (SPIN Selling) Remember your Bullet List! (Again see Part II.)
13. Understand the Difference between Elimination Questions & Qualifying Questions
    i. Elimination Questions – The sole purpose of these is to eliminate you as a candidate.
    • Answer briefly, details can only hurt you.
    • Example: “Why did you leave your last job?”
    • Most technical questions are Elimination questions. All “Have you ever” Type questions are Elimination questions
    ii.      Qualifying questions
    • Here details are your Friend! Remember- Details are the key to believability and they show your breath of knowledge. This is how you showcase what you can do for them.
    • All “Have would you” Type questions are Qualifying questions
14. Watch out for Trap Questions – These questions leave you with no clue as to what is the “Right” answer, the key here is to identify the intent of the question and then infer your experience. (Again see Part II!)
    • Example “What Methodology did you use on your last project?” –Correct Answer “We use Methodology Y, What do you use here?” – “We use X”, – “We Considered Methodology X but it wasn’t the right fit for us because of ABC, Methodology Y fit better because of XYZ. I did use Methodology X a few years back when I was …” – Trap avoided, and you get to showcase you knowledge of different methodologies!!
15. Wrap it up!
    • Ask for the Job! – Express Interest
    • Reiterate why you feel you are a strong candidate – remember your elevator pitch!
    • Thank them
16. Ask about Concerns – Toward the end of the interview ask “Do you have any concerns about my Candidacy?”, This gives you an opportunity to address those concerns directly, plus this info is invaluable during your postmortem analysis. (If you don’t get this info during the interview, you will never get it.)
17. Ask about Next steps
18. Send a thank you letter

If you are unemployed

There is a horrible trend now days, where employers think that if you are unemployed you must be an untalented lousy employee. This has gotten so bad that here in NYC a law was passed making it illegal to reject a candidate because he\she is unemployed. Studies have shown that employers are more likely to hold long term unemployment against you then they would a criminal record. I hate to say it, but I think IT shops are the worst offenders. This is a despicable practice and truth be told employment status does not gauge talent or work ethic in any way. Because of this, if you are recently unemployed and it is feasible I recommend you lie about being unemployed. I know I’m going to take flak for this, I don’t care; I think lying is justified in this case.

The Offer

Congratulations! If you did a proper job qualifying the lead the offer should be in the ball park of what you expected. If it’s not, you need to reevaluate your lead qualification process.

Negotiation

See: Managing your Career in IT

Postmortem

As I stated above you will not be offered every job you interview for. That’s ok, the key is to understand why, learn from your mistakes and adjust. This holds true for just about everything in life.

Recommended Reading
The Hoboken Chicken Emergency

As a veteran of applet development (see credentials below), I think it is high time to make a call that teachers should stop teaching applets in general, & especially AWT based applets. Applets are an advanced and specialized type of app. that has little place in the real world around us (most things that are done by applets can instead be better achieved using Javascript and HTML 5).

It saddens me to see new students ‘tossed in at the deep end’ to learn how to make an applet.

The reasons are multiple, but first, I’ll look a little at the history of applets and why applets were ever considered a good idea for teaching small, simple projects.

Applet vs. Frame

The simplest applet is:

import java.applet.Applet;
import java.awt.Label;

public class HelloWorldApplet extends Applet {

  @Override
  public void init() {
    add(new Label("Hello World!"));
  }
}

Looks simple, right? This hints at the primary reason that applets were taught.

It only takes a handful of code lines to see the end result.

But an applet gets a size & position on screen from the HTML that loads it. So an applet also requires a little HTML E.G.

<html>
<body>
<applet 
  code=HelloWorldApplet
  width=400
  height=200>
</applet>
</body>
</html>

This makes the total for a working applet 17 LOC. Not looking quite so simple now. Worse, many developers think ‘any old mark-up will do’ when that is very much not the case. Missing opening or closing elements make the HTML invalid and how a browser will interpret it is anyone’s guess.

Compare that to an application that behaves in as smooth a manner:

import java.awt.Label;
import java.awt.Frame;


public class HelloWorldApplication  {

public static void main(String[] args) {
    Frame f = new Frame();
    f.add(new Label("Hello World!"));
    f.pack();
    f.setVisible(true);
  }
}

So, while it takes just 9 lines of code for the simplest of applets (even including the @Override notation), while 12 LOC for the application doing the same thing, add the HTML and it becomes 17 lines for applet/HTML vs. just 12 LOC for the application.

AWT vs Swing

Time moves on, and the Swing component toolkit was introduced as a replacement for AWT. Nobody uses AWT anymore. Most Java GUI developers started using Swing, and those that have used AWT have largely forgotten the finer details.

This is relevant to the student in terms of getting help when they get stuck. It does not matter who we are, when approaching new areas of CS, we all tend to reach for whatever resources might help us understand the new technology. For a student the best resources are firstly the text books and class notes, but those typically only go so far at explaining, and the rest is from things like the JavaDocs, the Java Tutorial, searching the net, or asking for clarification on forums.

Those last two are particularly relevant in that:

• There is a slew of extremely poor AWT based code available on the net.
• There may also be some poor Swing based code out there, but usually there is a Swing programmer nearby that can point out the deficiencies in it.

Industry uses Swing and that is all that Swing programmers know and remember. AWT is obsolete, and a dead end in career or learning.

So let’s now look at the proper way to write a Swing applet & application. The Java Tutorial warns us that all Swing code should be started and updated on the Event Dispatch Thread, which (ironically) is an AWT based Thread.

A simple Swing applet might then be:

import javax.swing.JApplet;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import java.lang.reflect.InvocationTargetException;


public class HelloWorldApplet extends JApplet {

@Override
  public void init() {

@Override
Runnable r = new Runnable() {
  public void run() {
    add(new JLabel("Hello World!"));
  }
};
try {
  SwingUtilities.invokeAndWait(r);
} catch(InterruptedException ie) {
  ie.printStackTrace();
} catch (InvocationTargetException ite) {
  ite.printStackTrace();
}


}
}

This is slightly verbose (25 LOC) for strict clarity, but could be reduced to:

import javax.swing.*;


public class HelloWorldApplet extends JApplet {

@Override
  public void init() {
    Runnable r = new Runnable() {

  @Override
  public void run() {
    add(new JLabel("Hello World!"));
  }
};
try {
  SwingUtilities.invokeAndWait(r);
} catch(Exception e) {
  e.printStackTrace();
}


}
}

It could be further shortened (from 20 LOC) by declaring the Runnable inside the SwingUtilities method call, but I find that notation to be confusing & prefer to separate the Runnable into a clearly defined instance.

And now the Swing equivalent application, using the same ‘short guidelines’.

import javax.swing.*;


public class HelloWorldApplication {

public static void main(String[] args) {
    Runnable r = new Runnable() {

  @Override
  public void run() {
    JFrame f = new JFrame();
    f.add(new JLabel("Hello World!"));
    f.pack();
    f.setVisible(true);
  }
};
SwingUtilities.invokeLater(r);


}
}

Just 18 LOC in total.

Not very much coding to see our simple message on screen, in a free floating Swing component.

Embedded vs. not embedded

Security

Why won’t the applet load my input file?

By default, Java applets run in a security sand-box that prohibits many actions which might be damaging to other applets, the browser or the user’s machine.

While the security sand-box is of great benefit to end-users, it makes the life of the developer difficult. And it has just become that much more difficult in Java 7 update 21.

In Java 7 Update 21 Security Improvements in Detail Markus Eisele notes:

With the introduced changes it is most likely that no end-user is able to run your application when they are either self-signed or unsigned.

While that warning is a little extreme, I agree with the underlying point being made. A user (or in this case you, the teacher) will need to OK some very scary dialogs, and possibly lower the default Java security to an unsafe level, before being able to view an applet.

Error reporting

My applet is broken but shows no errors! Where are they?

The System.err stream used for displaying stack traces appears on the command line (or in the IDE) when running an application. When a stack trace occurs in an applet it is sent to the Java Console, which is (by default) not configured to be shown.

Class caching

I changed my applet but the browser shows the same!

Many times I have responded to applet problems where the questioner swears they have changed the code & recompiled it, yet the browser is still showing the old values. The solution is relatively simple when you know how – flush the class cache from the Java Console. To someone learning, it is typically a complete mystery.

Embedded conclusion

Those 3 problems alone have probably earned me a quarter of the reputation points I’ve so far gained for applets on Stack Overflow. They pose huge problems when developing and debugging applets.

Conclusion

The question really comes down to:

Are you teaching Java/CS or how to deploy applets?

If the former, use JFrame based applications and side-step all the problems that are inherent to an embedded app. And don’t even consider teaching AWT components – they are obsolete & Swing takes only a few more LOC to get something on-screen.

Author Credentials

So who am I?

• Top ranked provider of answers on Stack Overflow for the applet tag.
• The developer of Appleteer.
• Host of many applets on my site.

So you’ve been working as a programmer for a couple of years, and you want to become a good programmer. But not just a good programmer, you want to be a GREAT programmer. You want to paint with ALL the colors. Hell, you want to paint with all the dimensions. You want to be the GURU of programming – not just some nerd that’s stuck in corner that knows every namespace in the .NET API and can punch out a website in a day – you want to be a Michelangelo. A Picasso. Programming isn’t a science, it’s an art. You want to be respected.

Boy that’s a big ask.

So how do you get started?

By now you’ve hopefully realized that what makes good programmers great isn’t necessarily their technical skills. Your technical skills can be AWESOME, but if you don’t know what your customer wants, they amount to diddly squat. Of course if you know what your customer wants but don’t have the technical skills to back it up, you’re also up the creek. So what are the technical things you want to learn?

* How to write “DRY” code. DRY stands for “Don’t Repeat Yourself”. Copy and paste coders are not real coders. If you find yourself writing the same (or similar enough) lines of code more than once, it needs to be cleaned up so that you don’t have duplicate code all over the place. This will actually keep your codebase smaller, easier to maintain and reduce your bug count. People call this refactoring and it’s a daily part of our job. It’s not an optional extra for the end of a project.

* How to keep it simple. Once you’ve got the hang of refactoring and cleaning up your code as you go, you’re going to have to learn the next principle of keeping it simple. Too often once programmers have got it into their head that they need to not repeat themselves, EVER, and so many code bases grow to be an abstracted monstrosity. I’ve seen huge heaving code bases that take minutes to compile, but the application itself hardly does anything. Keeping things simple above all else is your goal.

* Learn the principle of YAGNI. You Ain’t Gonna Need It. All too often as programmers we want to make sure that we cover all our bases. The customer has asked that the application is to do X. If that’s the case, then they’ll probably want it to do Y and Z too. We might as well spend another 3 days putting that in, after all they’re going to ask for it anyway. Once again, you end up with a much bigger codebase and app than you need, and half of the code in there isn’t being used. Keep it simple!

This can be a very difficult concept to master. Making your solution flexible, customisable and forseeing future requirements is a very important part of our job. This is where I think that programming can be shown to be an art – there’s no hard and fast rule here. Ultimately it’s up to the programmer(s) discretion over how flexible a solution is – it involves constant judgement calls and a weighing up of the pros and cons. Normally the questions that you want to ask yourself are:

“How much extra work will it be to make this more flexible?” vs

“How much time do we have?” vs

“Will they really need it?” vs

“is this making the code worse or better?”

These kind of questions are very difficult to answer on your own. Two heads are so much better than one! Often just talking through the problem and the solution with another guy can help you work out the right approach yourself. Even picking up the phone to call another programmer to see what they think can save you a lot of pain.

* How to constructively review other people’s code. Code reviews can send a shiver down the spine of the most experienced programmer. They can be harrowing, aggravating and an ultimate waste of time. They can also be a delight, an opportunity to learn from others and to improve your skills! The most important aspect of code reviews is not what technical details you are looking out for, but the attitude and expectations that people approach the review with. If you’re dying to bag out someone’s code and make them feel bad, if you’re on the witch-hunt to see how many bugs you can find, then you’re going to be in trouble. People will resent these code reviews, nobody will want to help anybody else and most importantly, your code will not get any better!

The approach that you want is for everybody to go in with the mentality that “we’re here to learn from everybody else and to improve the code”.

* Design patterns. Reading the classic book on design patterns can give you a lightbulk moment – “oh, THAT’S how I solve that messy coding problem”. The danger that most people have is overapplying design patterns and you end up with a bigger mess than you started. Once you’ve learnt how to use a hammer everything starts looking like a nail. So don’t overzealously use them for the sake of it.

* Keep up to date with frameworks & libraries. You don’t have to use them, but you need to know what they do and their pro’s & con’s. A great example of this is SignalR – before this came along I would have been adamant that there is just no way that you can easily do realtime notifications within your web application. Turns out that before signalr there were libraries like pubnub who do this kind of thing with ease – but I had no idea! If I hadn’t kept up to date I could have been the one spouting rubbish (well, more often than usual, anyway). Keeping up to date with libraries and frameworks will also show you how if something seems way too hard to do then there’s probably (hopefully) a much easier way of doing things. Don’t write your own service bus layer when there’s MSMQ.

* How to comment your code. If you’re not commenting code then you’re making your life more difficult. When you come back to that function you wrote 6 months ago you’re not going to have a clue why you wrote it in such a convoluted way. Hey, it turns out that you did it that way for a reason! And BTW you shouldn’t simplify this mess because you’ll actually break it!

You also want to learn how to write down that complicated algorithm in a flowchart or just write it out in english. Don’t expect that someone will spend 2 days trying to reverse engineer your code. Don’t expect that people in the business will learn/remember/understand that complicated logic that they asked you to do. You’re going to end up pulling out this flowchart in at least 3 meetings in the future whenever people say “So what happens when x happens and then y?”

* How to write unit tests. Writing tests is a great way to ensure that your code will continue to work, even when some dufus comes along and modifies the database schema without telling you. Okay, well your code definitely won’t work, but now you can catch it the very day that someone renames a column. Instead of catching it three weeks later and finding out that your application hasn’t been calculating numbers properly. You’ll also want to learn what TDD is and see if it’s a good fit for you.

* What dependency injection / IOC is. A contentious argument for sure, but one you want to be well informed of. It’ll also give you a massive leg-up on when you see your first project that uses DI. If you don’t know what’s going on, you’d swear the code is backwards and insideout.

* How continuous integration is your saviour. I can’t imagine working on a project these days without CI. If I didn’t have a build running everytime someone checked in some code I would be quite terrified. It’s your safety net, your progress indicator and your one-click deploy solution all in one.

* Know what’s going on under the hood. For example, calling a web service – what’s it actually doing? If it’s WCF it’s creating a SOAP service call – you should check out the actual data that is sent over the wire sometime. It’s massive. If I hadn’t peeked under the hood I would have had no idea just how much bandwidth it needs. When it comes to programming, nothing just happens magically.

* Learn the gist of quite a few programming languages. You’d be surprised what you can learn from other areas. If you don’t know how simple python is nor how easy a web application is in ruby on rails, then you’re only seeing one side of the coin. If you’re coming in from strictly typed languages then javascript is a bizarre world in itself! I’m a c# developer and I’ve found that java guys think very differently. So do PHP people.

* Peter Rowell has a great post on how to debug. I agree with everything he says – real programmers don’t guess, they debug. If you think or hope something is working, you’re probably wrong. You need to SEE it working and prove that it’s working. I can’t tell you the number of times I’ve looked at code and said “there, that will work” only to run it and see that it doesn’t. Actually while you’re at it, read his other answers. There’s a voice of experience.

* Make fun of the losers. You also need to learn which programming languages you can successfully make fun of without someone actually punching you in the face.

So what about the non technical stuff? These are the hard ones.

* How to justify your project to management. Management will continually conveniently forget what the point of your project is. You need to be able to explain it in 30 seconds, and then if given the opportunity explain it in 360 seconds. How it benefits the business and why. If you can’t articulate it, nobody else will be able to, and pretty soon people will be asking “why is that guy here?”

* How to explain to management what you’re doing and why. This is different to justifying your project. Some bosses like to know what you’re doing every day – when s/he does, you better have a good answer. “Working on code” is not a good answer. “Adding feature X that will solve problem Y” is a much better answer.

* How to clarify and write down what the customers wants (“requirements”). This is an art in and of itself. If you can do this, your programming job will be A BREEZE. You know all those arguments and problems that you had with people outside of IT? They can be resolved by writing down what people say. Write it down in front of them, during the meeting. Learn from technical BA’s – they are a Godsend.

* How to estimate. People will ask you for an estimate, be prepared. If you don’t know what you’re doing, multiply your estimate by three.  This is not to pad it out – this is to make it more accurate.

* How to plan your project. Remember, only 30% of your time on a project should be coding. That’s thirty percent.

* How to differentiate between a bug, an issue and a feature request. They are all different.

* How to direct other programmers without getting up their nose. You also want to know how to motivate them.

* How to get along with other programmers. We’re a strange breed. Getting along with us can be a challenge – you’re going to have to learn some ninja skills. I can recommend “how to make friends and influence people” by Dale Carnegie. A classic.

* How to work with maniacs, psychopaths and just plain crazy people. There’s a lot of them out there. You’re probably one of them yourself.

Phew.

So what’s the most important thing to learn?

How to GET STUFF DONE. All the theory in the world won’t help you if you can’t get stuff done. Everything above is a waste of time if you’re not getting stuff done. Can this be taught? There’s an interesting question.

Well, not yet, but possibly.

There’s a dispute going on between the Python Software Foundation (PSF) and a UK company over the name Python. A loss for the PSF could mean that they are no longer able to use the name Python within the borders of the EU.

The chairman of the PSF, Van Lindberg, posted a “call to arms” last Thursday on the PSF blog about the trademark issues:

For anyone who works in a company that has an office in a EU Community member state, we need your help. There is a company in the UK that is trying to trademark the use of the term “Python” for all software, services, servers… pretty much anything having to do with a computer. Specifically, it is the company that got a hold on the python.co.uk domain 13 years ago.

The company is POBox Hosting, formally Veber, an ISP based in the UK specialising in dedicated hosting. The Guardian newspaper quotes the managing director of Our Holdings (apparently another name associated with the company)  as saying

… that the PSF had dragged its feet after he had been in touch with it last year about applying for a trademark on python.co.uk’s logo – which also necessitates seeking a trademark on some uses of the name. “We were talking to them but they didn’t get back to us so we filed for the trademark. And now, with 14 days remaining, the PSF has got back to me at 5.30pm on a Friday.”

According to the European trademark database POBox Hosting registered the trademark in April 2012; the status of the application is now “opposed” since the PSF filed a separate trademark application on the 6th February this year. As with everything, it’s not that simple. The PSF needs help in opposing this application; they need evidence that they have more right to the name “Python” than POBox Hosting.

What is easy is what you can do to help. Van Lindberg writes (emphasis mine) that

[a]ccording to our London counsel, some of the best pieces of evidence we can submit to the European trademark office are official letters from well-known companies “using PYTHON branded software in various member states of the EU” so that we can “obtain independent witness statements from them attesting to the trade origin significance of the PYTHON mark in connection with the software and related goods/services.” We also need evidence of use throughout the EU.

If your company uses Python and has an office or hires in the EU, whether you’re in Austria or the UK, Malta or Germany, you can do something to help. Van Lindberg asks

Could you write a letter on company letterhead that we can forward to our EU counsel?

1. just a brief description of how Python is used at your company,
2. how your company looks for and recognizes “Python” as only coming from the PSF, and
3. your view that another company using term Python to refer to services, software, and servers would be confusing

This doesn’t need to be long – just a couple of paragraphs, but we would want any description of how you use Python for software, web hosting, Internet servers, VPNs, design and development of computer hardware or software, hosting websites, renting servers (like Openstack), or backup services.

Alternatively do you have, or know of, anything published within the EU that uses “Python” to refer to Python? Can you provide copies, pictures or scans of books, pamphlets, conference programs or talks, job listings, magazines or other publications or prospectuses.

All the above should be sent in PDFs to psf-trademarks@python.org

Predictably, and understandably, they’re also asking for money and ask that you consider donating to the Python Software Foundation at http://www.python.org/psf/donations/

One last point. The Guardian also reported that:

Poultney said that the issue… had led to him receiving death threats and that the python.co.uk website was receiving 250 hits per minute.

This was followed up by Brian Curtin in another PSF blog post

… it has come to our attention that the organization with which we are currently involved in a trademark dispute has been receiving messages from our community members, including threats. We ask that no matter who you support in this matter, that you remain civil in your communications and actions. It is important that we maintain the positive and friendly atmosphere that Python is known for regardless of the situation at hand.

Civility harms no one and threats and crashing the companies website could actively work against the PSF. Far more important is to get writing something relevant and useful to support Pythons everywhere.

Full details are available on the PSF blog post.

Note: This is Part II of a three part series; it is recommended that you read Part I – The Basics first. 

A quick Re-cap I previously defined the Job search Marketing phase as “Finding and Advertising yourself to potential employers”. This is everything you do up until you get a person on the phone discussing a specific opportunity. Also previously stated is that the Marketing process looks something like this:

Marketing

1. Look for Markets – i.e. Research where (what roles\position\industries) that there are good opportunities for your skill set and will position you for growth
2. Generate Leads based on your research
3. Qualify your Leads
4. Market to your Leads – By sending a targeted Cover Letter & Resume
5. Get Responses
6. Qualify Responses
7. Postmortem

Confession: For a few years after I graduated college, I was a Cockroach. I had a solid resume for a Classic ASP Developer with SQL Server (What more could you need?!). I had a Basic cover letter (“I would like to apply for your Dev position listed in the NYT…”). I had Word Mail merge and a Fax Modem. I’d go through the Sunday paper, queue up my Faxer-Spam-A-Bot-umus, then bask in the glory of a full answering machine upon my return from work the next day.

After the Dot-Com Bust everything was online and there where oodles more Cockroaches to compete with (Mass emailing is massively easier than mass faxing). The going advice amongst the pros was that Cockroaches are bad, you need to be a Monkey. This didn’t sit well with me at all. How could I spend all that time customizing each resume I sent out? With each resume so customized, each was sure to have a few typos! I’d likely get disqualified on that alone, besides how long is the hiring manger going to spend looking at my resume? With so many Cockroaches out there I’d be lucky if my resume even gets looked at, and then I would likely only get a 15 second scan. It just didn’t seem right (or fair) to spend 2 hours of work (per job application) for that. Needless to say, that was not a fun job search…. I eventually joined a friend’s venture as a semi-partner, thinking I would do that until the job market picked up.

5 years later, I was ready to go on the hunt again, but I knew my Cockroach strategy was a failure. I needed to be a Monkey, but if I was going to be a Monkey I was going to be a Highly Efficient Monkey. I needed to optimize every part of my job search so I could apply to a large number of jobs that I actually want; I needed to be able to do that with no typos. The remainder of this article will focus on the different phases of marketing (see above) and how to do each in an efficient and effective manner. This is not a single linear process: you should be doing many of these in parallel, every day you should be searching the job boards, and you should be returning phone calls every day.

Disclaimer: All of the below is based on my personal experiences job searching in the NYC job market, this is in no way meant to be a one size fits all. You should test out these techniques, as well as others, and do what works best for you.

Look for Markets The key here is to research what roles\position\industries exist that there are good opportunities for your skill set and will position you for growth, these are the jobs you want. This process should be an ongoing process, you should decide what you want to do next, and then develop the skills you need (See Managing your Career in IT). If you didn’t do this and you find your self unemployed. You have no choice but to evaluate your skills, then look for markets where they are suitable.

Doing this is fairly straight forward, browse the Job boards looking at the types of jobs you want and make note of the skills you see coming up over and over again. (This is a great way of determining the marketability of a skill in a particular location, just search the Jobs boards and see how many come up! It’s not perfect but it works).

If you come across a skill you never heard of, look it up. GlassDoor.com is great for checking what particular roles tend to pay. You should always be looking for new markets even you are not conducting a job search.

Generate Leads based on your research

Finding potential employers is easy, all you have to do is go to your favorite Jobs search engine and type in a word and click “Search”. (My favorites happen to be Dice, Monster and LinkedIn).  Most sites have “Jobs Agents”, these will run a set of saved searches for you every day and email you the new listings for each agent. Jobs Agents are an unbelievable time saver, use them.

Making your resume searchable on job boards is common; I personally like the idea, though many people advise against it. If you do this, I recommend adding a “White List” stuffed with keywords to your resume (In a white tiny font so computers can see it but not people, think of it like Job Board SEO). This is a somewhat controversial idea, as many people believe it to be dishonest. In IT with so many acronyms and different terms that mean the same things, I feel this is a valid way to list all the different versions and acronyms that would look funny if you already mentioned them in a different way.

Qualify your Leads

You want to quickly scan each of your search results and only apply to the jobs you a) Want and B) Have a reasonable level of qualification. I briefly discussed this as a response to this now closed question. What I stated there still holds true. Scan the job posting much like the hiring manager will scan your resume. Look at the following and make a snap decision if you want to apply.

For me, the Quick Scan includes (You scan should include what you see as deal breakers.)

1. Job title
2. Pay Rate (Often not listed)
3. Location
4. Employment Type (Permor Contract, Contact length)
5. Requirements List \ Tech Used.
6. Then I start reading the Body.

The last thing you want to consider is the time it will take to apply: many companies\recruiters want you to reenter all your data into their proprietary system. Keep in mind that anything you enter there is going to be in that system till the end of time, and maybe used against you the next time you apply (if they see info that is inconsistent across applications). Any application that asks me to do more work, (e.g. retype my resume into a form) will also make me less likely to apply.

Market to your Leads – By sending a Targeted Cover Letter & Resume

For Monkeys this is, by far, the most time consuming part of the process; particularly if you are applying to a large number of jobs. The good news is that this is also the place where you will get the most gains in terms of efficiency. Before you apply, develop a basic “Elevator Pitch” for this particular Role. Put yourself in the employer’s shoes and ask yourself “What am I really looking for here?”. You should be able to define the job requirement in no more then 3 or 4 sentences. Everything else in the Job description is Fluff. Next, you need to develop a sales pitch that directly answers that description. This answer is your “Elevator Pitch”: it’s short, it’s to the point, and most importantly, it’s easy to remember.  This “Elevator Pitch” will stick with you through the rest of the process with regard to this particular job listing.

Suppose you read a job listing and you summarize it down to: They are looking for a Tech-Lead with 5-7 years of e-commerce experience within the high fashion industry. They use the LAMP stack and really need someone who can lead their team to success. (Note: they may not have used the words Tech-Lead or e-commerce in the job description; you need to read between the lines) ¹

Your “Elevator Pitch” should be something like this: I have been working for the past 5 years with the LAMP and the last 2 as a Tech Lead, including the roll-out of an e-commerce site for a small kid’s apparel company.

Note that you don’t have the high fashion experience; you are going to need to explain that Kid’s apparel is close enough. This is just one example; you will need to do this sort of thing constantly. You must understand how your skills can be used, and more importantly how to explain the transfer-ability of those skills (to the skills your potential employer is looking for) in such a way that the gate keeper can effectively sell you to the decision maker. Your “Elevator Pitch” must be so simple that the HR drone or the recruiter can sell it effectively to the real decision maker.

Also note that your “elevator pitch” never said you used LAMP for e-commerce, that’s because you didn’t. You don’t need to highlight this, but if asked answer honestly, “It was not LAMP, it was package X, Everything I learned about e-commence rolling out that system will be invaluable should I be given this opportunity, I am confidant that I can repeat the success with LAMP”

This “Elevator Pitch” will be at the center of all your correspondence up with the Recruiter\Co until mid-way through the first in person interview.

The Cover Letter

The purpose of the cover letter is to do 3 things:

1. Introduce yourself and formally apply for the position
2. Explain why you are the perfect candidate, using your elevator pitch.
3. Express your enthusiasm for the job

And that is exactly what my cover letter looks like. A two sentence opening paragraph along the lines of “Please accept my application for the XXXXX position, I feel I am an excellent candidate for it because:”. I then have a list of reasons in bullet form, highlighting the key points of my elevator pitch. I then have a closing paragraph saying: I’m very excited and interested in this opportunity, thank you for considering me.

Clearly, the Bullet list is the core of your letter. Bullets are easier to read then paragraphs and more likely to resonate with the reader. The first few times you do this, it will be very time consuming. The key is to keep every bullet you write archived for later (re)use. After a while, you will have your cover letter template and a list of 30-40 bullets that you have written over time covering just about every single one of your selling points. Then, when applying for jobs in the future you can quickly assemble your cover letter by selecting the bullets that match your elevator pitch on a job by job basis. Each bullet should reference a specific job or project so the reader can easily find the details on your resume.

For the example above, your bullets would look something like this:

• 8 years overall experience working as a Business Analyst and Web Developer, Including 5 Years working with LAMP, JavaScript & jQuery.
• Proven Track Record Rolling out E-Commerce sites within the Apparel Industry, While at Kids-Yellow Corp, I successfully led the development and roll out of their E-commerce site fully integrated with inventory and order processing systems. The System was built to be scalable and is responsible for 35% of company sales, bringing in $35m annually. I am currently working as the tech lead rolling out the Mobile version of that same E-commerce site.
• Solid Understanding of SEO and Web Marketing, Worked closely with the Kids-Yellow Marketing team to ensure all web marketing activities are tracked and related back to E-commerce site visits and sales, allowing for internal analysis of marketing ROI.
• Certified MySql Developer

From the reader’s perspective, it’s clear you read the job’s description and know what they are looking for. It’s clear you have the skills they are looking for (or at least, why you think you do). It’s clear that you have some level of communication skills, and lastly there are no typos, because there is no original content. Also, notice how easy this makes it for the HR drone\recruiter to pitch you to the hiring manager.

While on the subject of Typos, here’s a Random Proofreading tip: Use Speech to Text software to proof all your correspondence by listening to it, grammar errors have a way of standing out when you hear them.

One last thing on cover letters, if you really want a particular job and you really feel you are the prefect candidate for it, include a sentence stating “I will follow up with a phone call later today”, and then do just that.

The Resume

You should have a separate resume for each role you are looking for, (So if you’re a looking for a Lead Dev role or a PM Role you should have 2 resumes). If you resume is well done, you shouldn’t have to customize it for each job you apply. That being said it doesn’t hurt to move bullets around if a particular listing really wants a skill that you have hidden.

There are whole books on the subject of resume writing, it really is an art. The key thing is that you need to be constantly working on it, and fine tuning it. That being said, my resume is laid out as follows: (Everything in Bullets, needless to say I prefer the classic chronological resume)

1. Name & Contact info, Including LinkedIn URL
2. Professional Profile – A bullet point list of who I am professionally, a high level overview. If someone read my whole resume, and had to describe me to someone else. This is what they would say.
3. Professional History, ordered chronologically with the latest first, I list the company, job title (if your job title is not very descriptive feel free to use a functional job title), accomplishments, responsibilities, methodologies & tech used, ect.
4. Education & Certifications
5. General Tech section – a list of Languages, Databases and Operating systems
6. Appendices with project level info – Because for most of my history I have worked within the professional services, I use Appendices to discuss in detail specific project details, I often swap out appendices based on the job I am applying to. I find this is a great reference when discussing my work history with a potential employer. I also include my white list as an appendix, so if someone does find it, it doesn’t look out of place.

Get & Qualify Your Responses

If you have a reasonably marketable skill set and do the above you will get responses, but you still have to manage them well. Here are a few pointers:

1. Have a dedicated Email address just for your job search. Preferably YourName@???.com. Once you job search is done, this account will get spammed for years.  This way you have established a quarantine.
2. Have a dedicated phone number for your job search. I recommend Google Voice.
3. NEVERever pick up this phone unless you are expecting a scheduled call; always let it go to voice mail.
4. Before calling a lead back, review the original job posting (most job boards track the jobs you have applied for, and you can review them at any time), visit the companies’s website, review the cover letter you sent them, remind yourself of your elevator pitch for this lead (adjust if necessary). If this is a direct hire (not a recruiter) and the salary is not listed in the ad, check GlassDoor.com. If you have any other questions make note of them, and keep your paper and pen handy. Now you are ready to call them back. Nothing is worse then taking a call for a job you don’t remember applying to; you can kiss that opportunity good by. I learned this the hard way.
5. On this first call back, you have 3 basic goals: learn more about the position, pitch your elevator pitch and discuss next steps. Let them speak first, let them tell you about the position. What they say should match the mental summary you made when you first read the job description, make note of the differences and modify your elevator pitch on the fly. Once it’s your turn to speak, if you are still interested blow them away by going through each of there requirements and knocking them down one by one (just like you did in your cover letter). Speak with confidence, show your excitement and personality. Finish by telling them “I think this is a great fit and great opportunity”, ask if they have any further questions and what are the next steps. (Next Steps are part of the Sales Process and will be the focus of Part III of this series)
6. If you are no longer interested, thank them for there time and for thinking of you. Ask them to feel free to call you again should another opportunity come their way that may be a better match.
7. At some point during this initial call, ask them the salary range. If they won’t tell you (or give you some crap about it being wide open contingent on experience) be insistent that they let you know before you go in for an in person interview, tell them “It’s to our mutual benefit to know we are on the same page and that you are just asking for a broad range, not an exact number”. The common advice is to never bring up salary until you have an offer. I adamantly disagree with this, more likely than not, a company that refuses to discus salary early on pays below market level and you are wasting your time talking to them. If push comes to shove tell then what you are looking for and ask them if that is within the range.

Postmortem

SPIN Selling

Hey all! Today is our second anniversary since graduation, Happy Birthday!

No, I don’t have any cake for you, I think by now, we all know the cake is a lie. Instead, I’ve a not-that-long blog post, summarizing all the awesome things that happened this year. We’ve certainly come a long way since our humble beginnings, the community is stronger than ever and the site has been steadily growing for quite some time now.

So, without further ado, here’s what’s been going on this past year:

Community Events

Programmers’ second year had some truly exciting moments. First, Anna Lear joined the evil corporate machine and we found ourselves short of a moderator. This prompted our second community moderator election, a process that I was very proud to be part of. The elections run smoothly, with surprisingly little drama and participation, although a bit low, was increased comparing to our first election.

Then, after the dust from the election settled down, we had our first ever contest. An exciting month long event that brought us some awesome questions, and some of the best answers I’ve ever read on the site. You can read more about the contest in this blog post, and it’s never too late for your feedback.

Which, of course, brings us to this very blog. The blog had a rocky start, although it was first proposed in June 2011, we didn’t really seemed to be able to get enough people interested in contributing. We went through various Meta discussions, two calls for contributors, a lot of candidates in the elections commited to make the blog happen, and finally we launched and posted our first blog post almost a year after the blog was first proposed. Kudos to the awesome blog team and everyone else involved for making this happen!

Lastly, starting from late January we undertook the monumental task of cleaning up our most problematic tags. The Structured Tag Cleanup started with the most bothersome of our tags, career and continued with software-engineering and software-development. The clean up effort ended on early April, at which point we’ve gone through 1000+ questions. Those of you who were active at the time may remember that we got at least a couple of blatantly off topic career questions per day, cleaning up 600+ broken windows in the various career related tags took care of that problem almost instantly.

We kick off our third year with the Hat Dash, a network wide event starting on Wednesday, it’s going to be fun!!!

Sister sites

The Stack Exchange network has grown rapidly this past year, right now there are 92 graduate and beta sites and a lot more are very close to popping out of Area51. Here’s a brief list of new technology oriented sister sites that you might find interesting (in no particular order):

• Computer Science
• AskPatents
• ExpressionEngine
• Robotics
• Salesforce
• Raspberry Pi
• Windows Phone

When Computer Science first appeared, a question was asked in our Meta about clarifying the boundaries between the two sites. Inspired by that question, and after a brief discussion with a CS moderator, Raphael, we decided to test those boundaries by re-asking CS’s highest voted algorithmic question on Programmers. The answers the question received on Programmers are surprisingly different than the ones it received on CS, which, at least to me, says that although the sites overlap a bit, they have distinctly different audiences:

• Why is quicksort better than other sorting algorithms in practice? (Programmers version)
• Why is quicksort better than other sorting algorithms in practice? (CS version)

And of course, although not a technology oriented site, The Workplace deserves an honourable mention. The site was initially proposed on Area51 to fill the gap for all those general career related questions we couldn’t really support on Programmers, and it was greeted with enthusiasm from Programmers’ regulars when it finally made it to beta. Even today, 8 months into beta most of the site’s high rep users are also Programmers’ regulars, and all four pro tempore moderators are significant contributors on our site. If you haven’t visited the site already, trust me, it’s awesome!

New features

There have been a ton of new features this year, with two very important changes for Programmers:

• We are no longer a migration target from Stack Overflow, and
• We now require registration for asking questions (but not for answering them).

Network wide the more significant changes were:

• Reputation history changes
• Flag weight was removed from user profiles
• Real time updates to questions, answers, and inbox
• Rejected migrations
• Community review tasks (aka the new review queues)
• Disabling migration for questions older than 60 days

Questions

I wanted to close this with a list of awesome questions from the past year. At first I wanted to bring some new attention to a few hidden gems, showcase posts from less popular tags, blah blah blah, but at the last moment I decided to go simply with the questions with the highest score. It might not be the best metric we have, but it’s the only metric that I felt would adequately represent the wider community. Here they are, our top twenty questions:

• My boss decided to add a “person to blame” field to every bug report. How can I convince him that it’s a bad idea?
• Is the use of “utf8=✓” preferable to “utf8=true”?
• What is the Mars Curiosity Rover’s software built in?
• I’m doing 90% maintenance and 10% development, is this normal?
• I’ve inherited 200K lines of spaghetti code — what now?
• Should I intentionally break the build when a bug is found in production?
• What software programming languages were used by the Soviet Union’s space program?
• Why can’t the IT industry deliver large, faultless projects quickly as in other industries?
• Torvalds’ quote about good programmer
• Should you keep a copy of all the code you write?
• Why is 80 characters the ‘standard’ limit for code width?
• Why was Tanenbaum wrong in the Tanenbaum-Torvalds debates?
• How do I review my own code?
• Why are shortcuts like x += y considered good practice?
• How to keep a big and complex software product maintainable over the years?
• Has “Not everyone can be a programmer” been studied?
• How do operating systems… run… without having an OS to run in?
• Is it just me or is this a baffling tech interview question?
• Is constantly looking for code examples a sign of a bad developer?
• Is the phrase “never reinvent the wheel” suitable for students?

All in all, it’s been an awesome year! Keep on rockin’, Programmers!

Keeping your hands healthy and pain free is something every programmer should be thinking about, minor hand injuries will affect your productivity, a major injury could threaten you livelihood. Hand injury is common problem amongst programmers, so it’s not surprising that the question “How do you keep your hands in good condition?” was asked here on Programmers (though closed as off topic).

Dr. Alan Gotesman an orthopedic surgeon with training in hand, microvascular & upper extremity surgery and friend to the Programmers Community has agreed to answer this question for us.

By: Dr. Alan Gotesman

Repetitive Strain Injuries of the Hand

Prolonged repetitive hand movements, particularly in awkward positions, can lead to strain injuries. It is important to be aware of these injuries and prevent them as well as treat them when appropriate. Some of the conditions may not necessarily be caused by repetitive stress, but many can be aggravated by it.  The following are some of the more common hand conditions encountered by hand surgeons in the setting of repetitive stress.

Carpal Tunnel Syndrome

The carpal tunnel is a narrow, tunnel-like structure in the wrist. The bottom and sides of this tunnel are formed by wrist (carpal) bones. The top of the tunnel is covered by a strong band of connective tissue called the transverse carpal ligament.

The median nerve travels from the forearm into the hand through this tunnel in the wrist. The median nerve controls feeling in the palm side of the thumb, index finger, and long fingers. The nerve also controls the muscles around the base of the thumb. The tendons that bend the fingers and thumb also travel through the carpal tunnel. These tendons are called flexor tendons

Carpal tunnel syndrome occurs when the tissues surrounding the flexor tendons in the wrist swell and put pressure on the median nerve. These tissues are called the synovium. The synovium lubricates the tendons and makes it easier to move the fingers. This swelling of the synovium narrows the confined space of the carpal tunnel, and over time, crowds the nerve. The synovial swelling can be caused or aggravated by repetitive motion. Direct compression of the carpal tunnel as well as extreme positions can also aggravate the condition.

Symptoms of carpal tunnel consist of:

• Numbness, tingling, and pain in the hand
• An electric shock-like feeling mostly in the thumb, index, and long fingers
• Strange sensations and pain traveling up the arm toward the shoulder

Prevention:

Prevention of symptoms should focus on proper hand positioning when performing activities, in particular typing. The wrist should be in a neutral position (not bent up or down) which is best done by a forearm rest. There should also be no direct compression on the wrist which can increase the pressure in the carpal tunnel. Occasionally, braces may be required to rest the wrist and if symptoms become severe enough, surgery may be necessary.

Tendonitis

Tendons are the connection between muscle and bones which allow us to move our joints. The wrist tendons slide through smooth sheaths as they pass by the wrist joint. These tendon sheaths, called the tenosynovium, allow the tendons to glide smoothly in a low-friction manner. When wrist tendonitis becomes a problem, the tendon sheath or tenosynovium, becomes thickened and constricts the gliding motion of the tendons. The inflammation also makes movements of the tendon painful and difficult.

The most common and consistent complaint of patients diagnosed with wrist tendonitis is pain over the area of inflammation. Swelling of the surrounding soft-tissues is also quite common. Repetitive stress can cause tendonitis by putting too much strain on the tendons.

Prevention:

Taking frequent breaks and not putting the wrist/hand in awkward positions can prevent these injuries. If symptoms appear, anti-inflammatories can be helpful as well as short periods of immobilization. Swelling can be brought down with ice and elevation. Cortisone injections can be helpful for symptoms that are not improving and surgery may be necessary if conservative modalities are failing.

Sprains

A sprain is an injury to a joint caused by a tearing/stretching of the ligaments. These are frequently acute injuries caused by trauma, however they can be chronic from repetitive stress across the joint causing stretching. Any joint can be affected, but the thumb can be particularly vulnerable as the ligament is often being stressed with daily activities. The increased frequency of texting, with the thumb primarily being used to depress the keys, has increased the incidence of this problem.

Symptoms consist of discomfort around the joint, particularly with any stress applied. There can be swelling in the area as well as tenderness directly over the affected joint. Extremes of motion can be painful as well.

Prevention:

Repeated stress across the joint, especially in one particular direction, should be avoided. If symptoms appear, alternative positions should be used and if possible, decrease the amount of activity. Custom splints can be helpful to support the particular ligament involved and decrease the stress across it. Anti-inflammatories can alleviate the pain and swelling. Infrequently, if symptoms persist, the ligament may need to be repaired or reconstructed.

Repetitive stress injuries of the hand can be disabling and appropriate measures to prevent them should be instituted. If symptoms persist, they should be evaluated further by a qualified hand surgeon for further treatment.

About The Author

Dr. Alan Gotesman is a board certified orthopedic surgeon with fellowship training in hand, microvascular & upper extremity surgery. He has a special interest in minimally invasive and arthroscopic surgery. He is in private practice in Rockland County.

Alan Gotesman MD
http://www.alangotesmanmd.com
Orangetown Orthopedics
99 Dutch Hill Road
Orangeburg, NY 10962
845-359-1877