Hacker News Reader

Comment by edw519 | Hacker News Reader

I took a similar test, on-line while being watched. 4 sets of 10 multiple choice questions: SQL, unix commands, vi, & HTML. Make your 10 choices, click submit, get your score. It was kinda silly, but what the heck...

It was ridiculously easy and I got all 40 right without much thinking, as many people here would also, I imagine.

Then I asked, "Why bother with this after reading my resume?"

They answered, "We have to do this. We've interviewed 52 programmers with resumes similar to yours and no one else got them all right. In fact, the highest score before you was 32."

Wow. Is this the state of our industry now?

View on HN

It's the state of the bottom of our industry. Those 52 programmers aren't a representative set of the general population. Those 52 programmers are the ones that can't catch on for any jobs so they keep applying over and over. It's a sampling bias.

And by the way, this happens for most industries, not just technology. McDonald's has the same problem. Their majority of applicants fail at tasks like having the literacy to fill out an application form or getting out of bed and showing up to work. This doesn't mean the majority of the population is that deficient, just the majority of deadweight floating around the would-be job pool.

More generally stated, the worse an applicant is for his desired job, the more times his incompetence will attend interviews to be seen. Quality performers in any business get hired quickly and don't stay in the interviewing pool. So equivalently, any interview pool will consist mostly of bad candidates.

We need a name for this effect so that we can just quote it whenever this topic comes up, like Dunning-Kruger. Anyone got a good suggestion? Joel Spolsky was the first to set it out well and become widely read[1] , but Spolsky's Law is already used for the Law of Leaky Abstractions.

[1] http://www.joelonsoftware.com/items/2005/01/27.html

After looking for a new job recently, I realized the converse is also true. The worse a company is as a place to work the more often they need to hire. Therefore the pool of available jobs mostly consists of jobs no one wants. Be picky in who you hire and be picky in where you apply.

> We need a name for this effect so that we can just quote it whenever this topic comes up, like Dunning-Kruger.

Sounds a lot like the Market for Lemons:

http://en.wikipedia.org/wiki/The_Market_for_Lemons

Took a similar test at a recruiting company in ... 2006 (IIRC). Mostly on PHP. And the test was wrong. IIRC, I got 24 out of 25. They were ecstatic - "wow, no one in this office ever got such a high score - you were almost perfect"

"I was," I said. "One of those questions is wrong".

"Oh, no, it couldn't be - we have a team of experts who create these to the highest standards, blah blah blah.".

I asked again to go back, take a picture (crappy camera phone) and reviewed it again when I got home. It was wrong. Something to do with how references behaved in PHP5, and the exam's answer was right for PHP4, but the test was for PHP5.

Anyway, it was a bit depressing, and I don't want to have to go through those sorts of tests again if I don't have to.

"One of your questions is wrong" is an excellent filter. People should be thrilled to get that information.

I corrected two questions on a multiple-choice test that a finance firm gave me. They flushed me out after I handed in my personality test, so maybe it was for the best.

Yeah, you'd think it would be, but it's also indicative of someone who might be 'too big for their britches', or some other such nonesense. Given how many fakers I've encountered doing crap work for people (not just in software, but any service), I'm sadly inclined to realize that when I say "one of your questions is wrong", I'm very likely to be dismissed.

In the early 2003 time frame, I ended up taking a bunch of multiple choice tests about Java, C and C++. Every single one of them had things wrong. As near as I can tell, the auto-capitalization feature of Microsoft Word caused most of these problems. For example 'boolean' and 'Boolean' denote very different types in Java. In one test, they meant 'boolean' but had 'Boolean' written out.

I would definitely be thrilled. I wonder if intentionally putting an incorrect assumption in order to see if someone brings it up would be a good indicator. The idea wouldn't be to penalize someone who didn't notice the assumption, but to reward anyone who noticed the mistake and brought it up.

> Then I asked, "Why bother with this after reading my resume?"

You're aware that not everyone tells the truth on their resume right?

> Is this the state of our industry now?

