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.

Here's why you don't see question one answered honestly:

A. Our sales guys sold our product based on feature "Foo" a year ago. We haven't started coding but they need a demo next week. You have to grok our codebase and write it on your first day.

B. The 'Bar' feature was written by a guy who should have failed finger painting, but we don't have time to rewrite it. You have to fix the many patches and modifications it's had since.

C. The 'Zap' feature was written by our cowboy programmer. You have to do all his bug fixes and modifications because he thinks he's too important for anything but new code.

If I need more than that, then I should probably simplify what I'm writing, or use more descriptive names.

When hiring engineers (or speaking to any anyone ever again) NEVER use the word 'grok.'

I'd have to find some other way to climb your opinion ladder ;)

A second question then is why did they ask for an NDA then, and the answer is "company policy". I have refused to sign such NDAs, and they have refused to interview me then.

Interestingly here is something that has worked: I have signed such NDAs with my annotation saying something like "It is mutually understood that this NDA is null and meaningless" right above my signatures, and they do not have any issue with that. Well, as far as I "signed" the NDA per the company policy!

This has been the case with several big name companies I have interviewed with.

[1] Not making fun of you here, rather of the companies and bureaucracy.

No need for the rest, this will do.

Actually, in all seriousness there is at least one start up here in Germany which hiring process consist in going for a beer with the founders and members of the team you'll work with, and only follow up if you liked each other. It's probably not very scalable for the founders as the company grows, but still an interesting approach.

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.

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.

Also, you seem to have a specific kind of company in mind. Your questions fit a new web startup but I can't imagine how Google (or a Wall street bank, accounting firm, consulting firm, etc.) is supposed to tell you the three biggest things they need to accomplish and when they're due. Lots of places are just looking for smart developers because there's lots of things to do rather than looking for somebody to fulfill a specific task.

Some companies have great high-level vision but terrible low-level infrastructure/culture and vice-versa. If we had to choose between the two, I suspect the two of us would make completely different choices.

That. If you are that company, I don't want to work for you.

You have to have a mission. The big hairy audacious goals guide your week to week work. If they don't then "You're doing it wrong".

If you don't know what I should be working on, then I am unlikely to be able to move you forward in a meaningful way. Sure, Google as a whole may not have a "thing" for me to work on, but each department will have it's key thing... again, if they don't, what the are they adding to google? Is my job secure? Or will I get axed in the next product that doesn't serve to organise the worlds information?

Hiring for general problem-solving ability means being able to rely on the same already-meshed team of people for your next big hairy thing.

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.

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

This... is actually kindof interesting. See, I would see it the other way around. Working conditions are real things that effect me day-to-day.

My experience? usually when you go work somewhere, your /actual/ job has absolutely nothing to do with what you got interviewed for. All this talk about 'the problem the company is trying to solve' is, well, marketing bullshit.

Hell, if you are hired on early, the people running the company don't (actually) know the answer to that question beyond "make enough money to cover payroll."

If you are hired on late, usually, your job is to do what your managers want, not to try to do what the company needs. Usually, if you do the latter, you will spend all your time in conflict with existing management structures.

I mean, part of that is that people are stupid, sure, and everyone wants to protect and grow their little kingdoms.

But part of that is that even if you really are as good as you think you are at your role (and most people aren't) you don't know everything.

I know that as a young sysadmin I got into a bunch of fights with my boss about how to do things. Now that I have my own company? my employees sometimes get into fights with me over the exact same things. I mean, now that I've gotta look at it from the business perspective as well as the technical perspective, I can see where my boss was coming from way back when.

So if you want me to code something for you, supply me the required hardware for it.

And no, you can't hack on whatever hardware.

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?

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.

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.

Well, yes. As a non-equity employee, why should you care about "them", other than how you'll come out of working for them five years down the line? Will you have enjoyed your time there? Will you have grown as a developer?

"Creating something meaningful" only only really affects the lives of employees inasmuch as they now have something out there in the world that they can point to and brag about. That's not really as important to most people as you'd think.

The ones that it is important to? Too busy being entrepreneurs. :)

Because when you work at a company you don't care for, you are contributing to a toxic environment, which can hurt your career prospects much more than a sub-par salary, by making you caustic and bitter. If you come out of a job in anything other than high spirits, that will subconsciously, but seriously, hurt you in your hunt for the next job.

For example, the startup I left - I slogged there for 4 years and I left because of some leadership changes(pressure from VCs), heck I had to leave without taking the stock options because of some technicality. Yes, I am bitter about them but out of those 4 years, 3.5 Years were incredibly fun and I learnt quite a bit. I think story repeats everywhere.

