ed weissman

I was recently contacted by a head hunter for a job I thought was worth investigating. I wanted to talk to the company directly, but the head hunter made it clear that Step 1 was always a web-based programming aptitude test, no matter who you were. 20 questions. 18 correct was considered passing. They would only talk to candidates who got 19 or 20 correct. 

So I took the test and got 20 correct (as I imagine many would as well). I thought it was very easy. The headhunter later told me that in 9 months, she had sent 52 people to the test, only 2 of us got 19, and I was the only one who got 20. 

I’m not really sure what this means. That there are a lot of posers out there? That she wasn’t very good at screening talent? That the companies seeking the best talent gladly pay $100 50 times to save their time? 

I guess my biggest feeling is one of disappointment. It’s just not that hard to become a good enough programmer to get 20 right every time. All it takes is study, passion, a lot of dedication, and a lot of hard work. I wish more people would do that. There aren’t enough of us. 

The entire test was about a fictitious language, I forget what they named it. Every question built upon the previous. 

The first question was something like, “These are the definitions of variables: A string is… An integer is… A date is…” Then the question would be something like, “What can ‘15232’ be? a. an integer b. a string c. a date d. any of the above e. a and c”. 

Another question might be “Here are the rules of precedence… What is (1 + 2) * (3 + 4) / 3 a. 4 b. 2 c. 7 d. 12 e. Can’t tell for sure.” 

It got more and more complex, all in their own pseudocode. They covered branching, iteration, arithmetic operations, Boolean algebra, etc. Things most people here have seen a million times. Kinda like SATs for programmers. 

“Do you prefer a single page resume or multi-page? If multi, then how many pages of resume you think is good enough to sell you?” 

Single page. If I absolutely, positively have more to say, I occasionally attach a one page Appendix, “Sample of Project Particulars,” which includes 5 or 6 quick stories about major projects I completed that are relevant to the company and position I’m submitting to. 

“Do you elaborate on your work experience (like, job description, responsibilities, etc.) or you want to keep it short?” 

Yes, but I wouldn’t say “elaborate”. More like “itemize”. Forget about things like “experience”, “job description”, or “responsibilities”. Focus on one thing only: results. What I did, who it was for, why they needed it, and what they accomplished with it. “Built an AJAX e-commerce site that enabled a $10 million 

catalog distributor to double sales in 6 months.” This shows that I understand the forest in which I’m planting trees. Short, sweet, and to the point. If it catches their attention, they’ll ask you more about it. If it doesn’t, then you probably don’t want to work for them, anyway. 

“Do you have more than one resume, like a master one with all details and one page resume targeted to a particular position?” 

Just a custom one pager specially made for each company. I show them the same level of special attention that I expect in return. 

“In what order you present information in the resume: Objective, Experience, Skills, Education, Summary?” 

1. Very short summary (with embedded skills) that pretty much says it all, “AJAX programmer, expert level in e-commerce, 100 projects completed, ready for next long term challenge in Big City, USA.” 

2. Applicable accomplishments in reverse chronological sequence. (Emphasis on “accomplishments”.) 

3. Degrees. 

“Do you really think the resume layout matters more than the content itself?” 

No. 

“Which font do you use for your resume? Arial? Verdana? Webdings?”

 Who cares.

 “Do you prefer to maintain an online version of your resume?” 

No. I’ll contact them. I don’t want anyone contacting me.

When I hire, I’m not looking for a person or a resource. I’m looking for a solution to my problem. Sometimes that problem is big, sometimes it’s urgent. But there’s always a problem needing to be solved. The more a candidate looks like a solution to my problem, the closer to the front of the pile he/she gets. 

As far as I’m concerned, the most important thing for any candidate to do is to identify my problem(s) and present themselves as the solution. The problem could be: 

-We just got a bunch of new business and need someone to do immediately to satisfy those customers.

-We just acquired another business and need to convert/integrate from technology to technology and need someone who knows both technologies (or either one) and has done that before. 

- We have a new business problem and one possible solution is to build/enhance/maintain an app. Can you do that? Have you done that? 

- We plan to grow x% over the next 24 months and we need people to do more of what we already do which is <x>. Can you do that? Have you done that? 

- We have a problem and frankly, we’re not sure what to do. What would you suggest? Can you do that? Have you done that before?

 You kinda get the picture. The tricky part for any candidate is the research. How do you find out what my problems are? Ask! Ask me. Ask someone else in the company. Ask anyone. The simple act of research shows that you’re a serious candidate. The follow up with a solution to my problem puts you at the top of my list. 

If you’re right out of school or don’t have a lot of experience, you should still do this. You may not have as long a resume as others, but you have every bit as much to offer to solve my problems. Maybe a smart person who works hard and knows how to deliver is just what I need. You must find that out and present yourself as such. Remember, it’s about my problem, not yours. 

This was I great question. I’ve never seen it before. The fact that you thought enough to ask is a “huge” first step. It shows that you’re thinking about me, not just yourself. Keep thinking like that and there’s no telling how far you’ll get. Thank you and good luck.

“My biggest pet peeve with these types of tests is this: there are a lot of companies out there, and I’m sending out resumes to each one that I can find.” 

