
How To Hire Me (or any other programmer) - softbuilder
http://www.youell.com/matt/writing/?p=898
======
edw519
How to hire me:

    
    
       1. Tell me about the 3 biggest things you must accomplish.
       2. Tell me why you must accomplish them.
       3. Tell me when you must accomplish them by.
       4. Tell me how you intend to accomplish them.
       5. Tell me what you're already doing to accomplish them.
       6. Tell me the role you envision me playing in accomplishing them.
       7. Tell me what you expect from me.
       8. Put me with some of the key people already working on them.
       9. Tell me what you'll do when things change or go wrong.
      10. Take me to a Chinese buffet.

~~~
mindcrime
That's some good stuff, but I'd add a couple:

1a. Show me the office I'll be working in. Any "open plan" or "2+ people per
office" setup decreases your odds of hiring me by about 93%. Not to say I'll
_never_ take a job like that, but it really, really hurts your odds.

1b. Show me the rest of the building... are there common areas where people
can hang out and collaborate away from their offices, preferably with natural
sunlight to the area? Are there plenty of conference rooms, team rooms, or
other areas for small group meetings? Do people have to fight to get a room
for a meeting? Are rooms commonly "double booked" in whatever system tracks
that? IS there a system for tracking room reservations? Is it Lotus Notes? If
"yes" to the last question, I walk.

2\. Show me the tools I'll have available to work with: Hardware, software,
etc. If you're handing out ancient laptops with 1GB of RAM while expecting
developers to use Springsource Tools Suite, I'm probably walking out on the
spot. If you're using CVS for version control, I'm probably walking out. If
you don't have a continuous integration server, I'm probably walking out.

3\. Tell me about the training budget, if any. If there is no training budget,
your odds just went way down.

4\. Tell me about your software process. Here's where _I_ am going to
interview _you_. If you say "we are an Agile shop" you better be able to
explain exactly what that means. Which Agile methodology do you use? Scrum?
XP? Crystal? RUP? Your own made up psuedo-Agile process? Do you just use the
"words" from Agile or Scrum without actually understanding them? If you use
the terms "sprint" or "iteration", and "epic" and "story points" but clearly
don't understand what they mean and how they should be used, I'm gone. Also,
I'll want to know if the _business_ side of the company understands and is
onboard with the iterative approach with empirical feedback loops. Do execs
prioritize stories for the backlog and then leave it be? Or are they randomly
coming in, mid-iteration, and changing things around willy-nilly?

5\. I'll want to know how many people I "report" to. If I have a "manager"
telling me what to do, AND a "project manager" giving me conflicting
instructions, AND random execs with an unclear relationship to the project
coming along and tell me stuff, we aren't going to be together long, sorry.

6\. Tell me more about the culture of the company... are people expected to be
on-time for meetings? Do meetings always have agendas, and time limits? Does
the company favor promoting from within? Do the execs have an "open door"
policy? Are their performance reviews? How are they done? Do you make
employees take any bogus "psychological profile tests"? Drug tests? Do
managers go out to lunch with the "rank and file" and share a beer or two, or
do managers go out in groups and pointedly avoid the riff-raff, and you'll get
yelled at for having one drink with your lunch? Does the CEO interact with the
"rank and file"? How? In short, convince me that this is a well run company,
who respect their employees, value engagement and actually empower their
people.

7\. Is there any attempt to implement Kaizen or become a learning
organization? Are there post-mortems for negative incidents? Do they use "Five
Whys"? Are employees fired for one f%!# up, or is it more of a "support, coach
and encourage" environment?

8\. Are there bonuses? Profit sharing? Employee Stock Purchase programs? Stock
options? What exists to align the goals of the employees with the goals of the
firm as a whole, other than "I want to stay employed"?

9\. Take me to eat Thai. A quality serving of Num Tok and a nice Mussuman
Curry improve your odds considerably.

~~~
edw519
I purposely didn't include any of yours. Why?

1\. Mine are issues and yours are details. If my 10 are satisfactory, I can
live with your 9, even though some may not be satisfactory. But if you 9 are
good and my 10 aren't, I'd last about a year before moving on because of lack
of meaning.

2\. Mine are about them, yours are about you.

3\. Mine show interest in the big picture; yours could easily paint you as a
demanding nit-picker (whether you are or not).

Yours are important and a good list. I just don't think I ever would (or ever
have) discussed them with a prospective employer.

And thanks for the tip on the Thai. I'm googling "Midtown Miami" and "Mussuman
Curry" as soon as I finish typing this.

~~~
mindcrime
_Mine are issues and yours are details._

I certainly drilled down into more detail, but I'm not convinced that there's
as much of a dichotomy there as you may see. Nonetheless, I understand what
you're saying, but I'd counter that "details matter" and that different
details matter more to some people than others. Also, I certainly don't intend
that list to be seen as an alternative to your list, I mean it to be additive
(from my perspective anyway).

 _2\. Mine are about them, yours are about you._

To some extent, yes. But asking whether or not a company has, and understands,
a reasonable software development methodology, or whether or not they have a
culture that foster employee engagement and empowerment, _is_ very much about
them.

 _Mine show interest in the big picture; yours could easily paint you as a
demanding nit-picker (whether you are or not)._

Yes, I will say that I chose to drill down to a deeper level of detail.
Basically I'm working backwards from the bad stuff I've actually seen in my
career, and putting it in terms of "these things suck, I don't want to be in
this environment, so convince me that this won't be the case here".

 _I just don't think I ever would (or ever have) discussed them with a
prospective employer._

I mostly didn't in the past myself. But that was out of naivety, or fear.
Either I was naive about the existence of the issue, or I felt like "I need
this job too bad to be too demanding." As I've gotten older and more
comfortable in my skin, and more confident in the value I can provide, I don't
worry about that as much. I can walk away from a job offer, knowing there will
be others.

And even if I didn't discuss these issues with potential employers, they have
certainly been factors. I was invited to an interview with $BIGCORP once, went
in, did the first round of interviews, and then got a phone call asking me to
come back in. I politely declined. Why? I saw that all of their developers
were in a big cattle shed full of low-walled cubicles - an environment that I
consider "optimized for maximum distractions" and fairly inhumane. I decided
they weren't a good fit for me based on that factor alone. Doesn't mean they
were wrong and I was write, or vice versa, it just wasn't a fit that would
have worked.

~~~
w-ll
You lost me in caring about what the office looked like and what hardware you
got. Who cares? I don't! I can hack on whatever; whenever; with whatever!
PERIOD!

edw519's questions provoke conversation, where yours provoke sales talk.

~~~
reledi
> I can hack on whatever; whenever; with whatever!

So can everyone else, it's just not enjoyable for some people if they're stuck
in a shitty office space with shitty hardware. Who wants to work at a place
where they don't enjoy working?

~~~
lsc
More to the point, if you are paying someone six figures to write code, trying
to save a few hundred bucks a year by giving them hardware they don't like is
just plain stupid.

I mean, as an employee, I don't care that much 'cause i'll bring in my own
stuff if you don't provide me with hardware I like... but my experience?
employers get itchy if you do this with more than, say, a keyboard. Most
places don't want me supplying my own workstation/laptop, which is fine, so
long as they buy me reasonable hardware to work on.

I'm reminded of one place I contracted at where they gave me a P3 windows box
(this was in the mid-oughts) - I mean, they were paying me like $70/hr. They
wouldn't let me bring my own hardware, either. I go to put linux on the thing,
you know, make it usable; and the IT guy finds out (well, I ask him for a
blank DVD) Anyhow, he goes all 'Mordak' on me and tells me that I should just
sit there in front of my useless computer and "think about what I did" or
something like that.