That's where I work. And I wouldn't give it up for these fast paced do-or-die startups. :)

It also sucks if you need to make the occasional personal phone call, or if you feel the need to pick your nose, etc., etc.

I just don't think a company is going to answer many of these questions. They might think you are a spy for the competition :).

6. Architecture, TDD, code

7. 8 hour days, but available in emergencies at night.

P.S. (The secret is that good and cost are not in direct correspondence across the population of Chinese buffets.)

I've had so many bad experiences with Chinese buffets that I steer clear of any place that would suggest that.

Of course, we take all our candidates out for Chinese food these days, but its kind of expected since we are in Beijing. Sometimes its difficult dealing with some foreigner's dietary restrictions (orthodox, vegetarian are hard; halal is quite easy).

"Don't ask the fish about the water," and all that.

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

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

You don't need to be famous, not even close. You did get it right though - you do have to know people.

Finding your next job is something you should be doing before you're actually thinking about leaving your current one. Go to meetups, look up interesting companies in your area and make yourself known to them - you'd be surprised how many people are willing to chat even with the knowledge that there's a 0% chance of you jumping ship in the foreseeable future.

It's not only a great way to get your name out there and make a few contacts, but it's also a great way to find out what's happening in your local tech community.

It is also necessary. In my experience the best employers and the best positions fulfill primarily via word of mouth. By the time a job hits a major job site it means the employer has already failed their first-choice option (i.e., a known referral by a trusted entity).

Yep. Bilateral mismatch. Here's the dirty truth: people don't actually care about talent or even how good you are at your job. They just want to get a mission fulfilled. That'd be fine, with competent execution-- hire the right kind of person, get it done and done well, make your money and move on to something better. The problem is that it seems that 90 percent of them have no clue what they want or how to evaluate the relevant talents, and there's a hardcore Design Paradox effect going on as well.

By the way, I'm pretty well-known at this point. I'm probably in the 96-97th percentile for programming skill and 99th for loudness. It makes job searching easier to be "a quantity" and I'm finally getting to a point where it opens up some great options... but I've still dealt with a lot of frustration. It's nothing to be ashamed of.

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.

This is a problem in stodgy bureaucracies and VC-istan. In the former, it's because in Douchebagland, one's value is based on how many reports he has-- not what those reports actually do-- so bringing in marginal people through dishonest means improves the boss's resume. In the latter, it has more to do with the way companies are valued by investors and acquirers-- some $X million per employee.

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

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

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.

Issue one for me as an interviewer, whenever I've needed to be in such a position, was just to figure out whether or not I was talking with a programmer.

After that though I tend to agree with you. Beyond demonstrating basic competence - which I think in the future I will look to put into some for of pre-interview screening - code writing tests don't do much.

Personally, I've found bringing my current work in with me and talking about different ways of solving the issue seems to work pretty well.

I also struggle with that idea since I'm very capable of programming fizzbuzz and a lot more, but am still having a problem finding a new position.

Actually, if I went purely on personal experience it would be closer to 90%. I tempered it because I can't believe it could be anywhere that bad.

It's sad, but from what I've seen, applicants fall into two major groups, for the most part:

1. People who seem to know how to code (as in, actually use a keyboard) but who don't possess any type of critical thinking skills and can't actually figure out how a piece of code can solve a real world business problem - or even care - unless you tell them exactly how it should work. These people tend to live in big corps and stop coding completely at 4:59 everyday.

2. People with computer science degrees (the more the better) that can think up wonderful and complex solutions to the most basic of problems but can't seem to figure out a syntax error, or understand that a landing page does not require a $40K investment in the latest oracle database software, or that it doesn't matter how wonderful their design is if nobody can figure out how to use it, or that yes, it was more important to have it out last month than it was to make it run 30% faster.

Both of these hires are disasters. Unfortunately, the third group, the ones that can understand what a user is saying, design a simple way to achieve the goal, and where appropriate link it to other related features in a meaningful way, are few and far between. Most of them are working in small shops and never have the need to apply for a position via interview, since they get scooped up on reputation before that.

Otherwise, I think you're largely right. But there's a lot of variation especially within that third group. I'm going to cautiously put myself into that third group. The problem is I'm probably on the lower end of that category. I'm able to make design decisions and use the things I learnt in computer science classes while still being pragmatic and solving real world problems. But I don't have a ton of experience. I often don't have language X or framework Y under my belt. And I think that's made it really difficult for me.

