Hacker News new | comments | show | ask | jobs | submit login
How To Hire Me (or any other programmer) (youell.com)
346 points by softbuilder on Mar 22, 2013 | hide | past | web | favorite | 250 comments



How to hire me:

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


(The following is made up and CERTAINLY isn't for the job I currently have open for a senior PHP dev in Melbourne.AU)

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.


Your 'Zap' is bothering me. What happened to Baz?


It got reversed, then b spent too much time looking at a mirror pond.


What comes after baz? I've seen some use quux but having 4 letters bothers me



I tend to go Foo, Bar, Baz, Fizz, Buzz, Bing.

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


Useless weekend project idea: a tool to automatically fork random repos on github and replace all variable/function/class names with one of the above much superior terms.


Tip:

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


Why? It has a more clear meaning than just 'understand', and a 'huh' response should be a pretty good filter for an unsuitable candidate.


People who use grok properly in conversation move up a rung on my opinion-o-ladder.


While the term is firmly established within the jargon (and with good reason, it's a good word to have in the jargon), I have enough distaste for much of Heinlein's work that I don't generally use the term.

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


"to drink"


Wait, not knowing what "grok" means is a "pretty good" filter for a person who is unsuitable for a role as software engineer?


OP referred to a Heinlein quote in his article. I figured that makes using 'grok' in a comment OK.


Much of this sounds like a joke [1] to me really as the most of the companies I have interviewed with won't tell all this even after signing an NDA. Even asking such questions elicits a strange look (don't you know we cannot disclose what we are working on).

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.


> 10. Take me to a Chinese buffet.

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.


I wonder if being the fourth interviewee in a given day would help or harm your chances of a follow-up? :)


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


That's kind of interesting to me, because my questions are exactly like mindcrimes and I would never ask the kinds of questions you're interested in. I sometimes say in interviews that I'm actually not that interested in the big picture of the company, I'm much more concerned with the day-to-day issues of software construction.

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.


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

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?


But even the biggest, hairiest, most audacious (audacious-est?) goals a company has will eventually get 'solved' to a satisfactory extent; that feature of the product you were hired to get working will be essentially "done" and go into maintenance mode, etc. Then what will the company do with you? Are they even sure you're good for anything other than the one problem they hired you to solve?

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.


Mine are issues and yours are details.

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

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

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

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

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

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

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

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


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

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


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


I disagree. I once tried coding an iOS app in a Windows 7 laptop using a hacked VMWare to run Mac OS X. And I will not do it again. The amount of time beach ball of death shows is greater than the time I saw the normal cursor. It's so damn hard!

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.


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

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


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

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

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

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


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

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


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

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


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

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.


As far as I can tell, this is quite untrue. Many of the most successful people I know are quite bitter about their previous employers. It's all about spinning that, though. It's not enough to just be bitter. You need to flatter your new employer, showing them that you jumped ship to them because they're so excellent, unlike those previous schmucks.


Everyone is bitter about their previous employers. If they wouldn't be bitter they probably wouldn't have left (except in odd case of, starting your own company,academics, research). What you are missing is - people generally have good time in companies but they leave when things go south.

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.


I didn't say you should work at a company you don't care for. I meant that "whether the company does something I care about" will be, for most every employee, an instrumental value in their utility calculations, not a terminal value. You'll care about it, but you'll care because of what's in it for you.


Is there a chance that the toxic environment derives from the people who "care" about the company, giving the culture a bit of a "too many cooks" problem? That is, not caring about the company itself can contribute to a "pure work" attitude that benefits the actual success of the business.


I'd like to add 3 !!! after that last part, and add ... especially if people warned you ahead of time that they just fired ("lost") half their employees last year, and you shrugged.


Why wouldn't you optimize for salary, if it is a bad place to work, you could, you know ... leave ... As far as becoming bitter ... sounds like a personal problem!


Honestly, and I don't mean this in a bad way, I find your criticism of the parents response to you a little silly and kind off putting. If I interviewed someone and he or she put a list like that in front of me I'd probably just put in the reject pile. It's a little pompous for an interview. Just being honest.


1a. No offices, only cubes. 1b. Limited conference rooms, people ignore the reservation just enough to make it irritating. 2. No continuous integration. No Git. 3. We say there is, but there isn't. 4. As one of our supervisors said recently, "If I'm not telling you what to do, or changing your workload on a daily basis, then I feel like I'm not doing anything." 5. All of the above! 6. Most people show up for work, most of the time. Performance reviews are irrelevant. You may be evaluated on things like "dresses appropriately" when there is no dress code. 7. No, no, no. Employees are not fired. I'll let you think about where that eventually leads. 8. No. No. No. No. None. 9. Not in the budget, sorry.

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