I mean, I understand that some places want me to use their hardware, and let
their IT people handle it... which is fine, if they are wiling to do a
competent job of it.

~~~
greenyoda
_"More to the point, if you are paying someone six figures to write code,
trying to save a few hundred bucks a year by giving them hardware they don't
like is just plain stupid."_

And if the company is stupid about something as fundamental as creating a
productive working environment, you can be sure they'll be stupid about lots
of other things as well.

------
Glyptodon
I've got to agree with you. I recently started getting serious about changing
positions and I've become completely convinced that much of the so-called
'talent shortage' is caused by the job search process, from job listings
through to interviews. Every step is unintentionally outrageous in a new way.

The first step, finding open positions that are appropriate to your skills and
abilities, is overwhelming and impossible. The only way you have any hope of
short circuiting it is to have connections with the right people who can open
the maze from the inside. Or to become famous in a community.

Otherwise, it's a slog of browsing through hundreds of job listings, finding
the one in 20 that isn't for .NET or MS-SQL or C# or Oracle, and the 1 in 50
that's not from a recruiter who's listed the same job 5 times, realizing that
you aren't qualified because you haven't used the all 4 languages they care
about, or maybe because you've only dabbled with some key piece of tech
they're convinced you need 3 years experience with, or they won't look at
candidates who need to relocate, or you absolutely need to know Red Hat when
you've pretty much used Ubuntu derivatives or Arch or whatever. Then you waste
time adjusting your resume, and never hear back.

Those you do hear back from will often mis-represent themselves and their
businesses in an attempt to get hires. In fact, I was a victim of this at my
current job.

Oh well. All I need to do is start spending all my evenings and weekends on
side projects while building an impressive blog to talk about coding and
technology. Once it's popular with the Hacker New digerati all I'll need to do
is wait... After all, we all know 'talent' is code for 'marketing.'

~~~
resu_nimda
If my recent experiences are any indication, the secret is to go to hackathons
and developer meetups. In the past I've gone through that whole painful and
impersonal process you've described.

It has actually shocked me how effective this approach has been, and I wasn't
even trying (I was just there to hack and learn). You get to have real
conversations with people who understand you, and you can easily walk away a
couple of those inside connections.

Also, the companies that send people to those events (more accurately, those
that hire people who will attend of their own volition), seem to be more
likely to have sane hiring processes. The two that I have been in talks with
have actually made me feel "recruited," and follow most of the points in the
article, which is a nice change (and I certainly don't have rockstar status or
really any public image).

~~~
pyre
I've gone to meetups, gotten business cards, but my emails just ended up going
into a black hole.

------
Mc_Big_G
Want to get my attention? Tell me you don't use email as a project management
tool. Tell me you won't send me 5 emails a day. Tell me you don't want two
status updates/meetings per day. Tell me you understand that the shotgun
approach to adding features is stupid. Tell me that you don't randomly change
features without any kind of data to back up the reason for making that
change. Tell me you follow through on promises. Convince me you're not a
fucking liar. Tell me you're offering benefits packages commensurate with your
senior engineer position. After that, in addition to what OP said, I'll
consider responding.

~~~
zem
honestly, if i got a recruiting mail that emphasised a strong commitment to
tool-based programming best-practices (dvcs, review, continuous integration)
it would raise my interest in the company significantly.

------
mooreds
Wow, full of great advice. The biggest one for me is: acknowledge applicants.
I've hired and know what a hassle it can be, but use a system, and respond to
everyone. Set deadlines, and if you miss them, acknowledge that. Look, this is
a possible team member--why would they believe you'll treat them with respect
when they are employees if you don't treat them with respect when they aren't?

Basically, it's the golden rule. It's not hard!

~~~
illektr1k
If you give me a few seconds of your time to say thanks, I probably won't mind
spending a few minutes staying late to get a task completed.

~~~
mooreds
Or thinking of a friend who might be a better fit for a position, or trying
your product/service, or recommending your product/service, etc. The dividends
of being kind and humane are pretty amazing.

------
gambler
Thank you for putting this into words. I wanted to write something similar for
a long time, but didn't get around to it.

Not only these things are frustrating for us as developers, they also
_decimate_ IT recruiting for companies. I've seen it from the other side too
(while conducting some interviews). It's quite incredible, really. It's like a
game. Both sides go through all the usual motions, but gain next to no useful
information about each other. In the end it all boils down to unsubstantiated
personal impressions, coated with some generic BS that makes it sound
"objective".

(Before you ask, it's very hard to change interviewing process when you're a
part of an established process with a lot of people involved.)

------
RandallBrown
I can't even begin to describe how worthless I think most coding interviews
are.

Here's a contrived problem, that will never come up in our work. Now solve it
by writing your code by hand without a compiler or any other tools that you
would use in real life.

I understand that these questions are often about seeing how you think and how
you solve problems. Throwing annoyances like writing code on a whiteboard into
a high pressure situation doesn't help that at all.

~~~
niggler
Writing code by hand reveals far more than you give it credit for. Someone
omits a semicolon? Bam, conversation about semicolons or ASI.

It's not about the fanciest solution. And anyone who does it that way is
foolish. It's the purest test of Language facility, and a really good
springboard for all kinds of questions.

Downvoters: have you actually tried to hire someone?

~~~
gambler
I didn't downvote, but I disagree and I _did_ try to hire someone. Whiteboard
questions are next to useless because they are, essentially, a guessing game.
The candidates need to guess what behavior the interviewer wants them to
exert. Some interviewers simply use it as an idiot filter, while others want
the person to explain their reasoning, wile yet another group is stupid enough
to think it's representative of real coding habits of the candidate. If the
candidates guess incorrectly, they will fail the question, regardless of who
they are or how good they know their trade.

In short, interpretation of whiteboard questions is too damn subjective.

~~~
lessnonymous
That's bad interviewing, not bad practice. Get rid of the guessing. Make sure
you explain to the candidate exactly what you're looking for.

I use whiteboard coding .. and it's not to catch you out on semi colons. I
even tell my candidates that they can use any language they want or even mix
them together or make up their own.

What I want to see on the whiteboard is a logical, working solution to a
simple problem. And if your brain freezes up because it's an "interview", I'm
going to push you in the right direction.

Once you have an initial working solution, we're going to chat about how it
works. If there are cases where it would fail. What assumptions we've made
about input. Maybe we'll (both) even jump over to another whiteboard and write
a new version based on our discussion. (Do your eyes light up when we've found
a cool optimization??)

The only language caveat I use: you can't have a call a function called
doitforme()

(If you or anyone you know is looking for a senior PHP job in Melbourne.AU,
I'm hiring. Hit me up and I'll send you to the ad on Seek)

------
csmatt
Excellent! Very well written and expressed.

There was an interviewee here today and I heard my boss tell someone to quiz
him on big-o notation. I rolled my eyes.

Yesterday I had an interview that started off with "Tell me a bit about
yourself." No direction as to what the interviewer wanted and, the worst part,
as soon as I said I was done, he went right into asking me what the difference
between "overloading" and "overriding" is.

How many years of experience do I need to have for them to stop asking me
things like this? Most of my work lately is in JavaScript and Python. I had
trouble answering "What's the difference between an abstract class and an
interface?" That doesn't necessarily come up in those languages in a distinct
way, so I'm out of practice in my vocabulary.

I have neat personal projects with source code on github. Do you really need
to screen me with a phone interview?

~~~
chollida1
> Yesterday I had an interview that started off with "Tell me a bit about
> yourself."

To be fair, alot of well meaning interviewers start off that way. It's
supposed to be a chance for you to mention all the good things that we may not
ask about.

In fact that question is so common its a good weeder question; if a person
can't blow your socks off with 5 minutes then you can probably predict how the
rest of the interview will go.