You seem to have a good idea of what you should be looking for, but what about all of the other interviewers? Are they just incredibly short-sighted?

And if the fizz buzz failures are actually that prolific, then I'm really at a loss as to why I'm having such a hard time finding a position.

Want to exchange e-mails and chat about it?

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?

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

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)

I think far more people use whiteboard questions in that context than the article's author thinks.

" If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade."

I don't know about your experience, but in my experience candidates actually ask questions if you properly set up the problem and present an inviting atmosphere. And in my experience the best programmers are those that aren't afraid to ask good questions.

None of your alternatives "algorithms? Concurrency? Databases? Testing?" really test language facility. Those are important, and they have their place in the interview process, but so does language awareness.

And anyway, what better test of language facility is there than having the person code something? Or looking at code they've written? Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild.

"Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild."

You don't use a whiteboard when you code? I love them. The whiteboard is a nice tool for doodling and free exploration. I used to print out code and write on it, but I found that process to be much slower than the whiteboard.

No, I don't. I find them very uncomfortable to write on, and when I have to, I thus try to write as quickly as possible, resulting in messy lettering and not caring at all if I get every (or any?) semicolon in, just so long as I get ideas across.

I suppose if I had to use one in an interview I would try harder to write neatly, but my real-life day-to-day use of whiteboards is minimal.

So? I use google all the time while coding.

And what's wrong with that? I use google several times/day to help out with programming problems. This is 2013; if your company doesn't have access to the internet (and thus Google) then people aren't going to want to work for you anyway. The problem is you're trying to set up some kind of artificial situation where you want people to solve a problem without access to readily available information.

Sure, you could have them sit down at a computer that you've unplugged from the network and have them solve your problem, but why bother?

Would you hire someone who has to google for an answer to fizzbuzz?

No, but there's very little utility in someone solving fizz buzz with or without google. Give them a real test and let them use google.

But I think there should also be a real test, with Internet access available.

I had an interview several years ago. Talking with the owners, small shop (6 people? 8?). We get to a "let's code something on the white board" segment. Fair enough. "Write me some code that does XYZ" (I honestly don't remember what it was - something basic but not trivial).

I took the marker, went to the board, put the marker to the board, then turned around and asked a couple questions. They answered, I sketched out a few lines of code, and that was that.

I sat down and one of them said that I was the first person ever to ask a question before writing. Everyone else had started writing, got part way through, then asked for clarification on the ambiguous parts (or worse yet, never realized part of it was up for interpretation).

Everyone handles whiteboard tests differently, but it was interesting to me to get that perspective shared with me about asking questions before writing on the board.

I always assume that part of the evaluation is on my ability to resolve ambiguity, and always try to clarify anything I can, sometimes including writing out an example or two and verifying we agree what the expected output should be.

There ARE contrived problems that you can just regurgitate an answer for. (Why are manholes covers round? Because manholes are round duh!) And if anyone asks you one from the lists that are on the interwebs, they're probably just asking because that's What Google Does

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?

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

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

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.

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

Is this really true? I think if you turn it around you wouldn't agree with it so readily: if a person can blow your socks off in 5min, then you can predict how the rest of the interview will go." Well then why have the rest of the interview, or if the rest of the interview is still necessary, why go through the 5min pitch rigamarole? Why not just shave those 5min off the whole interview? Why not send the candidate on their way after they don't do their pitch-intro well? These are all rhetorical questions, but you see how I'm following the logic in your statement. I'm not judging either way, but hey, could it work any worse than the processes elsewhere described?

Heck, I wonder how a company would do if they gave the candidate 5min for whatever with the significant coworkers of the position, then take a vote from the interviewers and just hire based on the victors. Interviewers can do culture or technical interactions, doesn't matter, if they feel good about the person then they vote to hire. I guess it's like Speed Dating this way, but still.

It will never stop.

"Do you really need to screen me with a phone interview?"

Meh... I'm kinda split on that part of the process. I understand the frustration, and too often it's wasted time that doesn't gain anything you couldn't get from the CV itself. If done right, it can tell you if the other party is good at verbal communication, which is an important skill in its own right.

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.

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.

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.

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.

Unfortunately, the number of flat-out liars on resumes is extremely large. Heck, I've even seen resumes from people I worked alongside at Microsoft who now claim to have done things that I did while there. <shrug>

Sussing that out is part of the interviewer's job, at least if you care about 1) whether you're hiring a liar 2) the skills that should have been gained if they actually spent two years working on X.

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.

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

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.

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

   STARTUPS: STOP USING RECRUITERS!

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

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.

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

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.

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

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.

