Ask HN: Can you actually get a dev job without doing a stupid quiz? | Hacker News Reader

Ask HN: Can you actually get a dev job without doing a stupid quiz?

29 pointsprotocontrol65 comments

I hate all forms of on-line/in-situ developer exams and tests. It is basically non-sense code golf in 5 minutes on an universe of problems plus all the pressure of a job interview.

Today when you have code repositories, container repositories, challenge sites (HackerRank, CodeChef, etc), linkedin, blogs, h-index ranks, ... My line of thought is: With all of this free avaliable on-line information if a recruiter still need to test if I can extract max value without a binary search tree, then he didn't do his job. What do he wants to test? If I hired a genius to build a fake developer profile for me? And then I present myself to the job interview anyway? For what?

Look at this way: If I have 130 GitHub repositories (not forks), half of them fully passing tests through CI, my issues reports, my PR's, my own code metric reports including object-coupling, cyclomatic complexity, Halstead, Hansen metrics and all the stuff... should I really spent 3 months to practice how to add without + operator? And then get on-line interview just to discover they want me to write a k-partition problem solver?

There are companies which do not rely on these stupid stressful tests?

View on HN

There are lots of companies that don't do these kinds of tests.

It's been a while since I've done a job search, but several people I know have done them recently. And they've all found that some companies - mainly big tech companies, along with tech startups of all kinds - use these kinds of tests heavily.

Other companies that hire lots of developers - like banks, insurance companies, and manufacturers - don't seem to use these tests nearly as much. They'll sit down with you, talk about your experience, and the systems you've built.

At this point, if they like you, they'll often give you a small test project to do. And when I say small, I mean small - probably an hour at most. And while these projects can be annoying, these companies seem to give it after they've interviewed you and they're serious about moving forward. I don't mind this approach. There are lots of people out there working as developers who write truly awful code, so I think it's fair of them to want to see something from you before making an offer.

Working as a developer for a non-tech company might sound awful, but some of them are actually really great places to be. From what I've heard from devs I've talked to, many of these old school companies are actually really progressive technically, pay their developers well, and treat them with plenty of respect. And they tend to very sane work hours too. If your manager sees you still in the office at 5:05pm on a Friday, they'll probably tell you to go home. :)

Another thing the non-tech companies you mention will sometimes do is contract-to-hire. The hiring process for my current job at $BigBank was: Phone screen with recruiter. One hour interview with a couple developers. Follow up phone call with manager. That's it. Because CTH gives them months to evaluate actual skills in a real work environment before deciding whether to convert you or let you go.

It's a great arrangement for those of us who do really good work but tend to interview poorly. Probably not so popular with those who BS well in an interview but can't back it up...

The pay isn't FANG, but can be decent if your manager likes your work and you don't let HR lowball you.

Let me preface this by saying I despise whiteboarding as much as you do. I’ve been rejected from jobs dozens of time, and only got a handful of job offers in my ~10 year career so far.

But - all interviews are, in essence, is an exercise in virtue signaling. Can you do the local dance to prove that you belong?

If anything, whiteboard interviews are not the worst thing ever. I am from a Western European country, and my dad is a chemical engineer at a large chemical company with 30+ years experience, many patents, books, etc.

When I explained to him the interview processes I had to go through to get jobs in Silicon Valley, he exclaimed “oh wow that’s great! I wish we had that! Our interview process is a 1 hour conversation with a manager, and if you went to the same school as them or share the same hobbies, you get the job. We hire so many mediocre people because of that, I wish we actually asked them to solve technical problems”.

Now that I think about it, I actually declined a job offer once from a startup because their interview process with me was a 1 hour presentation where I showed some of my work, and then a phone call with HR. I thought to myself - wow, this is too easy. If I get an offer this easily, what caliber of people am I going to be working with?

Pick your poison.

My first boss used to do a short quiz just to weed out anyone that was wasting his time and that was that. But of course programming culture is hypertoxic so that's been turned into the roommate interview scene in Shallow Grave.

Programming culture is not hypertoxic. Maybe it is in the United States in the UK pretty much everyone just sits down and gets on with it.

Speaking personally, I was a bit surprised at the culture I experienced the first time I worked alongside younger American programmers, as opposed to my prior experiences with remote offshore teammembers, onshore H1B programmers, and the American greybeards from the earlier IT era.

In my general experience. I think with younger men in their twenties it can be a little difficult if management lets them get away with being a bit too unprofessional. They wanna prove themselves so sometimes a bit too much testorone in the room can cause a few arguments. Once everyone is past 30 that normally stops.