I mean the interviewer basically says to you a golden opportunity to say why
they should hire you. If you don't know what to say that pretty much says it
all:)

~~~
pekk
Except this kind of demand for a prepared 5-minute self-pitch really tests how
much you are confident and good at bullshitting, and not really anything about
your skill with anything.

A person is not worthless and incapable just because they aren't huge
salesmen.

No wonder women have trouble getting into this industry and getting ahead,
with this kind of macho superior attitude from interviewers

~~~
chollida1
> No wonder women have trouble getting into this industry and getting ahead,
> with this kind of macho superior attitude from interviewers

Calm down, no on one is having any kind of "macho superior attitude" :)

All I said was many interviewers start the interview this way so the
interviewee has a softball question that they can use to clam themselves and
make a point of anything they want the interviewer to know.

And I stand behind what I said, where if a person has a question perfectly
teed up for them and they can't tell you why they should be hired then they
probably won't do well with any kind of technical interview.

~~~
pekk
If you don't know why you are interviewing someone, why are you interviewing
them?

Test coders on how to code, not on how to sell.

------
freework
My best interview advice is this: Don't ask questions to judge, ask to learn.

A lot of interviewers have an interview process that is mainly designed to
eliminate candidates. Therefore, the process contains interviewers asking
"fake questions" that are designed to trip up candidates and eliminate them.
An example is a question like "How would you design a database engine". If I
really had to build a database engine, the context and details of that
situation would dictate how this database system should be approached.

Instead you should ask questions to learn. If you ask me what a cache is, you
better be asking me because you don't know what a cache is. If thats the case,
I'd love to explain it to you, because I like teaching people things. Its very
awkward to explain something to somebody that obviously knows that concept
very well.

When you ask questions like that, you end up subconsciously comparing
candidates by their explanation of cache matching up with how you would
describe cache. In other words, this process favors people who think the same.
A team full of people who all think the same is a company that has many
weaknesses. A strong company has people who approach problems differently. You
need people who approach life differently. Diversity is extremely important,
and asking fake questions during interviews leads to less diversity.

~~~
xtreme
I see three problems with this:

1\. It would pretty difficult to judge whether you are correct or not 2\. This
approach favors candidates with a flair for speaking but may not have good
programming ability 3\. The interviewer would probably run out of concepts
that he can reasonably expect the interviewee to explain.

------
bcoates
What am I supposed to do instead of the cookie-cutter technical interview?
Right now I do "Ask any question that starts with the phrase “tell me about a
time when”." for most of the interview.

I'm trying to give them an opportunity to describe technical things they've
done so I can drill into details and suss out if they're exaggerating their
skill-set and/or incapable of communication.

For perspective, I'm a schlub at my company they grab out of the hallway to
give technical interviews, not the founder or a full-time HR guy.

~~~
csmatt
Just came up with this, but you could ask the interviewee to teach you
something programming related that he/she learned recently. That should tell
you how well they communicate, can deeply show you their level of experience
(and interest), and it doesn't require that they recently revisited their
notes from academia.

Another option would be to keep notes on programming challenges you hit (and
the attempted and final solutions) while doing the job this person is
interviewing for and ask the interviewee to walk you through how he/she would
go about solving the problem.

~~~
rhizome
The first one might be funner for people-persons, but I'd say the second
approach would give you a much higher degree of confidence in the candidate's
skills.

------
rhizome
_"Be Interesting"_

As a corollary to this, I would advise companies to be OK with not being
interesting. Not every business is exotic and innovative. If you aren't
actually interesting, don't try to portray the company so.

 _"Rockstars, etc...."_

This has been hashed over so many times, especially here on HN, but I do want
to point out that there is a YC company (that has been trying to hire for A
LONG TIME, here and on SF Craigslist) who uses this kind of lingo. In fact,
they were the YC company that implied to me that the YC partners don't
actually try to control their companies too much. This company will be allowed
to create their own business (or not) via their own philosophy, which is a
point in YC's favor.

~~~
stanleydrew
So just be yourself as a company then right? Of course put your best face
forward, but don't lie.

If you're 5'4" and balding it's going to be apparent to anybody you meet, so
there's no point in lying on your dating profile. The same should apply to
recruiting. Both are a "dating game."

------
cliftonmckinney
We've been working to solve this problem for a long time at
<https://workforpie.com/>.

I completely agree with everything OP says, but I'll tell you what the real
problem is: time. This is especially true in early stage startups and
consultancies, where oftentimes the founders are still building stuff 95% of
the time.

Recruiters are easy (as are, by the way, the new wave of non-recruiting
recruiters like Developer Auction). Pay the man his money, and get a candidate
in return. The founder doesn't have to spend time communicating with
candidates or really doing any of the stuff OP mentions. That's why a lot of
companies still hire recruiters. (Some of the companies) don't care what
happens before the viable candidate walks thru the door, they just care that
he/she does. It's like buying an iPad. Most of us don't think about, and don't
care to think about what it took for that iPad to make it to us. We just care
that it did and that it works as advertised.

Recruiting: the most important thing most companies don't have time for...

There's absolutely a better way, and in the end it's less time-consuming than
what most companies do now. But the up front work is harder and more time-
consuming. Convincing someone who's time is worth more than his money to adopt
the better way is a hard thing to do.

~~~
Glyptodon
I wonder if it's possible to move from employer to employer getting paid more
and more by spending all your time answering questions on Stack Overflow
instead of working...

------
ghjm
Ok, so here's the problem. None of the recommendations in this are actually
actionable. Consider:

\- Be Interesting

Well, the company either is or it isn't. If you're an auto parts distributor
who needs to convert your application from Cobol on AIX to ASP.NET on Windows,
then well, you _aren't_ really very interesting. And there's not one thing the
recruiter can possibly do to change that.

* Care

Perhaps you genuinely care, but what if you don't? The recruiter is human too.
Maybe they just want to do their job and go home. You can't _decide_ to
_genuinely_ care. You either already do, or not. And we're saying they
_absolutely must not pretend_ to care. So ... the only remaining option is not
caring.

* Acknowledge Applicants

I don't think Matt appreciates the sheer volume of resumés that come in for an
advertised position. I know some HR departments that insist on sending an
acknowledgement for every received application, and they spend a _lot_ of man-
hours on it, and are constantly having to defend this practice to executives.
And honestly, why does the typical badly-formatted, ungrammatical resumé
actually _deserve_ a response, anyway? Matt may be a special unique snowflake,
but trust me, all those other people aren't.

* Get to Know Programmers

You can't do this without getting to know programm _ing_. And the whole point
of specialization of labor is that you shouldn't have to. You can hire a
doctor, lawyer or plumber while knowing nothing about plumbing, doctoring or
lawyering. Why should it be different for programmers? As a profession, why
should the rest of the world bow to our desires, instead of us creating a
better product for them to buy?

* Let Me Code, Dammit

This is the one piece of good advice. The best way to interview in any field
is to engage the applicant in job-related task behaviors and observe the
results. With programming, we're lucky that this happens to be pretty easy.
But I don't understand how this squares with the earlier rejection of having
the applicant code a Fibonacci function.

------
NateDad
Man I hate getting recruiter emails... I get this vague description of the job
for a "hot startup" or "well funded startup" or "established startup"... and I
have no idea what they actually make, what the company is about, etc.

    
    
       STARTUPS: STOP USING RECRUITERS!
    

in fact... _everyone_ stop using recruiters. Look on monster.com and dice.com
and stack overflow careers and whatever else. I guarantee you, recruiters
aren't going to magically find people that don't have their resumes listed
there. Anyone who wants a job has their resume listed up there. Find some
people that look good, and email them. It's not a full time job, and the
quality of candidates you get will more than make up for the lost time in
actually reading through resumes.