In what universe is this true. I don't want to imply anything but I feel like maybe you're not sure what "buyer's market" means. That would imply that employer's have large pool to pick from an those looking for a job are essentially lucky to find one. I don't think you meant that ... I'd hope if you are really in charge of hiring people you wouldn't think that because, I feel perhaps you wouldn't be the right person to be in charge of hiring due to not recognizing what is happening in the world at this moment (3/23/2013). :(

On a side note, I hear the thing about FizzBuzz a lot. I find it, personally, hard to believe that it is common for someone to pass an interview that probed to any depth, pass with flying colors, and not be able to code FizzBuzz. I would think the person directing the conversation was not doing a good job.

And the ++i vs i++ .. that's pretty basic stuff, I get that that's potentially part of your point, but that is just silly stuff.

People are still afraid of losing their job. Some people have been under-employed for a long time, now, and are settling for jobs they previously left in distaste. A lot of people feel stuck.

Let me try to rephrase it - there are entrepreneurs, there are people who will accept a lot of risk... and then there are people who feel they cannot move, have a low tolerance for the imagined future pain of being unemployed, worry about the housing market, worry about losing insurance... and when they are unemployed, they stand in line to try to distinguish themselves to the large companies that are nearby, so they can get a stable job.

Heck, I know people with advanced degrees in their fields who have accepted Internships just to have a paycheck.

There's no lack of smart people who will work hard at a stable job, and consider themselves lucky to get an offer for the positions at the companies I've worked at.

If you accept candidates who are not citizens (H-1B), I find it hard to believe that ANY of you have a hard time finding candidates. If you're open to telecommuting, especially.

At the companies I've worked at, the evidence has been very much on my side.

Maybe I've just taken for granted how desirable the companies I've worked for really are.

It's a buyer's market where I've worked for my last three jobs.

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.

I repeat my earlier declaration that I loved candidates who didn't know the answer, but could have a good conversation about the question.

A cookie-cutter interview will ask things that I've been asked by every other shop in town. For instance, I literally recite Fibonacci now. It's a completely useless test because it's over-used. This sort of thing makes a company look cold and - far worse - unimaginative. It's not insulting, it's just a red flag.

The other part of this is having people stand at a whiteboard or work on paper instead of sitting down with them at a computer. Every single thing you listed can be determined by sitting with the candidate at a computer, working with actual code.

None of this bars you from asking about historical quirks of compilers or anything else. If anything, it offers you the chance to have a more relaxed conversation about these things so you can get past the bullshit and see the person that you'll actually be working with.

I actually printed out about 20 sample bits of code, and discussed that. I worked with people on the Image Processing / Computational Geometry side who would set up a programming challenge with a compiler, and I respect that, too.

On what planet?

If it were easy to find programmers, you wouldn't have all these shops using spam-tactic recruiters to drive volume. They wouldn't need to.

It's most definitely a seller's market, if programmers can take their pick of corporate gig | freelancing | startup. My last job hunt took one hour. Their search went on for two months. If they fired me I could line up a dozen interviews next week, they'd still have to wade through a sea of unqualified/foreign/unmotivated alternatives.

It's not that I'm that good, I'm an entry-level Ruby guy working in a .NET shop. I interview well, but they interviewed a dozen guys before me. My job offer came the same day as the interview, after a token 4 hour wait. It's not that they were being overly selective, the pool they were fishing in was just that bad.

I don't know where you're getting the idea that it's a buyer's market for programming talent.

From my experiences, it is very circumstantial if you hit the ground running in a week like you said, or just get stuck in a mile of resumes, 3 week delays between responses with anyone from a 5 man startup to Amazon, and I think it is all about the network / school / area you are in. Besides being good, which I'm not either - that is kind of the golden ticket to glory.

And I mention recruiters only because it will open your eyes to the possibilities. Much better, got to any of the many free meetups (check the "NERD center" calendar) that happen almost daily and you will find plenty of like-minded introverts to talk code and network with.

Whether or not you're actually good, I of course don't know. But don's sell yourself short. Take a shot. I did about five years ago and it was like being fired out of a cannon. Good luck to you.

I think those are unrelated concepts. I think connecting with the right pool of talent is an art, and a lot of shops are completely artless.

> It's most definitely a seller's market, if programmers can take their pick

Maybe I've been lucky, but I've never worked at a company that felt like we couldn't take our pick of applicants. Especially the lower down the scale we went.

> My last job hunt took one hour.

I have applicants for positions that don't exist. My applicant search takes negative time.