1a. Just out of curiosity, what's wrong with "open plan"?


To be fair, plenty of people like it. I hate it. It's a personal preference. In terms of anything that's really quantifiable, I'll say that I believe "open plan" leads to a constant stream of distractions and interruptions which kills your ability to get into - and stay in - that "flow" state of maximum productivity.

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.


Indeed! but there is also some benefit with open plan. You can fire ideas and questions away without picking up the phone or walk down the hallway to reach your coworker cubicle or office. It also let you know your teammate better. With that being said, I am all for private space since I can think better in quiet place and dislike having people walking around my back and staring at my screen.


What's wrong with open plan wrt programming productivity is that it's distracting. Also, you can't have a private conversation without grabbing a real office, requiring you to move, and that takes up more time.


Sitting a whole day with headphones...


aka "I will only work at venture-backed startups that will die in two years or Google".


Except many of the things he is talking about don't require lots of money. The company just needs to give a shit and treat people like people.


I love this list!

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


Tell me where a place like this exists. I think you may be my doppleganger, especially in regards to #4, #7


Hmm, 6 & 7 are the same. And I think you meant Thai, not Chinese.


They're almost the same, and it probably wasn't intentional, but they're worded differently enough that you might get some surprising answers from someone if you ask them a few questions apart.


Actually, I think they are pretty different. I've never seen Tom Yum Goong at a Chinese buffet.


I think they've very different:

6. Architecture, TDD, code

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


A good Chinese buffet. If you can't tell, or don't want to pay for, the difference, well...

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


Sometimes you don't find out it's not good until several hours later when you are having a close encounter with a plumbing fixture.


Useful and insightful list. I'd add "what's the impact to [your org] if you do not fill this role (whether with me or someone else)?"


" 10. Take me to a Chinese buffet."

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


I absolutely hate Chinese buffets, they all feel like feeding troughs to me.

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


I mentally substituted "dim sum" for "a chinese buffet" because the latter just doesn't make any damn sense to me.


Maybe he lives in a deprived part of the country where "Chinese buffet" is the best Chinese food?


These are basically all the things they need to keep secret to keep leverage over you.


Sometimes I think it might be even more benign than this. Some hiring managers are already so ingrained into their work culture that it's already become transparent to them.

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


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

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

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

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

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


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

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

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


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


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

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


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

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.


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


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


I find sarcastic naming conventions can help the pain just a little. But yeah, otherwise completely agree.


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

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


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


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


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

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

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


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

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

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


The problem is that at least 60% of people that call themselves programmers, and seemingly have no issue getting by HR, can't code fizzbuzz, let alone whatever it is you're working on.

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've heard various numbers like this thrown around, but I'm having a hard time seeing how it could possibly be that high. Is that figure coming from personal experience?

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.


Is that figure coming from personal experience?

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.


Well I still want to know where all those fizzbuzz claims come from.

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.


I am in a similar situation I guess, although I also have phd not in cs and I am a foreign citizen. I do get interviews, I ask the questions and solve the coding problems and generally do well according to this and similar discussions here. I just don't understand why I can't get a job and I'm pretty depressed by now. Even after I did Evernote programming challenge that is supposed to get you a phone interview, I've never heard from them. Sometimes I feel like I'm in one of those movies where your friends and family say they don't know who you are and somebody else lives in your apartment.


I'm in the same boat here. It makes me wonder if I am doing something so terribly wrong that I am somehow being lumped into the same group as people who can't code.

Want to exchange e-mails and chat about it?


Yes, definitely - anthonysdesimone (at) gmail (dot) com


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

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

Downvoters: have you actually tried to hire someone?


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

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


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

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

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

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

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

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


"others want the person to explain their reasoning,"

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.


Conversation about semicolons? During a job interview? I'm sorry, but this is a waste of time. Why don't you talk about, you know, algorithms? Concurrency? Databases? Testing? Or anything that is more than remotely relevant to the job?


"It's the purest test of Language facility"

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.


Personally, I'm vaguely aware that JS does ASI, but rather than waste brain space trying to understand it, I just use semicolons with everything.

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.


Putting someone in front of a computer gives them the freedom to google (true story: I used to do a paper exam, and then I found one person was googling when I was in the bathroom and left the guy unattended for a few minutes).

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


You don't use a whiteboard when you code?

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.


> Putting someone in front of a computer gives them the freedom to google

So? I use google all the time while coding.