I pay 100x the attention to an email from a real person at a real company who
can actually talk about what they do, how they do it, and what I would be
expected to do, than I do an email from a recruiter who just wants to place me
at whatever company they can get me into. Recruiters don't care about you and
they don't care about me. They want a quickie - wham bam, thank you ma'am.

Maybe it's just Boston, I don't know, but you look on all the big sites, and
it's 95% recruiters.

Do you think job applicants are dumb? That they won't do some basic searches
to find the job your HR guy posted on dice.com?

Which of these do you think I'm more likely to click on?

    
    
      Job #213 from TechRecruiterz.com
      Full stack engineer for SomeAwesomeStartup.com
    

One is a position at an actual company, one is an advertisement for a
Recruiter who doesn't give any identifying information about the job, and
doesn't actually care if I'm a match for a job so long as I take A job... any
job, so he can get paid.

------
jwwest
> Assuming I Am Only The Last Thing I Was

I can't tell you how much this annoys me. I've been programming professionally
for over a decade now, and I've done a lot of things: C#, PHP, PERL, Ruby,
Python, Javascript, etc, etc, etc. Taking a look at my resume, you would
assume a rational and logical person would say: "oh, this guy's been in it a
while, he could probably pick up anything" -- but this rarely happens.

I get it, you need deep technical expertise in X framework working with Y
platform. Actually, no, I don't get it because a decent developer will pick up
and run with anything you hand them, regardless of what they've worked on
professionally in the past.

> Care

Passion != Success.

Look, I know you're oozing passion for building Twitter for Barnyard Animals,
but don't expect me to show enthusiasm for your niche. Honestly, I've probably
never heard of it before now. Maybe in time I'd come to really understand it
and be interested in it, but right now I'm more interested in the scaling
issues and optimizing my productivity through my tools.

------
kailuowang
As a coder, I couldn't agree more with the last paragraph (Let Me Code). Other
than paring interview, I also like code submission. The company gives you a
problem and couple of days and you write the code like you would in a real
project. IMO, nothing reveals a developer's coding capability more than that.

------
tibbon
Another thing that bothers me about some positions:

\- 5-10 years experience with all of the following: PHP, Python, .NET,
Javascript, C++, Perl, Erlang, Haskell, Ruby, IronPython, Lua, etc...

Seriously. Please god tell me you don't actually use ALL of those all of the
time.

------
segmondy
He who is getting hired is at the mercy of the person doing the hiring. That's
just how it plays out. If I'm getting hired, I have no say on how a company
should conduct their interview process. Their interview process is a window
into how they operate, and if it's terrible, I won't want to work for them. i
would hate to have a great interview process only to find out that the company
is terrible. There is a need for terrible interview processes, so long as it
matches the company. The last time I had a bunch of interviews, there was a
company I interviewed at, they were so terrible I knew I didn't want to work
for them. At the new company, I ran into people who interviewed at same
company and refused to work for them, and into two more who use to work for
that company and were glad to leave.

With that said, the biggest motivation for me is compensation. I don't care
what problems they are trying to solve, I don't have to love it. Want me to
write in COBOL? Fine, I'll learn it. Want me to work 10hrs a day? Fine,
compensate me accordingly. Everything has a price.

~~~
pekk
I find that people don't respond well to this 'mercenary' attitude. They
usually want you to act like you love it, even if it's stupid. They want you
to commit long-term, even if you are a temporary contractor. Etc.

Every company is like an oversensitive lover who has to be the best ever.

~~~
segmondy
Of course. I'll feign the love for it.

------
VikingCoder
When I'm involved in interviewing someone, one of the interviews will be
cookie-cutter. I've seen with my own eyes applicants who had stellar resumes,
had great conversations with everyone they talked to... and could not pass a
Cookie-Cutter Technical Interview.

You may think that it's insulting to have to pass a Cookie-Cutter Technical
Interview, but we are not (generally) a Professional group - we don't have a
Bar that you have to pass to be considered a professional programmer.

When I give something that looked like a Cookie-Cutter Technical Interview,
what I'm really assessing is, "How much of my time will I have to spend
explaining to this person how to solve programming challenges they'll actually
see in the code they'll be working on, and how hard will it be to have that
conversation with them."

The absolute best candidates were the ones who understood why I gave them the
Cookie-Cutter Technical Interview, and related to me their own frustrations
with similar oddities in programming... I concluded that they knew how to dig
in to programming problems, and solve them on their own.

The next best candidates, who I loved to recommend to hire, were the ones who
didn't know the answer to my questions (which were purposefully challenging),
but who had a great dialog with me. I would encourage them to ask questions,
to think out loud, etc. I know this is very, very hard to do in an interview,
and I tried as hard as I could to be encouraging, and patient, and give hints
when they were needed. And if they responded by asking good questions, stating
their assumptions, verbalizing what it was that was difficult for them... I
concluded that they would be good at identifying when they were over their
head, which I hoped meant they would know when to ask for help, and I could
also assess whether they'd be able to explain their problem succinctly.

Let me circle back with an anecdote: we had a candidate who looked great on
paper, spoke well in all of his other interviews, had lead impressive teams at
competitors, and who couldn't solve FizzBuzz. Hiring someone like this is
incredibly expensive. Spending one hour of time with a candidate to make sure
they can... program... is well worth the time.

And I'm sorry, but it's a Buyer's Market. People trying to Sell themselves as
good candidates are going to have to put up with one hour of demeaning
technical questions. Hopefully they'll turn that hour into a fun discussion
about how programming is challenging, and relating their own stories of the
oddities of the languages and libraries they use, and why they have certain
preferences, etc. - a whole meta level above why ++i is different from i++,
and how it's burned them in the past when someone didn't know the difference,
etc.

You say "Let Me Code, Dammit," but most of your job will be READING code that
other people write. I know what the code looks like here, and you don't. If I
show you the warts, I can tell how you'll react to them. Do you call ugly code
"ugly"?

<http://www.osnews.com/story/19266/WTFs_m>

Do you know why this line of C++ code compiles with Visual Studio 6, but
produces the wrong result?

Do you cringe when you see a %s with an int in the param list? Do you tell me
that printf functions are inherently unsafe? How do you recommend making them
safer?

If you code C++, do you know Boost?

Can you spot a new without a delete? Will you tell me to use shared_ptr or
auto-ptr, or just use the stack?

Typing code is generally having good habits, using safe but powerful libraries
and language constructs the right way. But maintaining code is a bit of an
art. If you don't agree about what's "ugly" and why, you're probably going to
push the body of code in a direction that I call unmaintainable.

And there are different strategies in how to make code more maintainable over
time, but within one company, we should probably all be pushing roughly in the
same direction.

"Let Me Code, Damnit" doesn't help me assess that as well as something that
looks - at first blush - like a Cooke-Cutter Technical Interview does.

~~~
DavidWoof
> Do you know why this line of C++ code compiles with Visual Studio 6, but
> produces the wrong result?

Are you actually serious? You ask about a quirk in a 15-year-old single-
platform compiler?

I always wonder what some interviewers think they're gaining from questions
about minute historical trivia like this. It doesn't provide any real insight
into ability at all.

~~~
Contero
I thought that was meant to be a joke. At least I hope it was. It would get a
good laugh from me in an interview.

~~~
VikingCoder
And that would be good, too. I like to laugh with my co-workers. Especially
the ones who have to maintain code that was originally written in Visual
Studio 6, but somehow has survived to today. Because if you end up with a job
like that, where you occasionally have to maintain something that long-lived,
you'd better have a sense of humor to carry you through to the times that you
get to innovate like crazy and make something nobody had ever thought of
before. May we all get to work at jobs that have a healthy and responsible mix
of those two activities.