> If they fired me I could line up a dozen interviews next week

If someone quits, I can line up a dozen candidates next week.

> they'd still have to wade through a sea of unqualified/foreign/unmotivated alternatives.

Every day, you make judgements about which companies would be fun to work through - you're always doing that background processing.

> they interviewed a dozen guys before me.

So, as a Buyer, they had a line of candidates applying. Most of their problem was probably announcing to the world that they had an open position that people should know to apply to. That sounds like a Buyer's Market to me.

> I don't know where you're getting the idea that it's a buyer's market for programming talent.

The length of time I've seen open positions sit unfilled, and the number of applicants who'd be qualified to fill it.

In any market, a good that's sufficiently - well - "valuable" - will be picked up in no time. Congrats on crossing that threshold, I guess.

But yes, I consider it a Buyer's Market.

The software industry is highly bimodal. There are two very, very clear camps - you fall into the other camp than most HNers.

The market for mid-top end talent is a huge sellers market. There aren't enough people to go around, salaries inflate double-digit percentages every year, and crazily does not seem to be stopping.

The market for low-end warm-body coders is a huge buyers market. There are more clueless VB coders than there are seats; many, many more.

Do you, by any chance, work for a consultancy where innovation, code quality, or engineering excellence aren't exactly high up on the list of priorities? This may explain your glut of candidates - whereas on the other side of the industry fence companies are offering six-figures to fresh graduates and creating bidding wars around entry-level applicants?

Then when you finally answer the ad, you'll be so far inside the person's head that it will look like God himself sent them the PERFECT candidate.

You need to be patient and to sharply cut down on the number of ads you're answering. So pick the good ones, the ads that look like they were written by engineers. The ones where you can see the thought processes of the people hiring.

In my job search, I sent out exactly one reply to exactly one ad, to the company that hired me.

-“What kind of work do you do?”

-“I do this, this and this. I just graduated and I'm hoping to find some work or freelance gigs. You?”

You've touched on one of the most involved and complicated questions in our industry. There are many qualified coders stucks on proverbial other side of the fence for no good reason.

The short answers, for me, is blind ass luck. I did well in high school, stumbled my ass (unintentionally) into what turned out to be a prestige school, stumbled into some interesting internships with well-known companies, and as a result attracted the attention of one of the "A-level" tech employers, whose name on my resume put me on the correct side of the fence (the employer is Amazon, btw).

It's not just the resume effect - being in said companies also puts you in a network of people already in the camp, which opens up networking and job opportunities also.

Being in the right camp is a self-reinforcing phenomenon. You get jobs at a particular level, with a particular type of employer, which in turn attracts more of that sort of employer. Unfortunately, the inverse is also true - if you're outside the camp, you attract the other employers, and your resume begins to look less and less like a resume from within the camp.

None of this particularly helps you, even if it does explain why you can't seem to get into the camp.

Here are some tips - but keep in mind that I've been in the camp from "the beginning" (i.e., right out of school) so I really cannot vouch, first-hand, how well these will work for you.

- Network more. A lot more. Look at technologies being used within the camp (Rails, Node, etc) vs. tech being used outside the camp (VB.NET, JavaBeans, etc), and learn according to where you want to be.

- Go to developer meetups hosted by companies/individuals in the camp. This community maybe small in Philly, but I'm certain it exists. This will reinforce both the learning and networking parts of above.

- Go to events in New York City, which is the closest tech hub available to you. There are events held all the time - hackathons, conferences, etc. Go, learn, make friends, network.

- After you've done this a few times you've probably collected at least a few cards from interesting companies. Hit them up, see if they're hiring, or if they know anyone hiring. Considering the severe, ridiculous high-end tech shortage in NYC, you will get substantial hits.

- Consider also traveling to NYC and crashing an AirBnb for a few days/week. Companies are a lot more receptive if you can talk to them face to face. If you can line up a few interviews beforehand, even better.

No, but it will give you just enough capital to move somewhere better. And you'll be working on your social skills, which is a big win for anyone.

Choice isn't all there is to it.

Let's say you're at a grocery store to get onions, but all the onions you see are terrible but really cheap. Being a discerning buyer, you decide to hit the next store. Same there too; more crap onions. It's like this at the next three stores. Finally you get to a store with decent onions, but they're 4x the price of normal onions. You, starved for choice and not willing to shop any more, despite the glut of onions, grab one and go home to make dinner.

This is a classic seller's market. The sellers with the goods command premium prices because there aren't that many of them at the quality that the buyer wants. Lots of crap onions to pick from, good ones are ridiculously expensive.