> Putting someone in front of a computer gives them the freedom to google

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?


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

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


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


I think there's utility in weeding out posers. That's why fizzbuzz is even talked about in the first place.

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


Your whiteboard doesn't have an inbuilt syntax highlighter or linter that points out when I miss a semicolon. It's such a contrived situation that to expect perfectly written code is madness.


While it makes no sense in a language like C, in languages that do have automatic semicolon insertion (like JS) the question is far more interesting


I'll go one further.

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 wonder if I interviewed you. I've only ever had one or two people ask for clarification or want more detail about inputs BEFORE they start writing code.


I find that surprising. The advice I've gotten from everyone when interviewing at the big tech companies in Seattle is always "make sure you clarify ambiguity before writing any code".

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.


to be sure it wasn't writing code - whiteboarding code/pseudocode. it was a bit of an ego stroke, i think, but given the state of their company at the time, and how they advertised the position, i don't suspect they were getting many sr-level developers applying. i applied mostly cause it was close to home.


Not too mention that many of those contrived problems are recycled, so a little studying goes a long way. What exactly does that prove?


It's not a test of your ability to recollect something. It's a conversation. If you're just regurgitating the greatest code solution ever but can't explain why it's so damned good then you're not very impressive.

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


Excellent! Very well written and expressed.

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

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

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

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


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

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

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

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


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

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

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


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


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

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


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.

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.


"How many years of experience do I need to have for them to stop asking me things like this?"

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.


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

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

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

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


I see three problems with this:

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


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

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

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


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

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


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


How about: hi, candidate, here's my laptop. I've created a guest account for you and installed an IDE with X programming language. Take some time to implement this original program I want done that can't be copied from google. I'll be back in 45 minutes and we can discuss your solution until our hour is up. Nice to meet you.


Completely agree with you - I frequently used to ask experienced candidates questions of the form, "tell me about one very difficult bug or performance issue encountered during your two years working on X."

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.


"Be Interesting"

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

"Rockstars, etc...."

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


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

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


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

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

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

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

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


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


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

- Be Interesting

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

* Care

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

* Acknowledge Applicants

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

* Get to Know Programmers

You can't do this without getting to know 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.


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

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

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

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

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

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

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


> Assuming I Am Only The Last Thing I Was

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

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

> Care

Passion != Success.

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


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


Another thing that bothers me about some positions:

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

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


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

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


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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


> And I'm sorry, but it's a Buyer's Market.

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.


The employers I've worked at, since about 2002, have had a large pool to pick from, and those looking for a job have gotten less and less of a cut of profits and their benefits have been cut back, fairly consistently (relative to inflation, etc.)

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.


Are you talking about programmers? Are you talking about the United States? If so, the evidence is not on your on side. It's actually so not on your side that I'm a bit flummoxed.


Software engineers, with advanced degrees and experience, in the United States. The majority of them are not citizens.

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.


Are you saying there's not that many and especially since they are not US citizens? ... That means it's a seller's market.


I'm saying that at the companies I've worked at, I've had a deluge of applications from extremely qualified candidates, the only hesitation anyone might have in hiring them is that a majority are not citizens.

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


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

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

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


At the time I was working with code that had been written with Visual Studio 6. The code snippet was written at that time, and I thought it was interesting because of how it behaved, and it let me delve into how the person reasoned about the language, the compiler, and the runtime.

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


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


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


The question equates to "spot the undefined behaviour in this statement" which I think is a legitimate question for assessing knowledge of a language like C++, and to use as a starting point to find out if they understand the difference between programming to the language spec. versus programming to the compiler.


I think it could be an OK question. I'd have to see it; if it is something sort of well known or a fairly arcane thing. It being 15 years old is not really that problematic to me. Python is much older than that. :)


I think "cookie-cutter technical interview" has been misunderstood. My fault, I didn't spend much time on it in the post.

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.


Thanks for the response.

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.


> but it's a Buyer's Market

On what planet?


> You think it's hard to find programmers, at any given level of skill?

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.


Maybe it is just perspective. I'm not good either, but I am a deep introvert that always botches interviews, and I've been job hunting for ~6 months, across the Internet. No network, I live in the middle of PA so no person-to-person tech sector without spending a few hundred dollars traveling, and I've been doing FOSS for a while now just biding my time so I have a portfolio to sell to get a 9-5 or go freelance (though I'd probably prefer the latter).

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.