Indian developers in the UK have essentially got won the Willy Wonka Gold ticket as the salaries in the UK are much higher and they just work 12+ hours a day and keep their heads down. There is a higher number of female developers in my experience come over. But that could be just my impressions.

I work in the US with engineers, techs, and business side people who obviously aren't programmers as well as software people. What I find is those people's culture is much less toxic than software[1].

However my experience with a couple of UK programmers was they were alright.

[1] Except for game developers and embedded.

Tests like these are a relatively effective way of weeding out people who simply aren't up to the job. You can say anything you like about yourself, and you can curate your online presence to make yourself look like an experienced, competent developer, but your code doesn't lie.

I agree that tests can be bad, frustrating, badly designed or just plain incompetent - but ultimately I'd rather hire someone who knows what they don't know than someone who thinks they can wing it. When I've been tested like this in the past, I just explain which questions I can't answer and why. If they want to talk it through, then great. If not, then do I want to work for them anyway if the attitude seems negative?

The real issue you need to overcome is fear of failure. Aside from some specific cases, nobody in the hiring process really cares whether or not you 'pass' the test - it is (or should be) more important to assess how you approach the problem and whether you are capable of acknowledging what you don't know and talking through your thinking.

I think the only interviewing process that really works is to invite the candidate to work for one day, side by side with their future team.

This also gives the candidate a glimpse into the culture behind the HR marketing bs.

Agree. We just recently went through a failed employee hire (even though we had a mini project for the candidate) and in the retrospective we came to the conclusion that our whole team was first hired as a contractor and then later converted to an employee. So we’re going to just keep doing that from now on.

How do you decide whom to hire for the contract role though? ;) A bad hire should indicate that your mini project missed testing something important for your team. In my own experience with an intern who didn't live up to my hopes, I realized I wasn't testing for the ability to read code not written by them, whose whole they cannot hold all in their heads (only a contextual part at a time), and make some changes to it. I do that now.

You do lose some candidates this way. If I'm already leaping from one stable job, I'm not going to roll the dice on a contract position. Sure it will probably work out, but everyone should already know not to trust promises made during the recruiting process.

I'm going to second that. I don't ever consider CTH, and there's a pretty strong body of programmers who feel the same way. There's too much risk in it.

My latest job search (Oct-Nov 2018) involved 6 different companies all requiring quizzes or live coding (I only applied to 100% remote jobs). I got "code an elevator controller", "code a number guessing game", "architect a analytics system to handle 1M data points for under $2k per month on AWS", "build a react app to let users pick a timezone and display the current time in it", "code a tic tac toe game", and "build a reusable dialog box component". With each exercise taking about 2 hours, it was a significant chunk of what could have been billable time. One company made an offer (the number guessing game one), which I accepted. In the end it was my open source project on github that won them over.

The technical questions given during an interview are not only used to see if you are competent programmer, but they are also use to see how well you communicate and how well you work in a team.

I think it depends on the company and where you live. This culture may be prevalent in Silicon Valley, but less so in other places. I live in Denver and every interview process I've gone through is different.

For one, I walked in and they handed me a laptop and a paper with a list of requirements for a REST API with some sample data and said, "We'll see you in 3 hours".

For another, I had 5 in-person interviews, none of which included any coding, whiteboarding, quizes, etc. The closest to that was "Describe the architecture of a system you've built".

For most, I'd say there is some amount of coding involved, but they rarely involving writing code on a whiteboard or solving a "quiz". Usually the coding I've had to do is at a computer, like pair-programming, or a project submitted ahead of time.

"Quizes" are the reason I've never even thought about applying to any of the giants, like Google / Facebook. I don't like them either, but I don't mind showing off my coding chops.

I've personally never been quizzed for a position. I know people that have in the same general area so I don't think its consistent; I've just been lucky.

As for adding without the + operator, a + b = a - -b :)

What you're effectively saying is that, if the recruiter puts enough effort in, they can find out how good you really are.

This is, of course, true. The problem is that that's not the problem they're trying to solve. What the recruiter is doing is finding people that have a high chance of meeting their criteria in a reasonably scalable way. Or facetiously, you may think it's about you but it's not.

Now, most of the ways they go about this aren't actually that great. But having the recruiters running around after you will definitely be worse.

I am freelancing via Toptal, and you have to pass the entrance exams (which are hard and include live coding), but that is the last time you have to do it... at least that is my experience with 5 different contracts in last 3 years there.. after entering, no one asked me to pass some additional quiz. The clients there seem to trust the system -- i.e. once you are in, you passed the bar and there in no need to waste time testing your abilities again.