------
nollidge
Also stop with: interviewing based on rote memorization.

Yesterday I had a really crappy (third-party!) phone screen assessing my
ASP.NET and some general web dev knowledge. Questions included asking me what
the stages are in the ASP.NET page life cycle, how to create Web Control in
ASP.NET, what elements are new in HTML5, and how to pop up a new window in
Javascript.

None of which I know off the top of my head (except I know <canvas> is new),
each of which I can learn in about 100 milliseconds, and none of which assess
_skill and intellect_.

Did you want a skilled programmer, or someone who memorized their Foobar
Enterprise Framework cheat sheet? Because you're only interviewing for one of
those.

~~~
rhizome
I recently got the question, "explains what happens when you type a URL into a
browser."

~~~
willismichael
Typing it in isn't really that interesting... but when you submit, now that's
when the magic happens.

~~~
rhizome
Believe me, that answer was the first thing that came to mind. "With or
without the enter key?"

------
meerita
I did an interview 2 week ago. I'm not a programmer, yet, they gladly asked if
I code wich I answered yes. What made me go nuts after show them all my work
is, fill a questionary? one question was: "Tell us what you understand by
"pixel perfect"

------
supervillain
Number 1 rule for hiring geeks.

\- Do not ask for a .doc Microsoft Word document resume

Because we might be scrambling and downloading LibreOffice and converting our
.latex resume to .doc, if you want to get our attention, ask for TXT, PDF or
LaTeX format.

~~~
ghjm
Unless you're trying to hire geeks who can fit in to a standard office
environment without weird platform demands. In which case, insist on .docx.

~~~
disgruntledphd2
Well, yes and no. I write everything either in LaTeX or markdown these days,
but its ridiculously simple to output either of these formats to docx, so
normally that's what I do. I'll always send them the PDF version of my resume
first though, as good typography can make you look better.

If a job requires me to write in Word throughout the day, that's a job I don't
want (in fact, writing grant proposals in Word was one of the most frustrating
things about working in adeademia).

------
ryderm
> If you don’t have genuine passion for where you work and you do the hiring,
> you’re committing some kind of moral fraud. You might want to see to that.

Never really thought about this before, but I totally agree.

~~~
pekk
Almost everybody is playing some minor role in making someone else a lot of
money. That also includes people doing hiring.

All this kind of statement will do is make companies extract faked workgasms
from their employees every day.

------
eksith
Thank you! That no recruiting recruiter email is such a buzzkill.

Even if the company itself looks interesting, just the fact that they sent
some brocruiter to flood prospects with emails just makes me question the
wisdom of the folks behind the company. I can appreciate a lax attitude at
work up to a point, but beyond that, there's no real productivity. It's like
the days before the dot com bubble when VCs were dumping cash on a _potential_
product sold on hype.

Even if I were to get hired, what's the point if the company folds in a year?

------
scardine
"Micro Positions" are a known scheme to hire foreign workers under H-1B visas.
The employer must, prior to filing the H-1B petition, take good-faith steps to
recruit US workers for the position for which the H-1B worker is sought. For
example, if you want to hire a Brazilian, publish a position for a "Python
Portuguese-language backend optimization engineer". The Portuguese-language
part is just to assure no US worker is qualified.

------
listaware
The problem is that recruiters carpet email (bomb) programmers, for many of
them it's a numbers game. They aren't interested in taking the time to get to
know you and frankly I don't expect that they do.

The best way, in my opinion, to get a new job is to be proactive and search
for it yourself. Contact companies directly, use your network and see how you
get on.

Recruiters sadly aren't interested making friends.

------
greenyoda
Very good article. I have just one thing to add: If you don't tell me a salary
range up front, I have absolutely no incentive to even talk to you. I have no
desire to go through an entire interview process just so I can find out that
you'll be offering me a salary that's $100,000 less than what I'm currently
making. It would be a huge waste of both your time and mine.

------
zobzu
I'm not a recruiter but like everyone i do interview people from time to time.
While I agree with TFA, of course, i think a few "quiz questions" are often
necessary.

While you can check if someone can code on his github/whatever page without
asking any question, you don't just want to make them _want to work for you_.
You also need to screen them enough to figure out if.. they're going to be
able to work for you. They're not all well known. There's new fresh people
graduating all the time, and even if there's people that aren't just well-
known (the vast majority!)

So, til there's better, i always have 25% of "quiz" questions, which are all
100% technical and all require either logic, either knowledge. (then 50% of
discussion of the stuff there's to do, and 25% for candidate's questions).
THEN if there's interest there's real interviews as in, come to the office 'n
let's chat about stuff you'd like to do. Not before.

------
electrotype
There is one main point that will help me want to work for you :

\- Show me your business doesn't considere developers as _resources_ that are
easy to replace. Because this is not true. I've never seen a successful
project built by thousands and thousands of inexperimented or bad developers.

------
fduran
To companies hiring: explain who you are and what you do, what you are looking
for and what the hiring process is, extra points for a FAQ. Here's an
excellent example: <http://www.matasano.com/careers/>

------
renegadedev
I just got an email from a recruiter who's looking for a SQL DBA. The
applicant must know (note the lack of mention of DBA skills): Java Script,
jQuery, CHTML, CSS

I also frequently get asked by recruiters "how much do you make?". How is my
current salary any of their business?

~~~
blackdogie
Personally I don't think that recruiters are worth paying any attention to. At
least not in the cookie cutter version. If they want to get in touch then
that's cool, but if it's a generic email it will get labelled as SPAM.

------
CurtMonash
I love that he just assumes people know the Heinlein quote. ("Specialization
is for insects.")

~~~
ibudiallo
I did not know what it was, and i am glad you brought it up :)

------
wfunction
I beg to differ on the whiteboard part. Asking someone to code on a whiteboard
is a perfectly legitimate way of seeing if they can code a few lines (with
minor mistakes if need be) without needing a compiler to guide them through
each step.

------
gavinflud
This is an excellent post. I'm soon-to-be fresh out of university and the
company I'm joining had a hiring process very similar to what you've
described.

They were in constant contact throughout the process, sold themselves very
well and - although they did carry out a cookie-cutter technical interview -
it actually made for an interesting hour where I was able to solve their
pretty simple sample problem and we ended up going off on a tangent talking
about how to optimize the interview process.

What differentiated them from countless others was that personal touch. I
always felt like they wanted me on board and they were able to sell themselves
and their culture very well.

------
up_and_up
“Node.js V8 Korean-language backend optimization engineer”

Thats hilarious. I recently was job hunting and I ignored prob 20% of position
due to that fact alone.

------
ruswick
I concur with the point about the ridiculous "rockstar" terminology. It's
ambiguous and non-descriptive. However, the titles that truly irk me are "code
artisans" and any variants thereof. I've seen this in use several times in the
past few months, and it is the pinnacle of absurdity.

------
stonemetal
I think my ideal way to land a job would be

1) contribute to some open source project.

2) get a beer with the company's dev team at a hackathon.

3) job offer.

------
anonfunction
The biggest thing I took away from this is that you should treat potential
employees like employees.

------
michaelpinto
Having survived the first dot.com crash reading stuff like this always makes
my "smells like a bubble" detector go off. Although to be fair I don't really
sense that in NYC, so maybe this is more a reflection of silicon valley.

------
coditor
I've said all of this many times on my blog as well. Sadly the only people who
read my blog and live on this site are the hirees. The hirers never visit and
remain ignorant.

------
brian_wendt
Wow, can't tell you how much I have seen and experienced the BS that you
mentioned. The company I'm with right now may be hiring soon, fwd this article
to my boss. Thanks