Friend: If you can get the money together, get on a bus to Boston (many other cities will work, but that's my home base) and go on couchsurfing.com to find a crash pad. Show up, unannounced, at any of the many, many recruiting offices around here with link to a portfolio or github account and let them know you are looking for work. If you have even decent skill, you will have interviews within a day or two at most.

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.


> you wouldn't have all these shops using spam-tactic recruiters to drive volume.

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.


I'll be somewhat blunt - but this isn't meant as disrespect for you.

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?


I agree on the two camps ideology, and this is HN after all, so I'll ask - how to you get into the sellers market? I graduated with my CS degree with an ok 3.4 GPA recently, and I cast a wide net on jobs from Django to openCL, but everywhere I apply I either get cold shoulders, a 30 minute phone interview that never gets a response even with follow up, or rejection on a lack of project experience. I've been working FOSS for a few months now, and I hope that helps, but when you live in the middle of PA and not a big tech hot spot, have no networking contacts, and no desire to try to play founder-with-some-arbitrary-webapp-maybe-1mil-people-will-use-but-will-be-forgotten-in-a-year how do you get ahead?


Get very smart about who you apply to. Seriously, stop responding to ads right now and spend the next week studying job postings. Look carefully at every statement. Ask yourself, "why would someone put this in a job posting?" Don't just assume you know, think about it and ask yourself if there's something you missed. Memorize the posting, before you reply.

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.


Hang out in NY or Boston. Attend every meetup you can find and let people know you're looking for a job. You don't have to be super pushy. Just do it in the middle of explaining your background.

-“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?”


Sorry about the late reply - I've been mostly cut off from the internet (mostly due to hotel charging exorbitant rate).

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.


You may have to move out of "the middle of PA".


There's a bit of a chicken-and-egg problem for intelligent developers trapped in a less favorable city: you can't make it to in-person interviews in a more active city, so you have to cross a higher threshold to be interesting to employers there; you don't have the funds to move to a better city, so you need to find a local job; local jobs are both low-end and scarce, so you can't save the funds you need to move.


This is very true. I advise everyone who is young and in the field to move to a tech hotspot. Otherwise you appear to be screwed.


If you're in a small town, you need to network more. My preferred method of doing so is to hang out at Starbucks and shoot the breeze with whoever walks through the door. Eventually a job will fall into your lap.


>But that job will not be worth talking to so many people. ;)

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.


But that job will not be worth talking to so many people. ;)


I'll note that the salaries at some of the top companies have not been inflating that much. For them, it's a Buyer's Market. Like I said, perhaps I've been lucky with the companies I've worked at, and didn't even realize how fortunate I was.


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

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.


> so you could get them at bargain rates.

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.


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

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


The charitable reading would be that he is talking about unsolicited applications.


Perhaps, but honestly the wording lead me to believe he was referring to the practice of keeping job postings open for non-existent positions. It's a relatively common practice, albeit a questionable one IMHO.


The length of time I've seen open positions sit unfilled

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


Absolutely disagree. It's a buyers market unless you're physically located in a tech spot or know the right acronyms of tech.

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


Are you in a tiny town in the middle of nowhere? Because there's nearly always a number of web designers out there serving even small-ish towns, sometimes even a shop or two. These designers are always looking for web programmers, because the freelance guys they use come and go. If you're a halfway decent coder, you'll have 80% of the small-town freelance market beat, and the other 20% will already have remote gigs. Sure, 90% of your work will be laying out HTML/CSS, in my experience, designers are terrible at it, but it beats flipping burgers.


"unqualified/foreign/unmotivated"

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


H1B visas are hard to get.


Let me give you some perspective. I'm not "good", interviews are incredibly painful to me. I work at a big-corp right now doing perceptual computing which I'm very happy with. It's not Google in terms of public perception, but it's not extremely bad either. I tried job hunting a few months ago, interviewed at the big ones. The interviews went mostly well actually, but I didn't get a single offer. Basically, given my specialty, I have to be extremely good to get an offer. I can't apply to any job that has to do with the web or mobile, because the stuff I'm building in my spare time is not enough experience.

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.


> unqualified/foreign/unmotivated

Interesting choice of words ...


Unqualified: One of the questions they asked me was the difference between a TCP and a UDP packet. I assume this question tripped up earlier applicants.

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.


Companies unwilling to do H1B visa sponsorship probably are not refraining due to language barrier issues. There is a cost, both money and time involved that small shops simply can't afford.


You think it's hard to find programmers, at any given level of skill?

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


> You think it's hard to find programmers, at any given level of skill?

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.


> "helping a local company offering $95k salary and benefits (well above average in their area)"

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.