That’s your first mistake. 

Why should a company take you seriously if you don’t take them seriously? Every resume you send out should be custom written and carefully crafted to address their requirements, not yours. Do you do any research into the companies you’re applying to? You should. 

Rather than sending out 50 stock resumes, you’d probably be better off picking the top half dozen or so opportunities and do everything you can to stand out. This includes a custom cover letter, follow up emails, thank you notes, etc., whatever it takes to make the connection. 

“I simply do not have the time to write fifteen code samples a day, just because you want to evaluate me against your coding test. Period.” 

There’s your second mistake. Misdirected attitude. Again, you should be focused on their needs, not yours. If you don’t have time to do 15 poorly, then just do one or two very, very well. No employer or recruiter cares that you’ve chosen a shotgun approach. 

Give of yourself without expectations of something in return. You may be surprised at the “unexpected” dividends you’ll reap later. 

For what it’s worth: I have conducted over 2500 technical interviews and every single one of them has had to code, regardless of experience or background. What good is a programmer who doesn’t want to code at the one point when it would provide the most benefit to everyone involved? In my experience, the best programmers were the most eager to give it a shot.

“No, coding on the whiteboard or on paper, or even the 5 minute exercise on the laptop is not really coding.” 

It doesn’t matter whether or not it’s “really coding”. All that matters is how effective it is in evaluating your candidate. 

I have interviewed over 2,500 devloper candidates and every single one has had to code with pencil and paper, in a room alone for 15 to 30 minutes. This has always been, by far, the most effective thing I could have done. 

I never cared what they actually wrote. I never once found out if it would even compile or run. And I never cared. The only purpose of the coding problem was the “discussion afterward”. This told me volumes. 

Given a person, a discussion, a problem, and 1 to 3 pages of written code, I could ask many questions focused on a single issue and take it any direction I wanted. And learn what I needed to know about that person… 

How did they attack the problem? What did they feel comfortable using? How did the deal with the situation? 

What kind of attitude did they have? How much did they enjoy dealing with the problem and discussing it? 

How well did they defend their choices? How willing were they to take criticism? How willing were they to stand up for what they believed in? 

These are the things I want to know now. Not 3 months after they start working. Programming with pencil and paper and discussing afterward is the best way I’ve ever found to find these things out. 

Here’s one of my favorite examples that can work for almost any language. 

Remember, before any of this happens, I have already helped the candidate get comfortable and have made the purpose of the exercise clear: to assess where they’re at and how/where they might fit in. It is not a test. Just an exercise to help us both. I offer them a soda or coffee, a little privacy, and this little problem… 

You have an array. Call it “a” or whatever you want. It has a bunch of elements, numeric, alphanumeric, or whatever. You decide. Sort it. Without using a second array or a pre-existing function or routine. While I’m explaining this I’m sketching it out with my own pencil and paper. I suggest that they sketch out what they want to do themselves and then write some code (in the language being evaluated) or just pseudo code for general purposes. Be prepared to discuss whatever you want to present. Don’t go nuts, just a few pages and 15 to 30 minutes. And have fun. 

When I return, I have them explain how they approached it. (Here’s what my code will do…) Then we go through the code line by line. At this point, it’s incredibly easy for me to ask questions, such as…

Why did you name that variable that name? 

Why did you use a for loop? 

How else could you have done iteration? 

How would you do it with 2 loops? 

How would you do it with 1 loop? 

Which variables are global? Which are local? Why? 

Why did you reuse the variable "i" in the inner loop? (Oops) 

How can you make it faster? 

How could you make it clearer? 

How would you change it if you knew the probability of the original order? 

How would you refactor this? 

How would you extend this to do...? 

Which code would you put in a library for reuse? 

You kinda get the picture. No 2 interviews are the same. Imagine the programmers you already know having this discussion with you and how much you’d learn about them. 

There are no right or wrong answers, just learning. Which is what you want. 

This simple test eliminates the 90% of applicants who are not suited for this work and 100% of the posers. You can tell right away who they are. 

On the other hand, good programmers shine on this. It’s actually fun to hang out and talk about this stuff with them. I’ve even had candidates email me later with revised code based on our discussion. Those are the motivated ones. Big points for that. 

Here is the dirty little secret about evaluating the code you write in the interview: 

What is on the piece of paper (or editor) doesn’t make a whole lot of difference. 

What happens when you and I talk about what you wrote tells me almost everything I need to know. 

Less than one percent of interview code I’ve ever seen even compiled. What I was really looking for was: 

- Did he understand the problem? 

- How did he approach the problem? 

- Does he appear as if he has any idea what he’s doing? 

- Can he explain what he has done? 

- Can he defend what he has done? 

- Does he understand the concepts of order, cleanness, iteration, branching, recursion, etc., etc., etc… 

- Based on this small sample, do I think he can do the work we need done? 

- Do I like him? Will he fit in and be a good team member? 

So assuming they interview like I did (a big assumption), here’s the good news…whether or not you’ll do well has already been determined. So don’t bother to “cram” between now and Tuesday. Relax. And have fun. 

Be yourself and it will all work out OK (one way or the other).