The developer evaluation process is broken, sometimes because the people hiring you do not even understand what you do and sometimes it is because what the interviewer is testing for is not properly communicated to the candidate for various reasons. The best way to get a job is to be in a developer community where you get referred to jobs and not by job searching online. This is how top-tier candidates get jobs in every industry, referrals, it cuts all the bullshit. So your goal should be to get to that level which means upping your social skills, that being said we all need to start from somewhere.

I wrote a post about this a couple weeks ago, on the disconnection between what an employer is looking for and what you (a developer) think they want. I hope it helps someone

http://blog.adimofunne.com/coding-interviews/

> referrals, it cuts all the bullshit

Referrals get one out of the internet-resume-void, but you still go through the standard interview process, right? I've always seen referrals as a "guaranteed shot at the interviews coding games". Am I doing it wrong?

Unless I have copious free time (and I don't) then I'm not going to browse 130 Github repositories and wouldn't known from Adam if they are forks or not (unless they were all created close together). Thus I cannot trust the metrics from them either

LinkedIn, blogs - not exactly reliable sources of information given they are what you are saying about yourself. We've had candidates list the number of Instagram likes they had as if it proved anything. Sold some t-shirts on Cafepress, wow you must be an incredible developer / entrepreneur then

I have seen some amazing code in a Github repository that the candidate couldn't explain to me. I suspect it was a joint project that someone else was a major contributor to

So yes I will want to verify / test your abilities

But personally I read a CV and then talk to the candidate. Worked well so far

Would you say then an online persona doesn’t matter much? I think about this a bit as an undergraduate hoping to land a gig in a few years. I could care less about having a technical blog or a tailored Github/Gitlab account contributing to open source or having an LinkedIn account, I just want to build cool stuff and become a good programmer and not have to worry about showcasing that on the internet like a clown in a circus. But on the other hand, it seems like companies look for that kind of stuff or at least give you the upper hand for it.

LinkedIn is just an online CV for recruiters to find you by. The one you submit should be tailored to the job you are applying for

The CV that lands on my desk will determine if you get called for an interview. One or two sides of A4 is all you need. We only look at Github if the CV is interesting enough

If your CV says 'I have a CS degree' rather than 'I am a programmer' then I'm not going to look any further. I have employed excellent programmers this way. Only one of them had a Github account. None wrote blogs. Didn't even look at LinkedIn

Github can be interesting to see what languages you work in and what topics you found interesting when satisfying your own needs. But I will only look if the CV makes me think that it will be interesting

Github, LinkedIn and blog posts are merely supporting documents for your CV. If the CV sucks then it goes no further

An online persona is like client-side data validation. It's a nice to have, but it cannot be trusted. You should always have server-side validation anyway. That's what tests/assignments/interviews are for.

This is super interesting response.

Because today's research on code plagiarism is huge (this mean years spent in code re-engineering by really clever people), and I could argue you could use just one employee to develop a profile crawler and validation workflow, isn't so? I am saying you could automate the browsing and just discard Adam if he's below your threshold.

Thank you for your reply.

Here is a repository of companies that don't force you into solving fizz buzz problems: https://github.com/poteto/hiring-without-whiteboards

Half of the companies on that list are even worse. Don't make me do a n-hour bit of homework without paying me for it.

Assuming n isn't very large, I don't see why. People will spend sometimes days in on-site interviews. A simple coding challenge can tell you a lot about a developer and provide a shared basis for discussion in a subsequent interview. Of course "build a CMS from scratch" is ridiculous but simple simulated bug fixing and small feature additions that mimic real life work can be quite useful and not time consuming.

As someone who has spent a lot of time implementing & arguing for work sample based hiring, the hardest part is getting places to remove the useless interviews from their filter process.

Very few devs given the choice between 8 hours of interviews & 7 hours of work sample/1 hour of interview will choose the former. But companies just add the work sample & leave the interviews defeating the point.

They also test conscientiousness.

But, yeah, having just gone through a round of interviews I think there's a big range of quality at work in these, and passed on some companies because of how irrelevant their prompts were or unstandardized their processes were.

In most software companies you are required, as part of your job, to communicate effectively with people who might not agree with you. That includes clients and co-workers. Including situations where things are heated and stressful. White board tests are great for finding out if you can stay level and communicate clearly in a stressful situation. Calling things stupid and slamming the door just shows you are not capable of doing a lot of real world software development jobs. Which involve a lot more than coding software.

For every developer that complains about a coding “quiz”, there are a dozen more candidates that have been weeded out by them.

You’d be surprised by the number of candidates who say they are “senior software engineer” or “10 years experience as a lead developer” who still can’t do FizzBuzz. Or the ones who can do it but takes them 100 lines of code.

I’ve also turned away candidates who didn’t want to do a simple coding test, but still wanted to work with us. Entitled people are just as damaging to a company as incompetent ones.

> You’d be surprised by the number of candidates who say they are “senior software engineer” or “10 years experience as a lead developer” who still can’t do FizzBuzz. Or the ones who can do it but takes them 100 lines of code.

I see comments similar to this one all the time. Are folks literally referring to the 'FizzBuzz' problem, or is that just an alias for a problem they subjectively find easy?

The problem I see with FizzBuzz is if you knew the problem, it would be super easy to remember. Otherwise, with the time pressure, anyone could fail just as Federer could fail a simple shot. You need a whole game to prove he's Federer, you follow me?

Most places aren't so much looking to make sure you know things, they're looking to see _how_ you do things.

It's all designed to fuck you over. Ignore whatever they throw at you. They're rejecting you by default, if they subject you to the quiz show.

That's the real lesson of the coding quiz. You are rejected by default. Take aims to flunk it by default, is the natural response.

Look at it this way, how does someone verify that all the work done is by you ? Even if it is its not within everybody's range to test someone on code from 130 repositories. Just memorize the quiz nonsense, the market is asking for shit prep so give it to them.

Isn't that true for any job ?

When you send your curriculum to recruiter, why should they believe you, whatever job your applying to ?

So if you start a relationship based on a non minimum trust, will it go well ?

Of course, this is all theorical, and how it should work on a perfect world, which this one isn't.

If you think about it, really all relationships start out with zero trust.

You'd think it would be possible to create some sort of certification system so that we could prove we are clever and can code once rather than having to prove it again and again.

Between having to endure a "stupid test" and have to shelve a wad of cash just to get a very expensive piece of paper, give me the stupid test every single time.

At least the people doing the stupid tests are checking for stuff that is relevant to them instead of wasting time with pedantic aspects of a programming language or tech stack.

> Between having to endure a "stupid test" and have to shelve a wad of cash just to get a very expensive piece of paper, give me the stupid test every single time.

Why not go fot the idea that one pays the cost in advance, but as soon as you get hired, the future employer will repay the costs to you?

Because paying is the problem, and expecting that prospective employers would pay for your expenses for a test that is used to infer basic competences is at best wishful thinking.

We only need to look at the current state of qualification mills/moocs to get a good idea how job seekers would be fleeced by these so called certification systems.

It's far better to get in front of a prospective employer and solve whiteboard problems than just be a number in a clueless HR drone's database.

> Because paying is the problem, and expecting that prospective employers would pay for your expenses for a test that is used to infer basic competences is at best wishful thinking.

I am cautious with this kind of statement, since this saves the respective company time to check these competencies by itself, which is a pecuniary advantage for the company (since it can obiously use this time to earn money).

I imagine a 2-3 hour test that costs something like $200, which seems like a reasonable investment, if many or most employers are looking for it. For the companies, it would save an hour or two of interviewing. If they accepted the test as indicative of basic coding sanity, they could then focus their interviews on more general or domain-related skills.

> I imagine a 2-3 hour test that costs something like $200, which seems like a reasonable investment

Nowadays you get the same result or even a better one by spending zero to do the prospective employer's test. It is not an investment nor it is reasonable. Companies already dump preliminary screening on specialized HR companies.

> At least the people doing the stupid tests are checking for stuff that is relevant to them instead of wasting time with pedantic aspects of a programming language or tech stack.

I've done a lot of interviews, and many of the questions have been very generic, with nothing whatsoever to do with the job I was interviewing for. I've reversed a lot of linked lists in my time, and I was once asked to solve FizzBuzz.

I don’t mind a simple test to verify skills. But from there tech companies should be able to evaluate prior experience, which they seem to struggle with.

Sure you can consult and if people appreciate your work they often approached you themselves about joining their work force.

Adults find their way through the world as it is, not how they want it to be. Grow up. When you've earned a bit of freedom from the stupid gatekeepers, you can do it your own way (entrepreneurship, networking, contacting, etc). For now, pay your dues.

I get what you're saying, but seems a little harsh. And also makes me think of:

"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw.

Personally I can't stand these tests either. I normally complete them fine.

However I've been to job interviews where they force me to code live in front of several people and I couldn't get half a line of code out before one of them will chip in with a "suggestion" breaking my train of thought. The code they want me to write is some algorithm that they have expected you to memorise.

I normally leave the interview frustrated and even when offered the job I turned them down because the hiring process has given me a bad taste.

This could actually be the test in itself. There seems to be a substantial contigent who believe that this is what a collaborative programming environment looks like, and they might actively want to select against people with a more shut-the-door-and-work-through-the-problem mindset. I'd argue that a pair programming exercise is probably better than whiteboarding-with-interruptions, but setting that up well is more work for the interviewer.

Edit: completely messed up the quoting in original!

If the test is like that I have zero interest in working there.

This is for two reasons

1. I don't like silly games in interviews. You aren't respecting me or my time before I am working for you, you aren't likely to while I am working for you.

2. I personally like to be left alone while working on something. Then again I find scrum calls etc a total waste of time.

Great point on this possibility... A big source of brokenness with tech interviews is that so many interviewers want to setup an interview (often adversarial, where the interviewer holds more cards) where candidates get ranked primarily on subjective hidden variables. If the real test isn't the given test, the interviewer sucks. Measure as directly as you can what you care about, whether it's technical criteria or softer criteria, and if the answer is on one candidate's resume but not another's, ask about it rather than assume the other doesn't have it. Want to know how the candidate collaborates? Prime them with that expectation, that the problem solving is a joint effort. Want to know how someone functions in the face of conflict? Ask about their experience with conflict and resolving it, rather than try to setup some conflict and seeing how they respond (or don't). Want to see if they can write a good unit test? Ask them to write some tests rather than saying something vague like "develop as you normally would". Whatever it is, the important part is making clear to the candidate as much as possible what is the hidden state in your head that you're using to evaluate them.