Yea, that seemed off base. I work about a 40 min. outside of Philly and the going rate in my group is $100/hr...with some guys negotiating more than that. Not suggesting that that is normal in the area, but half that for senior devs isn't either.


> The entire country graduated less than 10k people from CS programs in 2010.

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


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


> the curriculum doesn't really sell itself at all for professional software development

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.


you probably mean "Monte Carlo".

those liberal arts places... :-)


No, I did mean Monte Hall - see https://en.wikipedia.org/wiki/Monty_Hall_problem

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.


I assumed I just didn't know what the 'Monte Hall' approach was! :)


> ... we have overly-qualified applicants lined up for openings that don't exist.

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.


Where outside Philly are you? I'm in Berks and while I'm shopping everywhere from NY to SF for an entry position out of college, there is nothing close to any demand for developers I can find in these parts. Philly itself can be ok for positions, but outside the city seems like a barren wasteland.

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.


You need that "network". And by "network", I mean people. Find someone you respect, at least professionally. Someone that impresses you. Someone that you'd be happy to pattern your professional self after. Solicit their advice. Listen to what they say. Earn their respect in return for the time they offer you. Good things will eventually happen. (Translation: they'll help you find jobs.)

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.


I was in that fortunate situation until last year. Now even that well has virtually dried up.

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


I never bother with cookie-cutter interviews. With the exception of the first, every time I've had one I ended up being made an offer, and turning the job down. First, I found obscure technical questions from interviewers a bit sadistic. Almost as though the interviewer is trying to tell you how good she is. When I accepted an offer after such an interview I only lasted three months, because the interviewer felt threatened by me.

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


"If, conversely, a candidate asked me the questions edw519 listed above, you'd pretty much be guaranteed a job."

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?


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

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.


> Sure, of course.

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.


You're right, it's a buyer's market. And this kind of thing shows it. But for some reason we keep hearing that there is a massive talent shortage. Hmm...


Ahhh....I think the two concepts (buyers market vs. talent shortage) are related.

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


The bar in this business is still so low that "average" talent is utterly useless and nowhere near "competent".

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.


Well, OK, I agree, for the most part.

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.


API design is really key to working together. If I could pick one thing about myself to improve right now it would be API design skills. I think a lot of other programmers don't get it for whatever reason, so I can see why that would be in high demand.


>If I could pick one thing about myself to improve right now it would be API design skills.

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.


Both things can be true at the same time.

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


Though I have only been on the applicant side of the interview table, everything you say rings true to me. I understand completely why employers need to do low level competence tests.

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?


Also stop with: interviewing based on rote memorization.

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

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

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


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


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


Ugh. See, and if my mom asked that, I know she's looking for a barebones high-level explanation that she can grok, so I can be a bit fuzzy. But when an interviewer asks me that? I can't tell if they're just screening out the dummies, or if they actually want me to talk about packets and handshakes and DNS protocol.


I also got that last week. It was during an interview for a position that ostensibly didn't require any sort of in-depth knowledge of that process.


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


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


I think that's the problem, they don't know what they want.


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


Number 1 rule for hiring geeks.

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

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


To be fair, a lot of recruiting companies or hiring companies only do that because their HR system will only import a .DOC file.

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!


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


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

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


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

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


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

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


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

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

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


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


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

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

Recruiters sadly aren't interested making friends.


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


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

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

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


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

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


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


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

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


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


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


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


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


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

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

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


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

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


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


I think my ideal way to land a job would be

1) contribute to some open source project.

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

3) job offer.


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


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


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


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


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


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

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

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

Software Development Environment.

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

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

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

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

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

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

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

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

Teams.

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

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

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

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

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

Programmer Qualifications.

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

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

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

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

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

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

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

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

For more:

More.

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

Compensation.

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

Large Software Projects.

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

Training.

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

Security.

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

JavaScript.

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

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

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

Writing.

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

Net.

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


Now this is some fine trolling.

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


"Trolling"? I have no idea what you are talking about. What I wrote is simply, rock-solidly, literally true -- "I've been surprised and pleased ...".

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.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

VB:

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

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

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

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

VS:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On my

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

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

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

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

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

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

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

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

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

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

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

I could list another dozen such.

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

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

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

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


Can someone explain what a "resume wall" is.


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

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

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

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


So it's like a firewall but for resumes?


Sorry I left you wondering! A resume wall is a third-party service that sits between applicants and an employer. In order to apply for a job with some companies you have to submit your resume through their service. http://www.jobscore.com/ is an example.


Ah, I was imagining a huge page filled with resumes in the same vein as a wall of text.


This is a great post.

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

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

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


Cash, lots of cash!

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: