This, exactly. I keep reading about this huge shortage of qualified developers, but I've now met enough talented developers looking for work -- who are reliable and talented, and not assholes, that I know that the standard line about a talent shortage can't be true. Perhaps it's an issue in and around the Valley, but it's not in most of the rest of the country. If you're having trouble hiring in the US outside of SF, then you probably either:
1) Fail to realize that good programmers know about programming in general, and that this knowledge easily transfers from one language or technology to another. If you're looking for an X programmer with Y years experience in Z technology, then good luck with that!
2) Conduct your actual hiring process wrong, as described in this blog post. All these companies ask for "rock star" developers, yet when they actually get one to an interview, they spend all their time running them through one whiteboard exercise after another, instead of asking about all their amazing projects.
Unfortunately, I know I'm preaching the the choir here. I wish this kind of blog post could reach the eyes of HR people and/or hiring managers. Perhaps it could change some minds.
"There's no shortage of smart, hardworking engineers. There's a shortage of smart, hardworking engineers willing to work for very little money." ~ David "Pardo" Keppel
If you're having trouble hiring, it's probably because you're not paying enough. It turns out that talented people are worth paying a lot for.
It's not that people are having trouble with people accepting offers. They're never getting to that point because they don't think anyone is qualified.
I'm simply pointing out that the oft-heard complaint from the other side of the table is flawed. I very often hear startups complaining of talent shortages. This is false.
That assumes that people smart enough to meet their standards aren't smart enough to look up salary surveys that show whether the company pays market rate before bothering to apply.
"There's no shortage of smart, hardworking engineers. There's a shortage of smart, hardworking engineers willing to work for the kind of money we would pay if we just outsourced it to a cheap country" ~ Company CEO
Yes, there is something wrong. I had a good friend put himself on the job market six months ago. He has the total package -- has worked on and shipped well-known products, has reviewable open-source projects and contributions, great academic pedigree, nice guy, even good looking -- I said something like, "You'll have five offers at the end of this week".
Three months later, no offer. What was most interesting was how few interviews he received. He went with the cold resume drop approach. It's almost as if no one reads them at all.
He eventually just took a job with someone he knew from a company he worked with in the past. And in fairness he has several open door offers (I've told him that if he ever wants to work with me, just email me a start date).
But the fact that someone who I would actually describe as top 1% of devs I've worked with can't get a job without relying on his network is kind of scary. Imagine if you want to ever change from one sub-industry to another. And some of the companies he applied to are the same ones you'll hear complaining about the lack of qualified talent, yet they didn't even do a phone screen on someone who I am confident is a lot better than 90% of their current workforce.
> But the fact that someone who I would actually describe as top 1% of devs I've worked with can't get a job without relying on his network is kind of scary
This is just one of those unavoidable aspects of human psychology. Ignore it at your peril.
Lots of programmers seem to think networking is somehow beneath them. But it's the best way to sidestep most of the pitfalls everyone is amply describing here.
That's interesting, there is a recruiting process in place but the easiest way to get the job is to get informal and skip the process. That's really inline with the article ihmo, the process is broken.
Networking is and always was the best and easiest way to make relationships, and hiring is a relationship. So no wonder going through friends works better than blindly sending a resume to somebody having to connection to you.
It is ripe, but it requires you to come up with something better, which can't be gamed by bad developers and doesn't take longer for good developers (since they will find other companies to apply for).
Hmm, that's pretty interesting. I had decent luck with just applying online, but with the couple companies where I got a referral, things moved much faster.
I've always thought that the software industry is one of the few things you can get into without having a really good network (although it definitely helps).
I have a good blog story if someone wants to write it:
Create a fictional rockstar resume(s). Not too over the top, but someone clearly a cut above the rest. And submit to various companies online. Report on which ones actually query back with interest.
What is this experiment going to prove? That it's not too difficult to "create a fictional rockstar resume, not too over the top?" This is true. That submitting such a resume to various webforms across the internet won't glean many responses? This is also true. But where's the surprise? The cold-dropped resumes are useless because they are so easily faked.
A network of independent, apparently competent former co-workers who can vouch for you is difficult to fake. Failing that, the ability to bring it – to stand up in a room, armed with nothing but a whiteboard marker and a grin, and convince people that you're knowledgeable, wise, serious and energetic – is also difficult to fake, not to mention a really valuable skill.
But the fact that someone who I would actually describe as top 1% of devs I've worked with can't get a job without relying on his network is kind of scary.
Isn't it expected and the way things have worked? Friends give friends who give you jobs. Applying blind is like the shotgun approach because the relationship between you and the candidate company is nonexistent and has no context. If you're a friend of Jack's from his previous company, you're already someone and you come from somewhere. Doesn't necessarily make sense, but that's how people are.
Further, exceptionally good programmers hang around with other exceptionally good programmers and in companies that have an eye for exceptionally good culture. Now, where's the link to your generic Big Co to which you send your application? Colleagues? Generally no. Management? I don't think so. Name of the exceptionally good company? Hardly unless one of the big global names. You get to keep the badges you're known for? Not really, because the field is different. Would you recognize a good CEO based on the small company he was working But the fact that someone who I would actually describe as top 1% of devs I've worked with can't get a job without relying on his network is kind of scary.
Isn't it expected and the way things have worked? Friends give friends who give you jobs. Applying blind is like the shotgun approach because the relationship between you and the candidate company is nonexistent and has no context. If you're a friend of Jack's from his previous company, you're already someone and you come from somewhere. Doesn't necessarily make sense, but that's how people are.
Further, exceptionally good programmers hang around with other exceptionally good programmers and in companies that have an eye for exceptionally good culture. Now, where's the link to your generic Big Co to which you send your application? Colleagues? Generally no. Management? I don't think so. Name of the exceptionally good company? Hardly unless one of the big global names. You get to keep the badges you're known for? Not really, because the field is different. Would you recognize a good CEO based on the small company he was working for? Even if the small company is the technical leader of designing pressure valves? And you're hiring him for the position of a CEO in a game company? He might be the rockstar CEO but you don't know the field.
My friend is a manager in a big consulting company. We talked and I suggested I probably wouldn't pass the hiring process of his company, eventhough I work for a lot more high-end technical company and would beat most of his employees technically. He was a bit stumbled but slowly realized it might be true. (And that he might not get into our company, despite his senior experience.) It's a whole different world there than where I am. ? Even if the small company is the technical leader of designing pressure valves? And you're hiring him for the position of a CEO in a game company? He might be the rockstar CEO but you don't know the field.
My friend is a manager in a big consulting company. We talked and I suggested I probably wouldn't pass the hiring process of his company, eventhough I work for a lot more high-end technical company and would beat most of his employees technically. He was a bit stumbled but slowly realized it might be true. (And that he might not get into our company, despite his senior experience.) It's a whole different world there than where I am.
> Applying blind is like the shotgun approach because the relationship between you and the candidate company is nonexistent and has no context.
I don't know, in my (albeit limited) experience this has worked every time. Once a year in a row for the past five in fact. A nicely worded cold email highlighting relevant experience with links to code samples usually gets an interview.
I am definitely not your 1% super-developer, I think I probably sit right in the middle of the bell curve.
Not to lower the value of networking though, do it. I've learned much from just talking to people and keeping in touch, and so far I've helped set up a couple of deals that went well.
Sorry about the formatting mess. I'm not allowed to edit the post anymore so it's there to stay. If only the virtual keyboard on my tablet had cursor keys, everything would be a lot simpler...
As someone who just went through this, I had a similar experience. I was on contract through January. January comes around and I figure I'll have a gig no problem. As a front-end developer, I already had recruiters knocking down my door.
A month later, I finally landed a gig. I had a few offers, but over the course of a month, I had more frustration with people I was interviewing. Three places I interviewed with weren't looking for a front-end guy, they were looking for a Javascript programmer (my goal wasn't to write JS 7 hours a day - sorry). Also, I had several instances where the company had no idea what they were looking for. One company said they wanted someone who did a lot of server sided Javascript (node.js and backbone.js) as well as being a great designer. Seriously? WTF?
I agree that most of the interviews I excelled at, was where I got up and showed the company the app I just helped build. As opposed the the "code quizzes" a lot of places now use. I actually stopped a guy in one interview who kept asking me basic CSS stuff and said, "Did you even look at the sites in my portfolio or my personal site I built?"
All in all, it was very frustrating and I felt like I really had to go way out my way to try and convince people of my skill level. At other times, I was trying to pry out of them what they were really looking for.
Your story sounds… normal? This is how interviewing works, especially if you know what you want. It's a two-way street. Most jobs are pretty lousy, and even the great ones often don't fit you. You need to interview them and figure out whether or not their job is worth taking, then turn it down and move on.
(This is especially true for folks who program Javascript in 2012. It's a field in enormous flux.)
In many fields, it's normal for interviewing to take months. They warned us grad students to expect to spend a minimum of three to six months looking for Ph.D.-level jobs, because you tend to be searching among a fairly small pool of employers who are looking for folks with specialized training very similar to yours.
From the comments here, and in other similar posts, the HN community seems to think only one side of the interview process is broken.
I posit that all sides are broken -- yes -- the recruiters, the hiring companies, and YOU, the engineer/marketer/whatever you are.
I'm only going to address the one part that matters -- you.
Who cares how qualified you are? You think that entitles you to a job? Gimme a break!!! Do me a favor and put aside your naive and childish ideas about job entitlement...
The following is not prescriptive, but it works for me. The HUSTLE.
1. Skip the resumes and all formal methods of first contact. Scrape linkedin and other places to get an inside contact where you want to work.
2. Skip HR. They are only good for filing paperwork once you have a done deal.
3. Once you have a contact send a two line email asking for 15 minutes and a coffee. Be charming and funny. Don't sell yourself. Let your good looks and excellent hygiene speak for you.
4. Whatever your salary / hourly rate is, double it. Think perceived value.
5. Ask lots of questions.
Note -- this is nothing new. This is business as usual, and I love it. Networking is everything.
In case anyone here is wondering, yes -- I am a developer from time to time.
You can't just "skip HR" at lots of companies. You can't get a coffee with someone that lives across the country. These techniques work GREAT for some jobs, but not at all for others.
I don't feel entitled to work somewhere because I'm qualified. I feel that if I'm qualified and would be a good fit, that the company should want to hire me. The problem is that they often don't get a good picture of how qualified I am or how good of a fit I could be. That is the problem.
1. I've never seen a company where HR was impenetrable.
2. For cross-continental meetings, substitute coffee for phone call. Or serendipitously turn up at a conference, a panel, or in the executive wash room. This is all the easier with twitter and 4-square. Hustling is not stalking according to my attorney :-)
3. Companies don't hire you. People hire you. It is your job to get PEOPLE interested in you, and that does not come from a resume, qualifications, or any other credential. Those are incidentals and formalities "after the fact."
the broader is issue is that learning has been replaced by hiring. the assumption now is that you already need to bring all the required skills to the job, to be productive from day one.
the concept of apprenticeship has been completely eradicated.
i work in a specialized area and had trouble finding candidates that matched my job profile. frustrating. but then i took a step back and looked at how I had gained those skills - through practice, through experience, not through formal education. so i started to look for good people, good learners, flexible minds. yes, there will be a ramp up time, but they also come with fresh perspectives. i can also directly influence their knowledge as i am their reference point.
and age is not a factor here, last guy i hired is 50+ - and i am 32.
Absolutely. Most people either do not understand the role of apprenticeship (I try to persuade them to read Richard Sennet's The Craftsman) or simply have a completely short term attitude, which often means they fail to hire for longer than training would take, and also blinds them from the contributions different experiences can bring.
This is spot on. I think it's a recruiter problem - many look at the resume and take that as the full story.
I have a funny example of this "hiring problem." Shortly after I consulted for a established, public web company, they were hiring a FT person for the same thing (design-related). The dept I consulted for emailed me and asked me to submit a resume and said they'd make sure I floated to the top. What happened? I didn't get past the phone recruiter. I could tell she got hung up (no pun intended) on something on my resume and I got a rejection email from her shortly thereafter.
So as this post suggested, the company went the consulting route before-hand and we worked well with each other. Then a recruiter got in the middle and messed it all up.
Did you mention this to the people you had previously been working for, who knew you, likely recommended you, and could have helped bypass the phone recruiter?
It seems you would be in a prime position to get the job (if you, in fact, wanted it).
I just went through a long job search process in San Francisco, and I actually feel exactly the same way.
I told several companies "no thank you" after going through their interview processes, where the only thing they did was asking one whiteboard coding question after another. None of which had anything to do with the real-world domain of their business. The company that I ended up joining didn't ask any - their questions were no less technical, but they were experience-based, rather than quiz-based.
As a soon-to-be grad looking for a job right now, I don't get why nobody ever asks for just code samples.
Its like, here are 5 dozen requirements for the position no human alive currently possesses, now let us talk about everything EXCEPT code.
I'd just say "you want to work for X doing Y using Z? Show us some code samples of what you have done in the past".
And I would hope it would not always be "show us code samples using this tech for what we are trying to do" because then I already wrote your back end for you, apparently. I have a good ~30k lines of code I have written in college for both courses and freelance, and it all seems to sit in a folder of stuff I have since nobody ever wants code samples.
There is the flip side, that people could copy paste someone elses work to try to claim as their own code to get a foot in the door. Dunno how to deal with that. Maybe just ask for some 1 day assignment. If you are a web company, have them build a simple table in django using some database. Or something just to show they know what you are talking about.
But the rapid fire graph search and various sorting implementation questions and how do you use insert X random algorithm in convoluted way Y to achieve random result Z drive me crazy.
My current reading of the job market around me, and I may well be just in a funky mood so forgive me, is that all the IT job listings seem to itemize all the ways you won't be allowed to be creative, and also list a bunch of surprisingly general, and contradictory, experience requirements. They promote any kind of actual CS knowledge as being a masters degree skill only needing 10 years in direct experience in a 10 year old technology. This combination sounds like they have a bunch of old crap that they've built up to be so complex that no one wants to maintain it, and it will take a year for anyone to understand it anyway. So that's the total message like "here, you take this," but the HR people can only translate the requirements into someone that doesn't exist, because they want someone to hit the ground running, on an amateur complexity study.
I used to passive-agressively mention this to our HR department and my old job all the time. The basic "Software Engineer" posting has "At least 3 years of desktop or server software development" as a requirement. I always liked to point out that I (and everyone else they hired out of college) wasn't qualified for the jobs we were doing.
They're in Michigan, so finding development talent is a little bit harder so I don't know why they're discouraging college students from applying by having pointless job requirements that don't actually matter.
> they're discouraging college students from applying by having pointless job requirements that don't actually matter.
From the opposite end of the spectrum, I'm always amazed at the jobs that slap on the computer science degree requirement. My small rural municipal government was recently looking for a web developer to work on their CMS. A CS degree was a requirement for the job, despite there being very little pure CS work to being with (it is your standard db-driven website).
I don't know, It struck me as odd. Why would this small government, in a low income area - average single income was $25K/year in a report a few years ago - restrict their search to people who are said to be in high demand and probably being courted by places like Google with interesting CS problems that they trained many years to work on? And as a taxpayer, why would I want to pay Google prices? It is a useful resource, but not $100K/year useful.
After several months they finally did find someone for the role. Though, I cannot say if they finally relaxed their CS requirement or not.
Playing devil's advocate here a little bit - If you were a small organization with little technical expertise, how would you hire developers?
As someone who doesn't have a CS degree, I agree that it is frustrating to see hard requirements like this. But looking at it from the perspective of your "small rural municipal government", hiring developers is probably a pretty tough and scary endeavor. Lots of people hold themselves out as developers, and frankly, a lot of them are pretty bad at it.
How do you tell the bad ones from the competent ones? A CS degree at least gives you the guarantee that they at least had some training.
I think that is a fair point, but it seems akin to requiring a physics degree for the job of mechanic. Generally, the people doing the hiring decidedly know no more about mechanical work than they do about software development, so I do not think this is a unique issue.
Now, I am sure it would be useful for a mechanic to understand all of the properties of the materials to manually derive the torque setting needed for a wheel bolt and all, but in reality, you just follow the book. The science behind the application is not particularly useful within this context.
Hiring is hard, but I think this goes back to the original submission: If all you look for is a physicist, you're going to miss the master mechanic. You might even end up with someone who has no interest in tearing down engines at all. Is that really the better member for your team?
I when I applied right out of college I didn't give a shit about how many years of experience they required (for some reason they never count the years of experience I had accumulated in college) and just applied anyway. I got a job out of it too, so I wouldn't recommend anybody else pay attention to that.
From the other side of the desk, what I am most afraid of is letting someone with weak coding or technical chops through the door. It destroys teams.
Yes, culture fit is important as is someone who really likes to program and build. You get to that after you've established that the person can code.
I'm not talking about the google "how many jelly beans in a bus" thing either. I'm talking "what is an inner join", "what will this loop output". Basic. Stuff. 9 out of 10 can't do it. Until you establish that you can, the odds say you can not.
As someone hiring, someone about to put my money in your pocket in exchange for the skills you bring, I've got to be sure the ROI is there.
I have never interviewed at google. I was going off of the "how to prepare for google interviews" or "a rehash of my google interview" write ups linked to from HN.
Apologies.
I also would note that some candidates for our positions think "wow, all these guys know to ask are basic MySQL and PHP questions?", which makes me suspect other companies or the coder culture at large are asking the type of questions I derisively referred to.
Why not give everyone a simple test, but give A LOT of people a simple test (which SELECT statement is an inner join...)?
What I always here is that 90% can't write a for-loop or a basic regular expression, but look great on paper, and vice versa.
EDIT: Recruiters are probably too stupid (usually) to be able to either administer or evaluate such tests and so will always be more interested in the "crisper" resume which belongs to some MBA doofus.
Nonsense. I've worked in an organisation where we trained our recruiter to ask simple weed out questions. We would use questions like 'what is an A record?'. The candidate must give a two sentence or less answer right away. The recruiter didn't really know what an A record was, but knew how to ask the question. This saved us so much time because he could filter out tons of bad candidates for us immediately, without even looking at resumes.
As for 'crisper' resumes ... this guy was a Santa Cruz hippie at heart. He knew what was up in the tech industry. If you pick your recruiters for having some personality, it makes your hiring process go so much better too.
PS - This is about Operations hires, there are similar tricks applicable to Engineering hires.
> give A LOT of people a simple test (which SELECT statement is an inner join...)?
That is like asking, how do you implement a reduce function in CouchDB? The answer is easy, and would only take a couple of minutes with Google to answer, but I bet even many top programmers could not answer that question off the top of their head.
If you are looking for someone who writes SQL queries all day long, maybe that is a good question. But if you are writing software that does complex visualizations, occasionally pulling some information from an SQL database, should a recite-from-memory knowledge of SQL really make or break the candidate? INNER JOIN syntax is something you can easily query Google for.
I would disagree. There are questions which if you fail to answer this means your understanding of the field is near zero. For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases. Which may be OK if the job does not require that, but at least you'll know that about the candidate.
Another thing is that some candidates (or their recruiters?) "inflate" their resumes claiming expert knowledge for things that they heard about in passing or maybe did some trivial task with it. Asking such trivia knowledge allows to find it out very quickly - if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying. And this is a bad sign - to start relationship with a lie. I know some people like to do that (especially because of the keyword-match approach) but it's a huge turnoff to start an interview with a supposed expert in the field you need and find out the most work he did in the field was a toy project 10 years ago in college of which he remembers nothing and isn't even interested in doing that.
> For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases.
This is like saying if you can't write a controller in Ruby on Rails off the top of your head, you do not understand programming. SQL is a vendor-specific technology, and while it is related to relational databases, is not tied to the underlying theory. You can have a relational database that does not use SQL at all.
> if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying.
I agree with this. If you want to hire someone who understands the inner nuances of, say, MySQL then it may be a good question. This is quite a bit different to understanding relational databases though – one is theory, one is application.
No, it's not like that at all. RoR is a very specific application, if you can't write a controller then you probably don't know RoR, but it doesn't say you don't know programming in general.
Yes, you can have relational database that doesn't use SQL at all - how many of those are around and popular though? There are some, but not many. What are the chances that you worked with a lot RDBMS, yet never encountered SQL even at the basic level, and it is not immediately evident from your resume, which still says "SQL"? But OK, if that's the situation, you can say "you know, I worked with non-SQL relational databases, and let me tell you about this cool thing I've done that is way better than SQL JOIN can do" - and that might be fine too. Usually though the case is just that people inflate their resumes and think they won't be called out on it. It's very unpleasant because when you interview somebody whose resume looks good, you unconsciously plan that you'd get a great addition to your team - and then you discover he doesn't even know joins... Bummer.
BTW, inner join has nothing to do with MySQL inner nuances - it exists in virtually any SQL implementation out there AFAIK.
I've hear that Interview Street is aiming to solve this problem by letting people show their chops in coding contests (https://www.interviewstreet.com/challenges/) , pass one of those and you're closer to getting into the door of a big company than you were before.
what I am most afraid of is letting someone with weak coding or technical chops through the door. It destroys teams.
Only if you don't fire them. Making hiring mistakes is Ok if you can correct those mistakes. As it stands hiring seems to be a high stakes game of win a job until the next round of layoffs.
A big issue in modern hiring, IMO, is the combination of diverging specialized platforms and languages combined with overemphasis on keyword-hiring.
When I first got into the industry you had:
---
* old fogey LISP programmers
* old fogey FORTRAN programmers
* old fogey COBOL programmers
* Assembly programmers
* C/Win programmers
* C/Unix programmers
* C/Mac programmers
* some people on the cutting edge looking at this new "C++ thing"
* everyone else
---
I mean, sure you had some specializations but nothing like what you see now. Now you have:
---
* young retro hipster LISP programmers
* JavaScript/Client-Side programmers
* JavaScript/Client-Side/jQuery gurus
* JavaScript node.js programmers
* Python programmers
* Python/Django programmers
* Ruby developers
* RoR developers
* Java/EE programmers
* Java-Android programmers
* Clojure programmers
* Scala programmers
* Perl programmers
* .NET/C#/Win32 programmers
* .NET/C#/Silverlight programmers
* .NET/C#/WP7 programmers
* Objective-C programmers
* C programmers
* Embedded C programmers
* C++ programmers
* Embedded C++ programmers
* Go programmers
* D programmers
* Game Industry programmers (usually C++, often treated as a wholly separate category)
* PHP programmers
* etc
* etc (this is maybe 10% of the list I could generate without getting into the really obscure stuff)
---
Of course a spectacular programmer can pick up a new language/platform quickly and is usually learning non-day-job related programming languages on his or her own time anyway, but I've still both experienced and heard anecdotally of many situations where spectacular programmers were passed over without a second glance because they didn't have "at least X years of KEYWORD-HEAVY-SPECIFIC-TECH". Viable commercial quality languages and platforms are diverging way beyond the ability of even the most passionate programmer to be regularly using all but a small minority of them.
Just the other day I saw a job requiring "3+ years iPad experience".
I understand the appeal of hiring somebody who needs minimal training, but they may still not be the best pick. When it comes to a long-term position, it is better to hire the great developer who takes two weeks to get up to speed with some language or technology than it is to hire the mediocre developer who happens to have used Node.js or whatever.
When Java was young, I remember many tales of Java job advertisements demanding experience extending back before the language existed.
My impression is that the current insanity isn't so much the absurdity of the bureaucratic demands but the degree to which people take them seriously...
I'm pretty sure these instances (which I remember hearing about too) are just example of how out-of-touch HR is. Someone says:
I need a developer with 10 years of professional
experience, and he needs to know Java.
HR hears:
Developer with 10 years of Java experience
That, and we all know that sometimes the job listings are just there so that they can say that they tried to find other applicants, but the friend-of-a-friend is actually the 'best fit' for the job (i.e. those job applicants are designed to fail).
That is nothing. DHH posted a tweet about a company that required 7 years of rails experience.
The key to overcome that is to not give a fuck and just apply anyway. I applied to countless jobs right out of University that turned me down, but that didn't matter since more than one didn't. Nearly all of them expected more experience than I had, but again it is just meaningless HR talk.
I suspect this has a lot to do with recruiters/HR being the intermediate. If I hire a programmer, I'd prefer him of course to know the platform he's working on and hit the ground running, but I'd much rather have a good programmer that can learn a new platform and become productive in a month than a mediocre one which knows the platform but will be mediocre forever.
The problem, however, is that if I am a software engineering team leader, there's no way I can talk (or have anybody from my team talk) to every candidate out there to see if they're good. I will have to use somebody to screen people, even before they get to the interview. So recruiters, etc. come in. And it's very easy for them to operate on the keyword basis and very hard for them to find out who's good and who's not. So they do what's easy, since otherwise they'd be out of business or seriously hurt their competitiveness.
It's not just an HR issue. I've come across a number of situations where developers are making hiring decisions and using arbitrary criteria to base them on. E.g.:
* The fire storm over Deviant Art's 'we only hired 0.0000001% of people' blogpost/HN discussion.
* I went through the application process at a start-up where they were "really excited" about me after the first interview, but dropped me after the second because of a couple of stupid trivia questions. Trivia questions related to callable classes in Python, a feature that while interesting is (from what I can tell) little-used and extremely easy to pick up (took me 5 minutes of looking at the docs).
* I've seen groups within my own company pass up people with potential because they are 'too old to be junior developers.' (In this case, it was someone with development experience, though not too much, that was changing careers and who showed promise in his interview questions.)
* I know of particular people within my own company that are really smart, but also really harsh on interviewees. The tune seems to be along the lines of, "I'm a rockstar programmer, and if you're not too, then you're an idiot and I don't want to work with you."
* I know of places where it's generally admitted that current employees would not pass the interview process for the job that they do, even though no one thinks that they are inadequate for the position.
These are all examples of developers also doing a horrible job at hiring by finding arbitrary criteria to base their decisions on that have little to do with whether or not someone is a qualified candidate.
On the trivia-questions angle, I do think developers who've been working with a particular set of technology for a while tend to highly value deep knowledge of the particulars of that technology, and under-estimate the competence of someone who doesn't come from exactly the same background. It's not so much that they feel the detail is important, but that it becomes a heuristic of, if you don't know X and call yourself a Y-programmer, you must be incompetent or faking. Which is a tough call to make with all these permutations of experience people could have, and excludes anyone whose technology/stack experience is even slightly different.
The traditional example is interviews for C coding jobs, where when developers interview, they gravitate towards standards-lawyering type interview questions. That at least has the advantage of being a fairly stable community, though; being a "C coder" has a certain set of cultural assumptions, and it might even be true that if you don't know certain trivia questions, it's a reliable litmus test for whether you're "really" a C specialist.
This is why I never make a judgment based on the answer of a single trivia-like question. I will jump all over the map and ask about as many different aspects of a topic as I can, hoping to map out where the depth of knowledge is for a candidate. If I am getting mostly blank stares I then give them the opportunity to decide what to tell me about the subject, in case they can surprise me. Unfortunately the vast majority of the time candidates are unable to convince me that they have deep knowledge on a subject. I want to find qualified people as much as these people would like to be considered qualified. But sometimes I feel like I throw a bunch of stuff at the candidate and NOTHING sticks.
I am beginning to believe that the majority of people who consider themselves experts or experienced are really just novice or intermediate and don't realize how deep the rabbit hole goes.
Exhibit B: We code in Ruby, but are open to engineers with strong backgrounds in any interpreted or functional languages (Python, Lisp, Scala, Erlang . . .). Even a Java background might be OK, if you can show us that you are still learning and growing as an engineer. No C# /.Net engineers though: there are limits!* Ad for Principal Engineer at Slideshare
My point wasn't to paint all developers as being bad at hiring. My point is that HR shouldn't be used as a scapegoat for what's wrong with technical hiring.
I understand that it can be frustrating to feel like some non-technical person is blocking you from talking to someone that you can relate to and prove your value to. But it is just as frustrating once you get to someone technical that can understand you, only to find that that person is using equally arbitrary criterion to evaluate you.
I agree with your point, and posted that job ad in support of it: To disqualify someone because they are using C#/.NET is arbitrary and stupid, and apparently came from engineering.
These guys are trying to be funny, but in fact they probably are just limiting their available pool of talent. It's not a big deal - they probably need just one person, so they'd find that person anyway. But it does look somewhat childish.
Out of curiosity, how old were the candidates who were deemed too old to be junior devs? I'm in a similar situation myself (turning 29), and am concerned about my age being bad juju.
I agree completely. This is especially true when the KEYWORD-HEAVY-SPECIFIC-TECH is something that isn't easy for a programmer to gain meaningful experience in outside of work, like cloud computing, distributed software, or MapReduce architectures.
George, I really like your laundry-list post - and you're right, it could be much longer (at the very least, break "web programming" down into frameworks). And it inspires a thought that is only tangentially related to the OP's point, and that is the utility of fragmentation. There's a curious phenomena that when you list all of the languages out like that they all seem so...equivalent.
And yet they are only equivalent in the same way human languages are: there is a shared core of ideas that are expressible in any language, and then there are things which are easier to express in some, and which cannot be expressed in some others.
The proliferation of computer languages seems to be strong evidence to the claim that programmers do NOT believe in the equivalence of languages. And perhaps pg is right, that we already have a winner, Lisp, and most people are just too blind to see it.
I have encountered a few (too few) companies who recognize the equivalence of languages, and recognize that moving from, say, Python to Java isn't very difficult and isn't nearly the same gulf as trying to move from C to Java.
That said, the proliferation of language/framework-of-the-week projects is a serious drag on the industry. Its too easy right now to roll your own framework/JVM language/interpreter. The temptation is too great to manufacture a framework/JVM language/interpreter to solve your sort-of unique problem instead of adapting an existing one to your needs through modifications or extensions. In addition to clouding the buzzword pool, it hurts the position of existing languages because the energy that could have gone into improving language/framework X now goes into developing Y based on X instead.
Why did you list Ruby/RoR users as developers but list everyone else as programmers? I'm learning RoR so I'm curious if there's a specific reason for your wording.
I would have never noticed I did that if you didn't point it out, it wasn't intentional so I'm not sure how that happened.
FWIW I use programmer and developer (and coder, and...) interchangeably so that wasn't meant as a slight on Ruby programmers or to imply that they are somehow different from anyone else on the list.
I wanted to relo to the bay area last summer and agree.
What was more bizarre, to me, was that most of the companies never bothered to look at my sample code or projects... and a few in fact said they didn't care what I had done (and proceeded to ask me edge-case algorithms stuff).
What was most off-putting, was the incredible amount of time involved in jumping through the hurdles. I only did this with a few companies, but after you add up: customize resume / cover letter + initial/hr screen + solve this screening coding problem + initial tech screen + anywhere up to 3 more tech screens + solve this more substantial take-home problem + onsite interviews... You're looking at a substantial amount of time.
There's a misconception that anyone can hire. Tech companies are outsourcing their IT to heroku and AWS because programmers can't sys-admin. They hire lawyers and accountants to take care of legal and financial matter. But hiring? "I can do that" they think.
Worse, it isn't a process they try to improve. They don't try alternative approaches nor do they refine their process through small iterations. They have a belief in what "good hiring" is, and they stick with it. They swear by their approach, all the while bemoaning how hard hiring is. They don't realize they are the problem because, anyone can hire...
I quit my job 6 months ago, and I've tested the water a few times since then. It's a joke.
"There's a misconception that anyone can hire. Tech companies are outsourcing their IT to heroku and AWS because programmers can't sys-admin. They hire lawyers and accountants to take care of legal and financial matter. But hiring? "I can do that" they think."
In their semi-defense, they probably can do it at least as well as the vast majority of supposedly specialized technical recruitment firms, who are also largely a joke (yes, there are a few exceptions that prove the rule).
Good point. I didn't mean for the alternative to be using recruiters, but rather simply recognizing that you probably aren't good at hiring, and thus should continuously be looking at improving your process.
The other problem that I found annoying when interviewing (even with Startups) is the way the whole system is organized.
1. Talk to recruiter who is a non-tech person who doesn't really know what they are talking about and to whom you cannot really go in deep. This is the only casual conversation that you get to have about the company. (Assuming you don't know anyone there..)
2. Have phone screens which are that exactly: Ways for the company to give you a few puzzles and determine whether you based on whether you follow a certain process of solving them are actually good enough to join them. At the end of this, you are asked if you have any questions for them. In a big company, this person might not even ever work with the team that you are interviewing for. There is a good chance that after a grilling interview, you are tired and can't really have an actual conversation.
3. You have interviews at their office which again are designed to grill the candidate and don't offer any time for the candidate to get to know the people on a personal level.
I used to wish there was a way I could talk to an engineer in a company over coffee (and I am not talking about the whole lunch interview thing that a lot of companies do) and figure out what they actually do, what they want in a candidate and what sort of skill sets that they are looking for. Over the past few months, I have come to the realization that I am not sure many companies actually know the answer to that and all they are trying to do is to get the "best" without actually properly defining what that even means.
It's kind of hard to be a struggling grad student in Austin and offer to buy engineers in San Francisco coffee. :-) However, having said that, what you say does make a lot of sense.
My school was filled with either folks who went and worked for Google/FB or disappeared to work for large embedded systems firms. I wanted to work for a start up doing machine learning.
I think Google set technical recruiting back a few decades. Their process is and always has been ridiculous, but because they are so successful, everyone is copying it.
I propose that Google is successful in spite of their vaunted hiring process, not because of it.
Google's process seems to have two parts: very tough interviews designed to produce false negatives in exchange for almost no false positives, and the necessary reputation, benefits, and pay to attract more than enough talent. The problem is that most companies manage to pull off the tough hiring process, but don't have enough of a funnel to filter through.
To be fair, before them it was Microsoft. I worked at a place once that brought in a few ex-Microsoft execs and managers, and the end result was a dev hiring process that worked roughly like Microsoft's - despite us not having access to the same size of talent pool or really needing that many high-end engineers.
The end result was that we ended up having a harder time hiring, missed out on some good people, and hired some people we shouldn't have - all because we were hiring for Microsoft, not our organization.
Unfortunately, pretty much any high-profile, successful tech company will have its hiring methods replicated, even if they aren't a good fit for the company that is borrowing them. Hiring is one of the most important aspects of running a company - effectively outsourcing that responsibility via rote copying of another company's methods is a mistake.
I think Google's process is great. The result of the process is a bunch of people that are very easy to work with and smart. I never even have to think about rephrasing something or explaining it more simply; everyone operates at or above my level. The result is a very stress-free work environment where a lot of work gets done quickly. (Except when Google decides to buy out a ski resort and send us there for a couple days. Less code being committed then :)
The process does produce many false negatives, but that's much better than false positives. Hiring one bad employee can make many people miserable. Not hiring one good employee only makes one person unhappy. And they can interview again anyway.
The same thought occurred to me. Perhaps Google is like Lake Wobegon, where everyone is above average. :)
But a kinder interpretation is to note that there is a kind of threshold of intelligence which, if most everyone is across it, makes technical communication much easier. This fact mixed with (false?) humility to yield the mistake.
I think the problem with this attitude is the assumption that what you are filtering for, which for the sake of this discussion is called 'intelligence', is the sole scalar factor that makes an employee great.
Haven't we all worked with that guy (or gal) who can't explain things as succinctly as the great, super-quick-witted double-800 SAT guy, but who has something different, a creative spark, a way of thinking outside the box? To assume that that character is simply a 'false negative' that an organization can do without, I think is very naive.
It comes down to risk and reward. Google has a proven business model; maybe they don't need that extra something that is worth the risk of a few non-performers. Or, as I suspect, that spark comes mostly from people who ended up at Google through acquisition, or the few who have reputations that allow them to bypass the traditional screening process, or they were just there at the beginning before the process was so ironclad. Or they got lucky and the interviewer liked them and gave them a bit of a pass.
TL; DR: Do you really only need an army of facile, confident test-takers who are good at making first impressions?
[Addendum: it occurs to me that if you are as large as Google, you can accept a process that only produces 0.1% (or less) creative geniuses (because lots of false negatives get rejected). You may even prefer to keep that number small but non-zero (a surfeit of true creative geniuses has its own problems). But is a ratio like 1:1000 the right number for a 20-person startup? I think the dynamics are much different at a small company. Let's remember, Google is not a startup, they are one of the largest companies in the world.]
I had this exact same experience. It sucks. I actually didn't start getting job offers until I spent a week basically memorizing my entire computer science education.
It doesn't matter what you've accomplished if you don't remember what a red-black tree is you don't know how to program.
After reading some of the comments and the blog post it sounds to me everyone wants to hire like Google... but they are not Google.
In the end when you want to hire, look at what they have done and ask them about that. In my opinion thats the only thing that counts. Solving quizes does not sound very important to me.
If someone can walk you through his thought process on his favourite project you can see if he/she is able to pick up the job you are offering.
I've started just pushing the interview in that direction regardless. Generally a question will come up that's relevant to a project I'm proud of and I'll pivot the conversation over there. I've also found that if I really frame my answer as a "teaser" the interviewer will be interested enough in it to ask a follow-up.
When I'm able to pull it off I've generally felt that I've left a better impression on my interviewer.
There is a whole field of study, called industrial and organizational psychology, that researches issues like what hiring processes are most likely to obtain employees who do good work for organizations. Studies of many different hiring practices across many different industries and job categories have shown that the two most valid predictors of work performance and success in an occupation are
a) work-sample tests, if one can possibly be devised for a particular job,
and
b) general cognitive ability tests (IQ tests or IQ-like tests such as SAT scores).
Both work-sample tests and general cognitive ability tests have about the same predictive ability (predicting less than half of the variability in actual work performance, but predicting more than any other kind of hiring screen) as each other, and considerably more validity than many more common kinds of hiring procedures.
Expecting job-seekers to have
1) X years of work experience in Y technology,
2) a smooth manner in a face-to-face interview,
3) a degree in field Z from an elite university,
or any of many other hiring criteria are all less likely to identify job-seekers who will be successful on the job than a work-sample test. If the work at your workplace is so complicated and varied that it is difficult to design a representative work-sample test for job-seekers, test the job-seekers' general cognitive ability with one of the validated hiring tests used for that purpose. That can reduce the expense of your hiring process and improve its results.
I like the point about how randomness seems to be such a big part of the process. If you're not using connections and are applying through normal channels, to me it seems like there is so much that can go wrong that isn't related to your ability to do the job. Maybe the recruiter had a bunch of email that day and missed the application. Maybe the person who screened your email didn't like the font or design of your resume.
To me, one of the big problems in the process is the lack of a feedback loop. Since recruiters and interviewers rarely give honest feedback (probably for good reason), it is hard for an applicant to know if they're applying to the right jobs or not. And faced with this lack of information that would otherwise allow you to be more effective and only apply to a few jobs that would be a good fit, the strategy becomes just spamming your resume everywhere until you get a response. On the company's end, this means that you have this extra mass of applications of wildly varying quality because no one has a clue what you're really looking for.
How could this feedback loop be improved? I'm not sure.
As far as I can tell, a real shortage is basically impossible.
I come from a farming background. On the farm, when the work has to be done, it has to be done. The crop will wither away and be worthless if you spend any time waiting. That often means hiring people who are not skilled to get the job done.
On a grain farm, at least, good help are worth their weight in gold. I see some farms offering $50/hr. just to find talent. But in the absence of those good people, you still need someone to do the work. That often means settling on someone who is unskilled for, say, $10/hr. You just end up hoping the reduced pay will offset the additional costs of employing them.
The technology sector is different. The constraints on time are completely artificial. If a really good programmer isn't available today, the project can wait until he is available next month. Unlike other industries, here there is simply no reason to hire the less skilled programmer, even at a reduced salary.
I was checking out the interview questions people are posting on glassdoor.com and felt pretty stupid after going through them. I work at a successful startup at a pretty high level, and I could not tell you the best sort algorithm for some particular case. I could tell you how I would model it in a database, since that's really where large datasets get manipulated in my world. I wonder if the types of algorithm-heavy questions I see in interviews are there because these companies need that skillset, or is it to weed out people who aren't 'rockstar' or 'A Player' engineers. Sometimes it feels like a pissing contest to see who has the hardest interview. At my company, we give you a couple of real world coding tests, as long as you do ok, it's all about your personality and whether or not you seem cool to work with. It seems to work very well.
There are simply very few positions for programmers throughout the country. That includes the Bay Area. As much as everyone wants to believe it isn't true, it's true. There's very little demand and way too much supply.
Programming is a losing profession, and if you're in it you should get out while you still can. Get into sales, marketing, and/or management instead.
For the last 10+ years of my working in the programming area, the only problem that I constantly observed everywhere was hiring good people. There probably was a time around dotcom crash when supply actually exceeded demand and nobody was hiring, but that passed quickly. Normally what I see and hear - internally, externally, in conferences, etc. is "do you know anybody good that does X? We're hiring". Maybe of course I'm living in a bubble but that has to be big enough bubble to accomodate significant number of people.
You can also see it in other way. Just look at the salaries - if supply exceeds demand so much, the salaries should be pretty darn low, right? It's better have low paid work than no work at all, after all. So, are they?
>That includes the Bay Area. As much as everyone wants to believe it isn't true, it's true.
Source? Extraordinary claims require extraordinary evidence (or at least some.) There is plenty of evidence that counters your claim. (To start with, craigslist.org/sof has 90 listings on Friday while in 2004 I remember when it had like 8.)
Then apparently we're the only company that has crazy number of openings and I personally talk to people every week that aren't what we're looking for.
As a developer looking for work, I am curious what you are looking for in your future employees. Looking at your profile and comment history gives me no hints.
Perhaps you have enough people to weed through that you don't want to post here and get a few more, but I know that I am not the only developer on HN that is looking for work. I'm also certain that other people would also appreciate knowing where to look for employers who have "crazy number of openings".
What hyper specialized positions are you hiring for that none of those you've interviewed can possibly fill? Did your job listing requesting a developer get answered by waves of auto mechanics?
To echo what others have said : are you sure you're not raising the bar to imaginary and unrealistic heights? You wouldn't be the first would-be employer to sigh woefully just because you couldn't find a mythical wizard-rockstar hybrid.
Maybe the problem is what you're looking for? All of these people you're interviewing aren't capable of being trained to do the job? They're just not smart enough for that or something?
My stupid comment on the interviewing is: Go figure out how many people can do an excellent job as an interviewee, take the number, divide it by 10 or 20 - that's the number of interviewer who know how to conduct a good interview.
The only question that matters is "Can you do the job?" If you don't hear this question or for those doing the interviewing, if you don't ask this question, then there is something seriously wrong. All of the rest is pretty much a waste of time at least until after that key item is settled. With that out of the way, then it is time to worry about how well someone may or may not fit in etc (something that can be allowed for or fixed as may be). And whatever else might come to mind. But first and foremost everyone should realize that doing the job is the single most important item.
Been working at startups all my life. Got all of them but one from folks I worked with at previous job(s). Except the college hire of course - that was pre-trick-question-interview and my hobby projects caught their interest.
The 'but one' was more interesting. Moved to a new state, drove over to the University incubator, knocked on doors and chatted with people. Nobody turned me away. Two were interested, but one was moving to Detroit (no thanks!) so I took the other one. Worked out pretty good for a couple of years. Total time 'interview to job' - 1 day.
Other problem is that interviewing is a lost art. Most companies ask their developers to interview from a set of predefined algorithm/DS questions - there is no way to know if the candidate answered from his own thought process or just knew the answer. So most of the tech interview become a game of chance. I liked this article which says "let the interviewee impress you" - let the candidate show what he can do - give him a problem to solve on computer during a whole day or perhaps a week - see the results ?
We often find that there are plenty of technically qualified people out there, but what you can do isn’t the only factor in hiring. The most important thing about hiring talent is finding talent that works well with your existing talent. In other words: finding a good CULTURE fit. There are LOTS of smart people out there, but only a small percentage of those people are sociable enough to really do an exceptional job as a part of a TEAM, and teams, not talent, build products.
In my travels, I have found that "culture fit" is usually a euphemism for "we don't hire people that look different from us" . Now, before you think I'm accusing you of racism, I have found this to also include age, sex etc. So yeah, I call BS on the whole "culture fit" business
People who would work out perfectly in the R&D division of SAS Institute are not necessarily great first hires at consumer web start-ups (forgetting the potential skill impedance mismatches). There are lots of implicit ideas about "how things get done" that are part of any group. These ideas are the culture.
e.g.
Does the team practice TDD? Do they focus on unit tests or integration tests? How is work assigned? Does the team prototype ideas or discuss them in the abstract? If someone says something you think is wrong in a meeting, do you confront them publicly or privately? 12-hour days? Do you pick tools that are cutting edge or proven? Duct tape together two open source libs for one feature or write your own? And of course, the classic: Is it better to a) ship early with known non-critical bugs, b) ship on time with no known bugs, but inadequate testing, or c) when all/most stakeholders feel confident the project is bug-free?
These questions aren't nearly as binary as I've presented them (and there are many more). If you and your potential new team don't agree on these issues that's a poor cultural fit. Like a poor technical fit, it doesn't necessarily mean you shouldn't be hired, but it does merit significant consideration.
a) Making the candidate interested - I want them to be really interested in being hired, to ensure he will give his best shot (this is much easier when hiring with a specific spot in mind, which is not always the case);
b) Using a coding test that the candidate can do remotely at the time most convenient for him (http://www.codility.com/ currently - they are really good for this) as a first filter. This establishes basic programming skills, and allows me to...
c) Call the candidate for an in-person conversation and spend much more time discussing higher level questions, validating problem solving skills, and understanding the candidate past history. Unless it is remote position, in which case this will be a phone screening - notice I say an phone and not some kind of crappy can-barely-hear with-echo-or-lag-or-some-other-crap VOIP solution.
> I’m generalizing here, but I think that if I’m qualified to work for Microsoft, I’m probably qualified to work just about anywhere.
> Companies shouldn’t be turning qualified candidates.
> I feel like there are so many reasons to hire me
> I didn’t get to talk about the iPhone app I built.
Stop right there. You are not generalizing. You are talking out of your ass. I am always shocked when I run across people my age who are so arrogant. No matter how qualified you think you are, there will always be problems tougher than you have faced, hw architectures more delicate and complex than you have dealt with, and people who can blow your mind in ways that you cannot imagine. When you eventually acknowledge this, you should be grateful for the opportunity to learn what you can every day and that someone is paying you to do it. Fast forward 10 or 20 years and then we can start talking about value.
I totally agree. The whole point of the post was to point out that there are lots of good coders out there that are being labeled as bad coders because of poor hiring processes.
I agree with you that these companies are probably turning away qualified developers. However at my current job it is the prevailing feeling, and I mostly agree, that it's better to turn away a few qualified candidates in order to prevent a mis-hire.
I generally agree with that sentiment too -- having seen what a bad hire can do first-hand. However, I feel like the industry has gone too far in that direction, and may in fact be selecting for a different kind of mis-hire.
When you spend an entire interview doing college computer science quiz type questions, and none of it on process, code review, coding style, development philosophy, approach to testing, etc.... you end up selecting for people who are good test-takers, but may not be any good at writing maintainable code. Or debugging. Or troubleshooting production issues. etc... etc...
I actually agree with you. This is why I never make a hiring decision based on a single trivia question, but I do ask trivia questions that are all over the map on a topic in order to find something the candidate is good at. Honestly, if you can answer any of my trivia questions in a deep and meaningful way that demonstrates insight into the topic then I'm satisfied.
I personally hate graph algorithms and all the stupid associated questions. I have to spend two weeks reviewing all that stuff every time I change jobs to go ahead and never ever use it again. It simply never comes up in the type of work I do.
At my current place of employment, one of the engineering managers was complaining that an interviewee bombed a graph algorithm question. I asked, "Where -- if anywhere -- in our codebase do we use any graph algorithms?" Answer: "We don't." At all. Yet knowing graph algorithms is apparently a requirement for working here, which means that at minimum, I am unqualified to do my job. Sigh.
I'd much rather candidates spent time understanding memory implications of different types of java/jvm data structures, or know how to diagnose and fix memory pressure, or have experimented with design patterns to reduce memory requirements, etc. But nobody asks me. If you know off the top of your head that in the hotspot jvm an Integer is 4x as big as an int and that a Double is 24 bytes, and can figure out the rough size (8.5KB!!!) of a 100 entry TreeMap<Double, Double>, and know what compressed oops does and why it works, you'll almost certainly get a "please hire" vote from me.
edit: note that knowing a bunch about jvm memory use isn't a requirement, but knowing it will impress me. It probably also means you've been burned by jvm memory use before and that's why you know this stuff.
I've been interviewing recently and my opinion is more or less the reverse. I preferred the interviews where I was asked algorithms - only got asked on graphs once, but my last job did involve a lot of those so I was pretty comfortable with them. They seemed more useful to me than asking "trivia" type questions which you could learn in fifteen seconds - for example, I got one elsewhere about access to members of nested classes in C++, which I just couldn't remember at the time. The thing is, you can solve that immediately if given a compiler.
Personally I'd rather have a coder who understands the concepts behind these things, even if they don't necessarily know the answer right then, than one who is simply able to rattle off definitions by heart. In the example you gave, I agree that it's valuable to know that an Integer is significantly bigger than an int, and that a Double is bigger, and that your TreeMap<Double, Double> might be bigger than you expect, even if they didn't know the exact sizes of any of those things - but I guess I'd want them to be able to take a stab at working them out.
I think the point is not that someone who doesn't know about Java memory issues is useless. The point is just that someone who knows those things, but doesn't know graph theory well may be a better fit for the job, but the interview process doesn't account for this.
Well, I think the goal of these graph questions is not so much figuring out if they "know graph theory". But, rather, figuring out if the candidate had a solid Computer Science education and if they can think about a problem in abstract terms (as a proxy for being smart in general). The idea being that if those two things hold true, they can learn everything else on the spot.
I don't have a solid CS education (I studied EE in college), and I've had no trouble getting interesting, satisfying jobs at startups. Frankly I've found little correlation between CS background and whether a candidate is a good developer or not.
One of the problems is that nearly everything is an object so you end up with a lot of pointers which takes up additional space. Garbage collection isn't free either.
In this case it would have made sense to go with C++ and allocated as much as possible on the stack. It is cheaper memory wise (because you don't have to keep whatever malloc requires around and because they are removed as soon as you are done with it) and it gives better performance too.
For what you can't allocate on the stack, you a smart pointer.
There are of course pitfalls here -- smart pointers (via reference counting) can be slower than garbage collection and they have trouble dealing with cycles. You may also have to take special care if they are shared across threads.
Please cite some references on it being a memory hog, and in relation to what?
Using C++ makes the assumption that the developer can manage memory a lot better than the JVM. Especially when said developer(s) are developing high level business or web applications for example. And do you really expect developers to spend time writing code that manages memory as opposed to shipping functionality.
I don't know if you have used Java, although I get the impression that you've written C++ programs. You shouldn't be so hasty in pinning your colours to the mast so aggressively over a language. As many people on HN have pointed out it's not the language, but what you do with it that counts.
A few years ago, I applied to a senior Windows dev position. As I recall, they needed someone primarily to port existing software. One of the first interview questions was about how I would optimize shell sort for some particular edge case. The interviewer did not appear to have any papers with her that contained shell sort. I don't know if she thought I would remember it (last time I implemented it was high school), or what.
In months of sporadic interviewing, I don't recall being asked a single question relevant to Windows development, engineering strategies, how I comment my checkins, or any of a million other things which seem much more vital to me. Every interview centered on puzzles and algorithms. Every job listing was for Windows/C++ with various platform-specific technology requirements that I fit.
Personally, I think a lot of employers just like to have perpetual job openings. It makes the company look good. Also, I think that a very, very large percentage of the "screening" is really just to provide justification to the subconscious decision that was made within moments. There's a reason that Silicon Valley is almost entirely white, male, and under 40, and it has nothing to do with technical aptitude.
In small startups it's white, Indian and Asian. There are occasional women but less frequently as programmers. Women are more common as designers and sometimes sysadmins, though.
Bigger companies don't look like this. They look more like big companies all over.
I work at Google, and while you can level a lot of criticisms at it, this is not one of them. Half the employees I see around Mountain View are asians or indians. (I am indian.)
While, I'd like to agree with most of what you said. At least one of the parameters in the last statement you made can be statistically invalidated: Have you not seen the multitude of brown men in programming?
Well, honestly, no, I haven't. I've heard second-hand reports of some large companies that seemed to hire an amazing number of Indians, but I've personally worked almost entirely with white males (with a few East Asians and the odd female thrown in).
Also, I think it might be pretty much the same thing: Indian workers might be given a pass because they're "cheap" (i.e. decision made based on instant impression and personal biases). That shouldn't be happening, H1-B's and minorities should earn the same as locals, but it seems common knowledge that it's true.
"I think that a very, very large percentage of the 'screening' is really just to provide justification to the subconscious decision that was made within moments." - You are correct, but that's not because companies really want to drag you through these justifications, rather because (I believe) many are required to do so by law.
Er. Unless I missed something, you seem to have posted a link about population demographics.
I lived in Oakland for five years, among a considerable number of black people. San Francisco, just a few miles away, has a sizable (but shrinking) black population. How many blacks do you suppose I worked with in tech? (It's two, if you're wondering, and one came to the company from D.C.)
Local demographic isn't very well correlated with professional employment, particularly in tech.
If you are going to go anecdotal, here is one from me too. All Indians that I know who reside in / near Silicon valley are programmers, software engineers, computer scientists. There are dozens, if not hundreds of startups that have been founded / co-founded by non white people in the valley. There may be sweatshops exploting H1-Bs, but that is corporate greed rather than a race issue.
So if you are going to say the valley has a race problem, then one of the following things is probably true
1) You only see black and white
2) You work / have worked in some nasty institutions
3) You want to point out that there is a bias against African Americans.
1) Fail to realize that good programmers know about programming in general, and that this knowledge easily transfers from one language or technology to another. If you're looking for an X programmer with Y years experience in Z technology, then good luck with that!
2) Conduct your actual hiring process wrong, as described in this blog post. All these companies ask for "rock star" developers, yet when they actually get one to an interview, they spend all their time running them through one whiteboard exercise after another, instead of asking about all their amazing projects.
Unfortunately, I know I'm preaching the the choir here. I wish this kind of blog post could reach the eyes of HR people and/or hiring managers. Perhaps it could change some minds.