------
corwinstephen
Not that this information isn't good or anything, but how many "the hiring
process is whack" posts are there going to be on Hackernews before the message
resounds?

------
graycat
Interesting thread. The tread is interesting to me because I'm a sole founder
of a Web 2.0 startup with some relatively technical internals (in the server
farm only), and have done all the work from the beginning to the present. If
the startup works, then I will have to hire.

But, for what is in the OP and this thread, I have a different view.

Below I discuss the differences in three parts, software development
environment, teams, and qualifications and add some comments at the end.

Software Development Environment.

I've been around computing for a long time, but I skipped over the big growth
in Unix/Linux and C++.

Instead my more serious software development has been on IBM mainframes and
now on Windows with Visual Basic .NET, ASP.NET, ADO.NET, SQL Server, etc.

Why Visual Basic .NET? It seems like the nicest way to exploit Windows, the
Microsoft Common Language Runtime (CLR), and the .NET Framework (that is, the
enormous collection of classes), and work with the rest of the Microsoft
software for TCP/IP, SQL Server, IIS, etc. The syntax of C# is too close to
that of C/C++ and, thus, is deliberately 'idiosyncratic' and 'tricky' and,
thus, an obstacle and error prone; the Visual Basic .NET syntax is much easier
to take. The idea of 'immutable' strings, each with maximum length 2 GB or
some such, along with the ideas in 'managed code' and memory management seem
terrific for my applications level programming.

I've always typed code into just a text editor, one that permits writing good
macros, the most capable I had access to, done operations with just command
line scripts, never used an 'integrated development environment' (IDE), and
rarely used any interactive debugging. Instead, I just put some checks into
the code, have the code write a lot of tracing data, and then look at it with
a text editor. Always worked so far!

For my Visual Basic .NET code for my site's Web pages, I'm just typing into
ASP.NET without any explicit use of model–view–controller (MVC) or other Web
site 'framework', whatever such a 'framework' is! Once I looked at MVC for a
few minutes, and it seemed that some of my code is similar!

I looked at Visual Studio, didn't like the documentation or the many small
'panels' all in one window (instead of the 10-20 windows I use), never saw a
description of what they meant by 'dockable', and concluded that my favorite
text editor and some command line scripts were more productive.

I've been surprised and pleased by how well Visual Basic .NET works for Web
page development on Microsoft's Internet Information Server (ISS) -- e.g.,
just have a Web browser ask for the page using the loop-back IP address, and
IIS kicks off the Visual Basic compiler, apparently for anything and
everything on the site that needs compiling, does any 'link editing' on the
fly or some such, and at the bottom of the Web page gives, based on options in
the Web page code, lots of details on the compiling. Generally, if there are
no error messages, then the Web page displays. It's nice. Microsoft should
explain it someplace!

So, I begin to conclude that the main things a programmer needs are good
versions of a text editor, scripting language, programming language, and
documentation on these and the libraries, APIs, etc.

Teams.

I've done some software development in teams and supervised some software
development. In both cases, the work went well with no attention at all to
formal methodology, 'team tools', 'repositories', etc. In one case, I was one
of a team of three researchers in artificial intelligence at IBM's Watson lab
at Yorktown Heights, and we did research, published papers, designed and
developed software, and our work resulted in two, shipped, commercial IBM
Program Products, IBM's highest quality software product category. For one of
these two the code that was shipped was essentially just what we wrote. In the
other case, we did all the work except the actual code was typed in by an
outside company in Taiwan.

In addition to our three researchers, and we all wrote code, we had several
programmers. Really, it was a team of seven people. For a project that small,
the lack of formality worked fine.

Once I was the Chair of a computing committee for an academic institution and,
thus, in part a supervisor of a computing group that served the institution.
We had several programmers, former students, with no formality at all, and the
work was terrific.

I've never seen any formal approach to code 'building', testing, test
'buckets', 'quality assurance', etc., yet we had no problems.

So, I begin to conclude that for groups as small as seven, with a good leader
and some good people, can do well with no formality at all. None. Zip, zilch,
zero.

Programmer Qualifications.

The people I've worked with have nearly always been plenty bright, knew a lot,
learned quickly, worked hard, etc. And these people were selected with none of
the interviewing ideas in this thread.

Mostly the people were college graduates, but not all; some of the people had
technical Ph.D. degrees; some were graduate students in technical programs and
part time.

It appeared that generally quite sufficient (but usually more than necessary)
qualifications were a Ph.D. in pure/applied math or theoretical/experimental
physics, some good computer usage experience, and some scientific/engineering
programming in two or more languages would be fine. Then such a person could
pick up Knuth's TACP, Ullman on database or compiling, Sedgewick on
algorithms, artificial intelligence, 'machine learning', the elementary

Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein,
'Introduction to Algorithms, Second Edition', The MIT Press Cambridge.

etc. and zip through like reading a novel. Gee, Knuth's TACP has a nice list
of binomial and combinatorial formulas, good coverage of heap sort and the
Gleason bound, B-trees, AVL trees, and random number generation, and more that
is useful ..., well, maybe if I got out my copies I could find some more! Yes,
he has a very clever presentation of the fast Fourier transform, but the more
specialized sources, especially for signal processing, are better even if less
clever.

Gee, guys, there are more tough technical ideas in several cases of just 30
pages in W. Rudin's books than in some stacks of computer science texts. For
real technical creativity, R. Bland's proof in linear programming totally
blows the doors off anything I've seen in Bachelor's or Master's level
computer science or suspect is there or saw in technical talks at Yorktown
Heights.

Yes there are some other hiring criteria, but they are mostly by 'exception'.
E.g., if a person clearly has a personality problem that keeps them from
working effectively alone or with others, then can't have that person around.

I begin to conclude that software is still a relatively simple subject, and
for hiring the sufficient conditions I gave are fine.

For more:

More.

If I hire someone with a lot of 'skills' in tools and procedures for team
developed software and those skills seem to be worthwhile, then that person
could be helpful and welcome!

Compensation.

For salary, guys, look, the first thing to check is, does the job pay well
enough to let you buy a house and support a family in nice conditions?

Large Software Projects.

Next, I confess: I've never tried to debug or modify a 500 KLOC 'code base'
developed over 10 years by 20 programmers none of who are still there with no
documentation except some sparse comments in the code. My view is that such
code is not a programming problem but a management problem: To fix the
problem, need a lot of time, money, and people. Sorry 'bout that!

Training.

I've never seen anything very useful in formal training. Have to accept that
major fractions of programmer time go to working through bad documentation,
learning new material, migrating to newer tools, writing little tools, etc.
For a 'training budget', no: Just budget the time along with everything else;
for travel and fees for formal training sessions, sure, but likely mostly the
training should be in-house without flying across the country, business class,
limo service, fancy hotel, rental car, big per diem, big training fees, etc.

Security.

In some organizations, have to take security very seriously. Might have to
hire some outside firms with tools, procedures, tests, etc. Okay, then do
that.

JavaScript.

So far have yet to write a single line of JavaScript. But so far Microsoft is
writing about 300 KB of it for me, and I have to suspect that I could cut that
down by a lot and, thus, save on bandwidth. So, if I have to write some
JavaScript, then I will. That is, get some materials and/or 'training', learn
some JavaScript, and write some.

Do something really complicated with JavaScript? I want to try never to do
that!

And I would generalize that approach to JavaScript to nearly everything else
in computing, for me and any people I hire.

Writing.

Once someone in my company has spent a lot of time and, thus, company funds,
learning or doing something that has some importance, then I will want them to
document what they learned or did so that the company can have the work as a
continually valuable 'asset'. So, net, one of the better abilities I want is
the ability to write good technical material. Being able to give a good
technical talk would also help.