A buyer's market would be the other way around, there'd be lots of good onions, so you could get them at bargain rates.

I also think you might be misreading the fact that the company you work for is letting open positions sit. What this effectively means is that the workload hasn't gotten to the point where they have to take the next person that comes along. They can still afford to be discerning. If it goes on like this the workload will either get worse, at which point they will have to take the first guy that comes along, or they'll just stop looking, deciding they didn't really need a new guy. Both outcomes are exactly what happens in seller's markets, the buyer eventually gets fed up and takes a sub-par deal or walks away.

I think when you look at the DJIA, companies really are getting developers at bargain rates.

How much revenue do you think the top 30% of software companies are earning, versus how much they're paying their top talent?

> I also think you might be misreading the fact that the company you work for is letting open positions sit.

They're not - they're filling as quickly as we want them to. That's a Buyer's Market.

Why do you feel it's necessary to waste a candidates time by having them apply for make-believe vacancies?

There's an excluded middle here, where the ability of a company to choose correctly (avoid false negatives) is not a given, and that they are filtering properly in the first place (as I mentioned of a rockstar-seeking YC company elsewhere in this thread).

I don't know where you live, but where I live, there is NO market for programmers.

So "foreign" is in the same category as unqualified and/or unmotivated ? WTF ???

Basically, the more specialized you are, the more brittle your situation is. I also happen to be an immigrant, which together with the specialization means that for any given city, there might be 2-3 employers I can apply at tops. My plan going forward is to basically abandon my specialty in favor of a more common/in demand skill set.

Interesting choice of words ...

Foreign: On their ad, they specified that they couldn't sponsor H1-B Visas, because they had a lot of replies asking for that. They didn't want to deal with a language barrier.

Unmotivated: I learned after I took the job that of those applicants that weren't A or B, the rest of them really wanted to work in games. They decided against hiring them because they were worried about the guy jumping ship as soon as a game job opened up.

I was the first guy they interviewed that didn't have any of these hangups, and jumped immediately on me, despite having no real previous experience with C#, .NET or other C-like languages. They offered me the top-end of my salary request range. I had nothing to negotiate. I can't imagine this having happened in anything other than a seller's market.

Maybe I've been fortunate enough to work for companies that had enough gravitational pull that we attract good candidates without trying very hard.

Outside of the tech hub cities, yes, it can be very hard. Even just an hour out of Philadelphia, helping a local company offering $95k salary and benefits (well above average in their area), there were very few applicants and fewer actually qualified to do any professional programming. It took almost a year to fill a single developer position.

Programmers are a rare species in most of the country. My CS graduating class a few years back was probably 30-40 people and, having worked with many of them in various classes, many were completely incompetent, having only passed by copying and pasting or sharing code. The entire country graduated less than 10k people from CS programs in 2010.

I work for a NYC startup that has hired Philly residents in the past - either remote or remote-occasional-commute. Geographic salary fences are falling, and falling quickly - may I suggest $95K is below-market? Heck, around here $95K is below-market for a good, fresh undergrad.

I've gotten into a debate with some friends about this: a degree on a resume is really great, but it's not necessary for the vast majority of programming jobs.

> helping a local company offering $95k salary and benefits

I hear that driving a truck in the North Dakota oil boom can earn you $150k, to start. Even in a Buyer's Market, you have to offer a realistic salary.

> well above average in their area

Average what? Average programmer?

> there were very few applicants

How did the company find candidates? I feel like a lot of companies expect applicants... This is like expecting the phone to ring and having someone ask you out on a date. Putting your profile up on Match.com isn't much better.

If you want to hire people an hour out of Philadelphia, have you considered training people who live an hour out of Philadelphia for the job?

Again, I've said this a few times, maybe I've been very fortunate to work at companies with enough gravitational pull, because we work hard to make sure people know they're supposed to apply. But since we've put that effort in, we have overly-qualified applicants lined up for openings that don't exist.

> many were completely incompetent

You just told me that CS graduates can still be completely incompetent, but then you expressed surprise that apparently degrees don't matter that much any more. =)

In his defense, and as a recent grad with my CS degree this last year, the curriculum doesn't really sell itself at all for professional software development. Knowing algorithms / language theory / OS theory / theory in general doesn't mean you can throw together a Django app or use git. I had to learn those outside the classroom, because class projects were about convex hull and Monte Hall, not making useful software.