My own dream as candidate/interviewer is to spend some hours trying to solve an interesting problem together that neither of us has solved before. Unfortunately it's not repeatable for the interviewer (at least once it gets solved, until then there might be a way with a big problem to bootstrap a candidate to build on past candidate+interviewer's efforts), and even then its main use is judging "works with the interviewer well" when there are probably better things you should be measuring in most cases.

A slight aside. I had a really good coding assignment once.

It simply said "Make a working clone of this webpage, zip it up and file it to us".

I could have just nicked the jQuery code (this was before a lot of the frameworks have taken off and everyone abused jQuery and I worked at a place that used vanilla js for performance).

https://pastebin.com/NvGm89cR

Lack of controlling for anxiety is probably the biggest contributor to false negatives... At least you got the offer though.

On the interviewer side of the table, I had a candidate and there was a stretch of silence after they confirmed they understood the problem which I interrupted with "Is there anything I can help clarify?" (I can't observe internal state!) They asked me if I could be quiet for 5 minutes while they thought about the problem. That's fine, I did so. Maybe you can ask the same thing next time if interruptions come too frequently? If they don't respect the request to shut up, that's a useful signal to not work there too.

Lack of interviewer experience can also account for some of it. Unless everyone in a room with more than one interviewer has their turn at questions, I'd expect the silent ones to either be shadowing so they can interviewer, or be overseeing a former shadow take the reigns. I think an interviewer needs to do as little as 10 of them to run the style range of people who need some quiet time to silently think, to people who ask lots of questions, type some, ask more, type, to people who easily vocalize all their thought processes while typing things; the interviewer may also importantly see that despite the style differences the time to get to the same place (if they get there at all) doesn't vary by much...

I normally just wanna hack out a problem first, work out for myself what the short comings is with my first approach and then make all the relative changes.

I'm a bit confused by your reference to HackerRank -- is not "extract max value without a binary search tree" a kind of problem that might show up there? Is it that type of problem you're complaining about, or the fact that you've already done enough in public that you shouldn't have to be subjected to it again time after time?

If it's the latter, a counterpoint is that doing these sorts of tests (usually not strict pass/fail ones but ones with levels of progression or orthogonal points of detail like "handles the divide-by-zero case without it being pointed out") lets me rank candidate A and B in a consistent and arguably more fair way. Sometimes A will have lots of impressive github contributions, while B will have nothing but schoolwork to discuss. Personally I'm unwilling to automatically grant the job to A on such a basis as publicly available work artifacts, or indeed anything on their resume (such info probably made it easier to get to the interview stage, of course) so I test A and B the same way. I might expect A to do better, but I give B the chance anyway, and B sometimes does way better. If A's past work/volunteer experience isn't directly related to the jobs which they'll be asked to do, how valuable is it? I think minimal. (It may become more valuable in the future, but such hidden future utility applies just the same to B, just in likely less obvious places such as the ability to read a crypto paper and pump out exploit code in a couple days rather than a month or two.[1])

All that said, I'd love it if I could just give (and as a candidate, receive) a certified IQ test (or perhaps the https://en.wikipedia.org/wiki/Wonderlic_test) and OCEAN personality test once every n years that can be reused. A lot of jobs don't require anything else but "smart and gets things done" (i.e. high enough IQ and trait conscientiousness). Maybe something fizzbuzzy in addition in order to lower job onboarding costs, though you'll find anecdotes of companies hiring smart people who couldn't program and successfully training them / otherwise supporting their education to become good programmers.

My advice for finding a less-BS job besides the already-linked no-whiteboards repo (which is a bit suspect since I know at least one company on the list shouldn't be in general) is to find one that isn't in high competition from candidates (they're more likely to shorten the process to find someone good enough, i.e. "smart and gets things done") or one with a very defined job role (in which case they'll test you on that knowledge specifically if your public contributions don't make its presence evident rather than give the usual generic quizzes that sort of act as proxies of IQ or ability to do real non-quiz work).

[1] https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

IMHO I did enough coding, even wrote papers, just to find recruiters didn't eve bother to read the titles.

Your reply makes me thought about a community certification test, taxonomy or classification of company profiles. Which as far as I know it doesn't exists.

Wasn't the IQ tests somewhat discarded by Stephen Jay Gould work? https://en.wikipedia.org/wiki/The_Mismeasure_of_Man

Recruiters hardly ever seem to dig into things... But if you get far enough in the process, the people doing the interviews sometimes will dig a bit. Sometimes. Sometimes they print off your resume 10 minutes before, ask one or two things about it, and throw you a couple whiteboard problems to take up the rest of the time.

A college degree in CS or related used to be a kind of 'community certification test', but then interviewers started getting bad candidates even though they had BS or MS degrees, and when they started testing for ability to program a FizzBuzz, found that some MS students couldn't do it! So its value as a test has gone down significantly. This is why I like the idea of an IQ test better, because it can't be cheated and corrupted the same way.

Classification of company profiles is kind of what Glassdoor et al. purport to be, but sometimes I can get the feeling I won't fit in just from the company's website and how it represents itself (especially if they have a dev blog). e.g. One company had a picture of a scrum team doing pushups together at standup. I'm not opposed to exercise, or the idea of getting together with some coworkers to go work out at a gym, but I am opposed to such group dynamics and conformity pressures at work. If I worked on a team that already had the established culture of doing pushups during the daily standup, I would decline, and that probably indicates there would be other cultural problems down the line.

I'm not familiar with Gould's discussion of IQ but I generally don't trust Gould's work at all and don't bother reading it. https://www.lesswrong.com/posts/BahoNzY2pzSeM2Dtk/beware-of-... convinced me of that, what he did to evolutionary biology isn't really forgivable. From the first sentence of your wiki link I would worry he did the same to IQ research by representing everyone in the field as whatever he characterizes are "biological determinists". IQ is merely the best single predictor we have for a large variety of "success" metrics. Its validity predicting job performance, as one of those metrics, depends on the job and can range from 20% to 80% (i.e. knowing nothing about a person but their IQ, for some jobs, you can predict their performance bracket accurately say 75% of the time -- they will be better or worse than predicted the other 25%). I suspect software job performance would be towards the upper end of predictive power. Throwing a second data point of Conscientiousness in, your predictive accuracy rises even more, but Conscientiousness alone isn't as useful as IQ alone.

no :(

I'm honestly surprised by the amount of people complaining about the interviewing process. First of all, have in mind that the interviewer should have some kind of an objective measure, you need to judge all candidates the same way. There are many great developers who don't work outside of their job, so GitHub is out of the question. LinkedIn is self kept and doesn't really show your skills, just your CV. Reaching high levels in HackerRank takes a lot more time than the interviews probably, and you still have no objective way to judge candidates.

And this is where interviews or coding problems come. They allow the interviewer to judge your ability to code and compare it to other candidates. And, probably even more importantly, your social skills, which in a team or in a relatively small company are essential.

But... Why go through all this? Other professions don't do it, right! Well, at least in Europe, most other professions aren't even nearly as well paid as even a junior dev.

Reply on news.ycombinator.com