Net.

Many organizations want a lot of detailed 'skills' that I get by without and,
thus, won't require in people I hire. I prefer JIT skills -- learn the stuff
as needed.

~~~
eppsilon
I appreciate that you posted this alternative opinion, but I found myself
disagreeing with much of what you wrote.

 _Why Visual Basic .NET? It seems like the nicest way to exploit Windows, the
Microsoft Common Language Runtime (CLR), and the .NET Framework (that is, the
enormous collection of classes), and work with the rest of the Microsoft
software for TCP/IP, SQL Server, IIS, etc. The syntax of C# is too close to
that of C/C++ and, thus, is deliberately 'idiosyncratic' and 'tricky' and,
thus, an obstacle and error prone; the Visual Basic .NET syntax is much easier
to take._

I also work with the Microsoft stack, and I was surprised that you prefer VB
over C#. I've used VB (briefly), and the syntax felt quite cumbersome compared
to C# (which I use daily). What do you find "idiosyncratic" or "tricky" about
C#?

 _I've always typed code into just a text editor, one that permits writing
good macros, the most capable I had access to, done operations with just
command line scripts, never used an 'integrated development environment'
(IDE), and rarely used any interactive debugging. Instead, I just put some
checks into the code, have the code write a lot of tracing data, and then look
at it with a text editor. Always worked so far!_

Before I switched to .NET and C#, I used Django and Python, so I have some
experience with the more barebones development environment you seem to like.
There are things about Visual Studio that bother me, but I have to say that
it's really pretty good overall. I think IntelliSense and ReSharper save me
far more time than macros could. Also, interactive debugging feels
significantly nicer than printing values to the console or messing with lower-
level debuggers like gdb/pdb. What text editor and scripts do you use that you
find to be better than Visual Studio?

 _For my Visual Basic .NET code for my site's Web pages, I'm just typing into
ASP.NET without any explicit use of model–view–controller (MVC) or other Web
site 'framework', whatever such a 'framework' is! Once I looked at MVC for a
few minutes, and it seemed that some of my code is similar!_

How do you organize your code if you don't use MVC? It's a pretty well-
regarded pattern; you may want to look at ASP.NET MVC or a similar framework.

 _In both cases, the work went well with no attention at all to formal
methodology, 'team tools', 'repositories', etc. ...I've never seen any formal
approach to code 'building', testing, test 'buckets', 'quality assurance',
etc., yet we had no problems.

So, I begin to conclude that for groups as small as seven, with a good leader
and some good people, can do well with no formality at all. None. Zip, zilch,
zero._

You don't use version control, bug tracking, feature planning, nightly builds,
continuous integration...any of those? I would think a project without those
essentials would be quite disorganized.

 _It appeared that generally quite sufficient (but usually more than
necessary) qualifications were a Ph.D. in pure/applied math or
theoretical/experimental physics, some good computer usage experience, and
some scientific/engineering programming in two or more languages would be
fine. Then such a person could pick up [lots of computer science knowledge]._

These requirements sound extremely high. Wouldn't someone with a recent B.S.
in computer science or software engineering be significantly more prepared for
the job (as well as less expensive to employ)?

 _I begin to conclude that software is still a relatively simple subject...._

I don't think this is the case at all. You can assemble a team of good
developers, follow industry best practices, be blessed with a good product
manager...and you still have to deal with bugs, tangled code, issues with
libraries, changing requirements, architectural design problems, UX design
failures, and so on.

 _For salary, guys, look, the first thing to check is, does the job pay well
enough to let you buy a house and support a family in nice conditions?_

Er, that doesn't sound all that good considering the level of demand there is
for software developers. You need to at least match the average salary and
benefits for the region and the skill level of the position. And you'll have
to pay much more if you're serious about requiring Ph.Ds.

 _I've never seen anything very useful in formal training. Have to accept that
major fractions of programmer time go to working through bad documentation,
learning new material, migrating to newer tools, writing little tools, etc.
For a 'training budget', no: Just budget the time along with everything else;
for travel and fees for formal training sessions, sure, but likely mostly the
training should be in-house without flying across the country, business class,
limo service, fancy hotel, rental car, big per diem, big training fees, etc._

I don't think this is what is meant by "training". Learning new tools or
libraries on the job is expected of most developers. Providing training means
sending developers to conferences, buying them books on topics related to
their work, allowing them to work with more experienced mentors, etc. Those
things are really not that expensive considering the benefit you receive in
improving your developers' skills.

 _Do something really complicated with JavaScript? I want to try never to do
that! ...And I would generalize that approach to JavaScript to nearly
everything else in computing, for me and any people I hire._

This seems like a very bad approach to use if you value improving your skills,
gaining domain knowledge, or keeping up with industry trends. JavaScript in
particular has been an area of incredible innovation in the past decade or so.
Is it really worth avoiding just because it has some quirks?

 _So, net, one of the better abilities I want is the ability to write good
technical material._

I somewhat agree. Developers should be able to clearly document their code
through a combination of good formatting, useful comments, thoughtful naming
of types and variables, and blocks of technical documentation (docstrings/XML
documentation) where appropriate. But they shouldn't be doing the jobs of
technical writers.

 _Many organizations want a lot of detailed 'skills' that I get by without
and, thus, won't require in people I hire. I prefer JIT skills -- learn the
stuff as needed._

This sounds good in theory, but I don't think it really works in practice. For
most projects you need people to have certain skills or experience before they
join the team...otherwise you'll spend most of your time reinventing wheels or
teaching them the basics. For your web app startup, would you really hire
someone who is intelligent and has credentials but has only a vague idea of
how a web app works? Can you really expect them to just pick everything up as
they go and still be a major contributor to the project?

~~~
graycat
I mentioned my use of a favorite editor and command line scripts; so, I should
add some detail on those two:

My favorite editor is KEdit (Mansfield Software), a PC version of the IBM
VM/CMS editor XEDIT. The macro language of XEDIT is Cowlishaw's Rexx, and
KEdit uses their similar Kexx. My scripting language is ObjectRexx, an
extension of Cowlishaw's Rexx. Rexx is elegant.

Nearly all my typing for everything goes into KEdit \-- one means of input to
rule them all.

My spell checker is Aspell from some TeX distributions; it's a darned well
written program, can support several languages, and lets me maintain just one
addendum dictionary!

VB:

I programmed in C for a while and got used to it. If I used C# daily, then I'd
likely get used to it. As I recall, K&R confessed that the C syntax is
idiosyncratic, which I agree with. E.g., can write

    
    
         i = j++ + ++k
    

Too tricky for me. When I read Lippman on C++, it seemed trickier. What I've
seen of C#, say, from reading Microsoft's Web pages at their MSDN, it looks
like it's borrowed such 'sparse' syntax from C++.

So far it appears that Visual Basic .NET (VB) and C# differ essentially in the
flavors of 'syntactic sugar' and could be translated one to the other, almost
statement by statement. So, I prefer VB mostly due to a flavor of syntactic
sugar.

What I like in the VB syntax is essentially the "cumbersome" part -- somewhat
redundant, easy to read, puzzle problem free. I type the code in quickly and
let the VB compiler tell me when I've omitted little things. But there's
enough redundancy in the syntax so that the VB messages usually still
recognize what I intended. Good -- I don't want some tiny typing errors to
convert what I want into a still legal statement I don't want.

VS:

First, I don't like the one window with lots of small panes. Second, when I
look at VS, I can't make any sense out of it. E.g., I have no idea what the
little icons or the various panes are for. Then, I've never seen any very good
documentation. I could figure it out, but my objective is my business.