In 9 months since graduating I've gone from my favorite language being C, my experience being in Java and a smidgen of Swing (and still an incomplete knoweldge of the Java thread model, how to write for the JVM, and some others) I did know some CUDA / pthreads / openMP but from an elective on parallel systems, I had a touch of Python 2.7, and almost no sysadmin experience, to now my preferred language is Python3, I know and use qt for FOSS work, I learned html / javascript / C# / regular expressions / SQL / proper networking / the kde libs / pyside / simpy / numpy, I switched full time to Arch and learned Unix ground up, I learned about assembly, unicode, byte order marks, etc.

I never touched on any of that in school. Given, my school was a mediocre liberal arts place I went to just for the near-free scholarship, but I get the impression from other schools I encountered during ASM contests that the curriculum was similar.

Oh, I completely agree. It's a Liberal Art, essentially. As opposed to a Trade School. I'm a huge fan of a liberal arts education, and I think the background of a Computer Science degree is fantastic, but I can't lie to myself that it's necessary.

I think the future is more mentorship, and once someone is a bit established in their career, that they will take continuing Liberal Arts education to improve themselves.

those liberal arts places... :-)

It was a class project my freshman year. I already knew the probabilistic parts to it from junior statics in high school, so I was bored out of my mind.

This can happen in a seller's market if people with jobs are in such demand that they can try to create the position they want.

Maybe I'm just not looking in the right places. I'm absent a network, so I'm just using online job boards from Careers 2.0 to Dice to Linked In, and I just don't see anything.

If you feel that you've tried this and you can't find anyone, I see two options: 1. Establish these relationships online. HN is a good start. There's also no shortage of good software developers writing blogs. Interact with a few that you really respect. Comment on their posts. Connect with them on LI and Twitter. Email them. Taking it to a personal level where they'll feel the desire to go out of their way to help you could be difficult, but it's possible. 2. Move. If your present community truly is devoid of people you respect who would be willing to mentor you in some way, you need to switch it up and expand your circle of potential colleagues.

Some of the programmers in my team are fairly high profile within the community, but what they've been reporting back from conferences and meetups is "dude, half the people are trying to hire the other half..."

If, conversely, a candidate asked me the questions edw519 listed above, you'd pretty much be guaranteed a job. I don't care how well or badly you program. I don't care whether you know Boost or not. I want to know whether you'll fit in here. Ever read Peopleware [1]? There's a great example in there on why you should value the programmer that seems to deliver nothing of value, and yet makes the team gel.

If you don't know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result, hey, that's ok. Are you giving me the impression that you like programming? That you will try and find an answer yourself before coming to ask for my help? If I ask you a question that you can't answer, do you bullshit, or do you say "Hey, I don't know, but I'll find out and email you the answer tomorrow."

The character is far more important to me than your ability as a programmer. The former is a fit, or it isn't. The latter I can work with. Because it's a long game.

[1] http://www.amazon.co.uk/dp/0321934113

I'm confused. Is it normal for an interviewee to ask the interviewer a tricky technical question at some point of a job interview now? Am I reading this correctly?

Do I know it exists? Sure, of course. Have I used all of the 50+ libraries in Boost? nope. Maybe about 10% of them. What exactly do you mean by "know Boost"?

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

You can also have a look at my GitHub where you can read actual code I have written and see how I've handled pull requests, bug reports, etc.

I get applicants who claim they're C++ experts, and they've never cracked Boost open to look for anything good, and they've never heard of TR1 or anything that followed. I'd like to have that discussion with a candidate. That's all I meant by "know Boost."

> You can also have a look at my GitHub

When I can do that, it's awesome.

Many candidates have been work-for-hire their entire careers, in states with Non-Competes that are either enforceable or people are afraid their previous / current employer might try to enforce it. I don't hold a lack of a GitHub account against someone.

It's a "Buyer's Market" right now for average talent. And honestly, most start-ups only need average (competent) talent.

But if you need above-average talent, there's a perpetual shortage. Speaking from experience (and I'm NOT a name you've likely heard of -- I'm just a generalist who is good at low-level through high-level code and API design and have a resume that reflects that), once I get through a technical interview with a company they usually are inclined to make a position for me, whether or not they previously had one available.

And by "usually" I mean that I've gotten a job offer from more than half the companies I've ever interviewed with. Feels like a Seller's Market to me, and has for 20 years (with the exception of the 6 months following 9/11 when most of the US was in shock).

Step outside the HN bubble and you'll know that this business is still seriously fucked, and not getting any better. The only thing that has improved is that many of us, both employers and developers, have gotten better at isolation ourselves from it.

We maintain our own little bubble of online communities, conferences and meetups (always the same faces right, never the other 90%) so well that we actually think tech is getting better.