Now? It's always been this bad... Happens when demand for talent out strips supply - the bar keeps falling.

"Wow. Is this the state of our industry now?"

Traditionally this happens when HR demands "10 years experience with windows server 2007" and you somehow snuck thru (or maybe worked at MS on the dev team, or were in a beta program or...) anyway by definition the only people making it thru the filter are going to have a weird/cool/interesting background or are going to be pathological liars who inevitably will only get 32 on the 40 point test, because they filtered all the real applicants out by applying a bad filter.

I guess the SQL analogy would be something like:

SELECT COUNT(*)

FROM applicant

WHERE applicant.skill > 40

HAVING applicant.skill < 10 AND applicant.honesty < 0

Without seeing any real data, wouldn't that all be a WHERE clause? I wouldn't imagine the skill was an aggregate of the applicants.

I've just skimmed over this though, I'm not having a go

Ah I was trying to imply two sets of filtering and probably have them reversed, where HR is filtering on lack of honesty which only implies lack of skill or at least average skill, whereas the secondary filtration (the having clause) would imply the test for skill.

Don't you need a group by clause in order to have a having clause?

This is yet another of those things that gets the pgsql folks all wound up about mysql. mysql is generally permissive best effort rather than restrictive follow the spec, so HAVING is allowed to reference stuff not in a GROUP BY or an aggregate (like MAX or COUNT). As you imply, this is not allowed by the SQL standard so philosophically I would Strongly Expect pgsql to error out unlike mysql. I donno what ms-sql does, don't use microsoft stuff. Oracle costs too much, so another I donno.

About 99% of the noise about mysql vs pgsql boils down to this overarching philosophical different of "try yer best" vs "only perfection is permissible". There are minor other differences aside from that, none of which I can remember at this time.

I was mostly trying to make a joke and making the psuedocode kinda sql inspired rather than cut and paste into a window like a stack exchange answer. I could have implemented it "properly" as a nested subquery I suppose. Or to make the point a little more .. obviously, just "select 0;"

That's messed up. "Having" should only be used for filters on the output aggregate functions, and "where" should be used for filters on the input row data. If mysql lets you use "having" when you mean "where", that is unfortunate.

example:

    select count(1) cnt, department
    from sales
    where department_id in (1, 2, 3, 4, 5)
    group by department
    having count(1) >= 100;

So, it filters out all the input rows to only those department ids, and then it filters out the aggregate output rows to only those with a count() of 100 or more.

This is how Oracle and MS-SQL server work.

In SQL Server a HAVING without GROUP BY is a way to filter out duplicates.

It seems to error out.

  select name, count(*)
  from queries
  having count(*) > 1

Column 'queries.name' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Like this. There is more than one way to do it:

  -- List employees who have the biggest salary
  -- in their departments
  select
      Name
  from
      Employees e1
  where
      exists
      (
          select
              1
          from
              Employees e2
          where
              e2.DepartmentID = e1.DepartmentID
          having
              max(e2.Salary) = e1.Salary
      )

It's been like that since at least the late 90s when the spike in wages versus most other jobs both increased the financial benefits from overstating your experience and decreased the cost of having to find a new job if you were actually caught, which is surprisingly uncommon.

One major factor: companies delegate a great deal of hiring to recruiters, in part because it's expensive to maintain in-house experts. Since recruiters are usually paid by the hire rather than for sending qualified applicants there's pressure to simply use the shotgun approach of sending as many remotely plausible applicants over and hoping one of them will be hired rather than spending the non-trivial amount of time needed to find a great fit. Sometimes resumes are even altered by the recruiter to add required skills – and that probably does work well at large organizations which either don't hire well or where HR tosses every word they've used in past listings into the job description.

I was once tasked with hiring some developers. HR used filtering software, so every candidate had C++ on their resume even though we didn't need that. Out of curiosity I asked each candidate a simple C++ question. Not one had a clue.

You've heard of the FizzBuzz test, right?