The times I tried VS; it created a 'project' where Hello World started off as
50 MB of 'stuff' I didn't understand. Then I fear that if, really when,
something goes wrong I will have to dig into that 50 MB, with no
documentation.

For more, I don't want to type into VS if only because I don't see any hope
for the kinds of functionality I get with KEdit and macros that I highly
value.

Instead of VS, here's an outline of what I do:

In the morning when I start programming on my Web 2.0 project, I run some
little ObjectRexx scripts that open about 25 windows, mostly KEdit and
Firefox, in a particular Z-order and arrange the UL corners of the windows
equally spaced on a line on my screen from LL to UR while preserving the
Z-order. I close the windows I won't be using that day and end up with 10-20
windows. When the windows get to be a mess, one click on an icon drives an
ObjectRexx script to arrange the windows again preserving both the Z-order and
the order of the left sides. Net, I get in effect much more screen area for my
work than I get from the one VS window with its small panels.

The windows are mostly for files and directories where I am working or with
relevant documentation. In addition, one of the scripts starts in a console
window the session state store I wrote (some TCP/IP and a collection class).

I have 4000+ Web pages of documentation and a little system for abstracting
the pages and finding the pages I need. In addition, for more relevant pages,
I put in my source code page titles and corresponding tree names on my
computer; then one keystroke in KEdit has Firefox display the Web page from
which I can continue to traverse the MSDN tree back at MSDN. That's my
substitute for Intellisense.

KEdit is terrific as an easily automated chef's knife and cutting board for
slicing and dicing files of text, working with collections of files, starting
programs, dialing phone numbers, etc. I don't want to type into VS instead of
KEdit.

For debugging, the main challenge for me is finding the cause of the software
going "poof" after running for some interval. So, with interactive debugging,
there is too much stopping at break points and starting again. Instead, I just
have my code write values of relevant variables to a file or, for the code for
a Web page, the Web site log. After "poof" I look at the output, maybe 10 MB,
go the bottom where the "poof" happened, and move backwards, using the KEdit
'select' tools to show me what I want. It's always worked so far! Sure, later
I could have the writing go over TCP/IP to a program that keeps, say, the
10,000 most recent lines.

> You don't use version control, bug tracking, feature planning, nightly
> builds, continuous integration...any of those? I would think a project
> without those essentials would be quite disorganized.

Sure, some of those I do now. But I just don't yet have or need formal
procedures and tools. One thing I do nightly is an incremental backup!

Since I'm just one guy, some simple techniques are sufficient for being
organized. And at Yorktown Heights, I found that for our team of seven, still
we could use just simple techniques.

> These requirements sound extremely high. Wouldn't someone with a recent B.S.
> in computer science or software engineering be significantly more prepared
> for the job (as well as less expensive to employ)?

I just said "sufficient"; I didn't say necessary or "requirements"!

One reason for my interests in this thread is that I don't yet know just how I
will hire; I don't intend to hire all Ph.D.s.

My company needs for the code to be a solid company 'asset'. So, the code has
to be well written and not just some gibberish.

For what I'm doing, I believe I could teach good people quickly.

On my

"I begin to conclude that software is still a relatively simple subject"

So, have (n)log(n) in-place sorting, balanced binary trees, TCP/IP, if-then-
else, do-while, call-return, etc. Simple.

We are in agreement. Most of the sauces in Escoffier are fairly simple, but
running a three star Michelin restaurant is not. Having a big chunk of
production software in good shape and working and moving along nicely is not
so easy and takes some good people.

On salary we may not be communicating: What I hear about programmer salaries,
e.g., people happy to get $100 K a year, sounds a bit short of the standard I
mentioned. E.g., $100 K a year won't go very far where houses are $400 K,
taxes are high, and want to support a wife and three kids.

Early in my career, in one two week period I went on seven interviews and got
five offers. Then I was getting paid about six times what a new Camaro cost.
Today that would work out as $240-300 K per year.

Right, houses at $400 K are too expensive for anyone to afford. Yet, people
keep buying them.

We largely agree on training. Some conferences are just for entertainment, but
some are important for training. And could at times use some in-house lectures
or short courses, given by people from inside or outside.

> This seems like a very bad approach to use if you value improving your
> skills, gaining domain knowledge, or keeping up with industry trends.

I'm not interested in JavaScript because I don't have anything important in
mind I need to do with it beyond the JavaScript Microsoft writes for me.

I believe that the goals of both the company and the employees are closer to
the bottom line, that is, the real business needs, than what you mentioned.
And I believe that there is relevant knowledge to be gained much more valuable
than what you listed. To me "industry trends" are too much like a fashion
show, not that I've ever been to one.

We're not communicating well on the role of good technical writing. E.g.,
suppose someone in my server farm looks into system management platforms from,
say, CA, EMC, HP, IBM, and Microsoft, goes to some conferences, tours some
sites, gets some sales pitches, talks to some consultants, etc. Then I will
want them to write up a report on what they learned and give a presentation to
likely the whole server farm staff, myself, and maybe others.

I could list another dozen such.

For a significant new software development project, there should be at least a
first cut design document.

For technical writing, I believe that should be done by people who understand
the material really well. For 'technical writers', they may help such a person
with organization, grammar, punctuation, building an index, etc.

Your remarks critical of "JIT skills" have some value. But I anticipate people
bright enough and growth slow enough that what I outlined should work. If they
want to know how the Web works, say, from the ISP connection into the LAN
switch to the servers, etc., fine: I'll outline it quickly. Then I'll have the
first person write up notes available to teach others, get some books, etc.

Current computing can be super complicated, but my plans for my company are to
keep nearly all the computing relatively simple. If the computing gets to be a
big, complicated thing, then I've done something wrong in my business planning
and server farm and software architecture.

------
signed0
Can someone explain what a "resume wall" is.

~~~
lessnonymous
A job board has a 'resume wall'. It's like there's a very narrow slot in it
you shove your resume through. Then you just hope. And hope. And hope. And
then give up because that wall ain't talking.

Anyone ever applying to me that sends me a legitimate application WILL get a
response. And if you made it to a phone interview you WILL get a phone
response even if we're not continuing.

It's all about respect. (Plus, I might want to hire you next year for a
different role. I'd like it if you thought highly of me. And it's not
difficult to be polite)

(If you or someone you know is looking for a Senior PHP role in Melbourne.AU,
hit me up and I'll point you at the ad on Seek's resume wall :-P)

~~~
signed0
So it's like a firewall but for resumes?

------
michaelochurch
This is a great post.

One issue here is that a (possibly deeply-layered) "neural network" model
applies to many industrial processes, which means that there are a lot of
interacting components, but in many of those the input/output relationship is
almost binary-- a logistic curve close to a step function. Most companies have
absolutely no need for exceptional people. They're looking for a process that
can hire good-enough people at controllable volume. They have a mission to be
fulfilled and want it done well enough. There's nothing wrong with that; it's
just that most of them have no idea how to execute. They might over-hire and
reject mediocre-but-good-enough people. They might come up with insane purple
squirrel queries or HR-ish hiring policies ("we only hire NoSQL developers; it
says here that you use Scala"). They might hire mediocrities (when they
actually need strong people) and compensate by hiring a lot of them, which we
know doesn't work.

There's also a deep, bilateral trust sparsity in the economy. Most employers
aren't doing interesting work and have shit cultures. Most programmers haven't
been well-trained or motivated to grow and are incompetent. It goes both ways.
I'm just as elitist and network-driven in terms of the companies I'm willing
to consider credibile as they are in their willingness to fairly evaluate
candidates.

I can't come up with a good way to overcome this in the general case, but the
OP gives a strong guide for recruiters to overcome trust sparsity and show
capable developers (who can be selective) that they're not actually clueless.

------
ttrreeww
Cash, lots of cash!