Until you start seeing the CV's and talk to candidates from "outside". It's depressing. I wouldn't call that a "Buyer's Market" when it's almost uniformly shit.

And it has been that way for as long as I can remember. For the 25+ years I've been in this business any decent programmer can take their pick of offers withing a few weeks, crisis or no crisis.

It's a Seller's Market if you have something to offer. Always has been, at least since the 80's.

But I have seen CVs of people "outside." Heck, I've accidentally become an expert at fixing people's broken code, or porting crap code from one platform to another. I've SEEN how bad it gets. (And as I type this, I'm procrastinating from porting some code from one platform to another that I'm surprised works at all -- oh wait, it actually crashes All The Time. Sigh.)

And I know that even THAT work is filtered so that I only see the code written by people who eventually got something to run at all.

Oh, I know how bad it gets. In part it's why I've gone the consulting route; there's no way I'd be adequately compensated working as an employee anywhere. By at least a factor (divisor?) of two.

But you have to figure that all of those people who suck are still developers. Professionally. And some of them have been for 20+ years. So someone must hire them. At least sometimes. And that means there's a market for them. And in that market, I continue to assert, is a buyer's market.

Now it's a market I have no interest in shopping in. I assume all of these people end up in huge companies that can afford to have people who barely know what they're doing. But someone must hire people from that crowd or they'd give up and take blue collar jobs. Everyone has to eat, right?

But yes, you and I and a large fraction (at least) of the HN crowd live in the Seller's Market.

I know it's cliche to suggest, but learn by doing. You need to think about what you're doing, of course. Otherwise you're just doing things by rote.

One thing I love to do when designing an API is to write pseudo-code that is using the new API, before I even start to design the API itself. Just think to yourself, "What is the exact call I want to be able to make?"

That call probably doesn't have a dozen parameters, or 15 lines of set-up. It has the minimal information you need to get things done.

Oh, and one other trick: If anything EVER annoys you about an API, decide to fix it rather than putting up with it. I don't care if it's NOT "your" API to fix; wrap it with convenience functions if necessary.

Good luck.

Someone fresh out of school should expect to jump through hoops.

A company that's looking for senior developers who've Been There, Done That, should expect to have to empower, reward, and listen to them.

But senior developers really need to understand that there are Chameleons among them, who have floated from job to job, look like they have all the right skills, but can't perform.

Companies need to be able to distinguish those Chameleons from the real deal, and I have found that Cookie-Cutter Technical Interviews are a necessary step. I think I've kept out more Chameleons than I've lost good candidates. Or rather, I've determined that it's worth administering the Cookie-Cutter Technical Interview, because I've concluded that the cost of hiring a Chameleon is higher than the cost of making one of the many honestly good candidates walk away in distaste.

I also have to emphasize how empowered, rewarded, and listened-to the candidate will be, and that they'll be surrounded by other senior programmers with great skills that they'll have fun interacting with...

However, I am curious what you mean when you say that it is a buyers market. From everything I've read, there is a shortage of development talent, so those "selling" their service as programmers have the edge. Doesn't that make it a seller's market?

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.

People who ask common/simple insert language/framework here interview questions are sometimes looking to see if you at least minimum care enough to memorize the answers. Alternatively a sideways answer might work, like "I find that's no longer necessary since..." or "I'll be attending a 3-day dev conference that includes that topic..."

That said, it makes it look like they don't care enough about interviewees, when they put so little effort into the questions asked. To hire a skilled programmer, you need to present yourself as a skilled interviewer.

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

The absolute worst place I ever applied to required to you upload a version of your resume in Word format. After you hit submit, the next page wanted a plain text copy. Then, I bullshit you not, the next page was a web form in which they requested you fill out educational background, work history, references. Something you just uploaded twice!

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

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

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

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?

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.

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.

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

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

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.

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

1) contribute to some open source project.

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

3) job offer.

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.

"I've been surprised and pleased by how well Visual Basic .NET works for Web page development on Microsoft's Internet Information Server (ISS)" - Jesus Wept.

Your concerns are that I'm on Windows instead of Linux, not using Visual Studio, am using Visual Basic .NET instead of C#, that I didn't just criticize Microsoft but found something in their work I like, or something else?

Me? I've never touched Linux, tried Visual Studio in total for less than an hour, have not looked seriously at C# and so far have yet to write a single line of it, and do have some objections to some of Microsoft's work. Still, as I wrote, "I've been surprised and pleased ...".

If you have some concerns, then cough them up.

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?

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

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.