I heard about it in the last year or so here on HN, otherwise I wouldn't have known what a FizzBuzz was. I've been coding for 20 years professionally and 30 for fun. I've never coded a Fibonacci either. I think colleges need to teach how to code a microcontroller to do something, build a multi-platform application, build a database application, set up a CI server, etc.

We use FizzBuzz as a very basic first filter in our hiring process. It saves us a lot of interview time considering some 60% of candidates fail (or give ridiculously over-complicated implementations). Resumes are nothing but an exercise in creative writing, it seems.

Fibonacci? That's a recent invention, right?

not sure what you mean?

coding a simple function for evaluating the fibonacci sequence is a reasonable alternative to FizzBuzz that allows for some slightly more sophisticated requirements: like "code a recursive function that evaluates the first N members of the fib sequence. use memoization in your implementation and show how this runs in O(n) time complexity."

I think he was joking based on the fact that the Fibonacci number is at least an eight hundred year old concept.

Maybe the previous person was an emacs guy? Seriously, what would be a valid reason to sort employees based on which specific editor they are habitually using?

> Seriously, what would be a valid reason to sort employees based on which specific editor they are habitually using?

It's not for filtering out really good candidates, it's for filtering out abysmally bad candidates. Show me the dumbest Vi user and the dumbest Eclipse user you can find and you might learn something.

And people who've never used vi are ipso facto abysmally bad?

Ignoring ed, vi is the only sane editor that you can depend on to be installed on every system you work with. Even if you know emacs, it's common to at least be familior with enough vi basics to fix a broken system (hjkl, i, :q, :w)

The original interview was claimed to be for a developer position. If you're a developer in most companies, you never have to handle a random broken system, as usually any and all deployment or production maintenance is separated. DevOps is still an exception, not the rule.

You manage your workstation and your dev/test environments or VMs at most - they have the exact editor setup you like. The only interaction between your computers and "foreign" systems is the code version control system. Your editor, no matter how rare or exotic, is guaranteed to be installed on every system you work with - if you work on your systems, not manage systems of other people.

Even the OS doesn't need to match. You can easily code for Linux deployments on a MacOS or Win machine, and never touch any Linux computers. Heck, you even can code for Windows deployments on Linux machines, though sometimes testing that may be a mess and requires a VM - but you certainly can do that.

Unless you have the misfortune of having to work with windows systems :)

> And people who've never used vi are ipso facto abysmally bad?

A few false negatives might be acceptable.

Jeff Atwood has written about a similar experience in "Why Can't Programmers.. Program?": http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

We also set up an online test to screen candidates. Because HR and the recruiters kept sending us such terrible candidates.

I just can't understand how people don't score 100%. Alas, not many do.

It's saved us devs a HUGE amount of time.

I dislike the whole interview process, I'm only young so the interviewing process is still very new to me. We find that people lie heavily on CVs to the point where it is annoying. We had someone once who had 5 years CSS experience yet found it hard to center some text.

I think an online test would help our cause some but I don't know how simple to make some of the questions. How long would you expect the candidate to be taking the test? Do you tailor the test to the candidates?

It's dunning-kruger and lying in full swing, I feel.

Some people go like "Oh I worked 5 years in that tool, I must be magnificient in this tool. I shall list myself as highly professional in this area!" and do so.

Me... I rather go like "Hmm... Well I worked with C for 3-4 years, but I'm rusty as hell... and I didn't touch many libraries much, I just worked on tiny microcontrollers and implemented a highly multithreaded programming language execution environment. Guess I'm gonna call me <somewhat experienced> there." Though afterwards I just roll over people in an interview.

The positions on my team usually call for people that have a strong mix of business and technical skills. We get business analysts with programming that they've picked up along the way or programmers with MBAs. Typically, when the programmers get dropped from the process, it is when we test their SQL. Sad, but yes, this is the state of the industry.

And yet people still ask if automated testing is needed. I heard there's a new research project being funded called "People: They make mistakes. Again. And Again."

Reply on news.ycombinator.com