How To Hire Me (or any other programmer) - <AUTHOR> http://www.youell.com/matt/writing/?p=898 <comment><USER2> 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.

<comment><USER3> 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.

<comment><USER2> 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.

<comment><USER3> _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.

<comment> 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.

<comment><USER4> > 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?

<comment><USER5> 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.

<comment><USER6> _"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.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> 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.'

<comment><USER8> 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).

<comment><USER9> I've gone to meetups, gotten business cards, but my emails just ended up going into a black hole.

</comment></comment></comment><comment><USER10> 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.

<comment><USER11> 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.

</comment></comment><comment><USER12> 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!

<comment><USER13> 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.

<comment><USER12> 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.

</comment></comment></comment><comment><USER14> 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.)

</comment><comment><USER15> 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.

<comment><USER16> 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?

<comment><USER14> 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.

<comment><USER17> 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)

</comment></comment></comment></comment><comment><USER18> 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?

<comment><USER19> > 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:)

<comment><USER20> 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

<comment><USER19> > 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.

<comment><USER20> 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.

</comment></comment></comment></comment></comment><comment><USER21> 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.

<comment><USER22> 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.

</comment></comment><comment><USER23> 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.

<comment><USER18> 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.

<comment><USER24> 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.

</comment></comment></comment><comment><USER24> _"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.

<comment><USER25> 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."

</comment></comment><comment><USER26> 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.

<comment><USER7> 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...

</comment></comment><comment><USER27> 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.

</comment><comment><USER28> 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.

</comment><comment><USER29> > 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.

</comment><comment><USER30> 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.

</comment><comment><USER31> 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.

</comment><comment><USER32> 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.

<comment><USER20> 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.

<comment><USER32> Of course. I'll feign the love for it.

</comment></comment></comment><comment><USER33> 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.

<comment><USER34> > 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.

<comment><USER35> 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.

<comment><USER33> 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.

</comment></comment></comment></comment><comment><USER36> 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.

<comment><USER24> I recently got the question, "explains what happens when you type a URL into a browser."

<comment><USER37> Typing it in isn't really that interesting... but when you submit, now that's when the magic happens.

<comment><USER24> Believe me, that answer was the first thing that came to mind. "With or without the enter key?"

</comment></comment></comment></comment><comment><USER38> 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"

</comment><comment><USER39> 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.

<comment><USER27> 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.

<comment><USER40> 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).

</comment></comment></comment><comment><USER41> > 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.

<comment><USER20> 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.

</comment></comment><comment><USER42> 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?

</comment><comment><USER43> "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.

</comment><comment><USER44> 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.

</comment><comment><USER6> 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.

</comment><comment><USER45> 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.

</comment><comment><USER46> 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.

</comment><comment><USER47> 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/>

</comment><comment><USER48> 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?

<comment><USER49> 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.

</comment></comment><comment><USER50> I love that he just assumes people know the Heinlein quote. ("Specialization is for insects.")

<comment><USER51> I did not know what it was, and i am glad you brought it up :)

</comment></comment><comment><USER52> 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.

</comment><comment><USER53> 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.

</comment><comment><USER54> "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.

</comment><comment><USER55> 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.

</comment><comment><USER56> 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.

</comment><comment><USER57> The biggest thing I took away from this is that you should treat potential employees like employees.

</comment><comment><USER58> 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.

</comment><comment><USER59> 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.

</comment><comment><USER60> 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

</comment><comment><USER61> 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?

</comment><comment><USER62> 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.

<comment><USER63> 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?

<comment><USER62> 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.

</comment></comment></comment><comment><USER64> Can someone explain what a "resume wall" is.

<comment><USER17> 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)

<comment><USER64> So it's like a firewall but for resumes?

</comment></comment></comment><comment><USER65> 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.

</comment><comment><USER66> Cash, lots of cash!</comment>


Intel and nvidia sign $1.5B cross-licensing agreement - <AUTHOR> http://arstechnica.com/business/news/2011/01/intelnvidia-bombshell-look-for-nvidia-gpu-on-intel-processor-die.ars

<comment><USER2> Unless nVidia changes its policy and starts releasing documentation, this will be bad for open source and bad for security.</comment>