Hacker News Reader

Comment by btilly | Hacker News Reader

I certainly hope that they don't ever assume that experienced candidates don't need a programming test.

There is a particular kind of dysfunctional candidate who once was a programmer, graduated to being a lead programmer, and then became an architect. As an architect they stop programming, and their programming becomes rusty. Once that happens, the feasibility of their proposed "architectures" becomes steadily less practical.

You can detect them by their first getting offended that they would be asked to program during an interview, and then failing to actually write working code.

By contrast people who really do program have no objection to being asked to program in an interview. To the contrary being asked to actually program is seen as a positive sign that they won't have co-workers to deal with who can't actually program. (This is an unfortunate experience that most programmers try not to repeat.)

View on HN

I have declined some programming tests, when the employer wants yet another three hour challenge to build a mini app. That leaves not much time for actually thinking about a problem and rushing out a crappy solution. Not the way I like to write software. I have code online I can show them and talk to them about, and extend if they want to see me actually code.

Bashing out code is usually the simplest part in writing a software solution to a problem.

There is a difference between "demonstrate that you can program" and "waste X hours on busywork".

I write lot of code, but I refuse to do coding at interview. For me its sign of dysfunctional company. But I do not mind to do pair coding, and fix an actual bug.

There are more reasons, in short it takes me couple of hours/days to warm up and grasp the problem.

And secondly I refuse to waste my time, on half arsed throw-away code, with zero results.

> And secondly I refuse to waste my time, on half arsed throw-away code, with zero results.

That's a very wierd thing to say. Does that mean that each and every side-project that you do ends up being substantive? If writing few lines of code gets you a job at a good company where you can spend your time working on exciting problems how is that wasteful?

I do program a lot too, and I typically don't mind writing code in an interview. The only thing that sets me off are stupid level-order binary-tree traversal questions which test nothing but rote-memorization skills.

Most of my code is thrown away. But I like to finish stuff, so there is a chance I spend next weekend finishing/polishing the interview questions. It is great for career, but has to be managed.

Also my job is to design database structures, and there is no such thing as simple problem. Even binary tree needs thousands LOC for tests, concurrent access, writes...

I mean you should know how the basic data structures work. Not necessarily for a web dev job but for a software engineering job. Data structure interview questions are a good small concrete problem to reason about.

But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc...

> I mean you should know how the basic data structures work

Oh I'm not discounting that. I'm just saying that off the bat binary-tree traversal don't really test my understanding of the data structure. Recently in an interview I was asked a problem which eventually required using a binary-search-tree to improve the running time. This, I believe, is the right way to test but it requires the employer to spend more time designing interview questions rather than relying on a problem bank[0]. (which is a strong filter for good companies in itself)

> But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc...

This is true but this is really really hard to test. In the interviews that I've been giving, I've indeed been asked design questions. I assume soft skills are implicitly tested while speaking to the interviewer (to some extent, at least). But other factors, AFAIK are very hard to test. Also, I would argue that a candidate doesn't need to know everything coming in. Estimates, timelines etc can be learnt on the job.

IMO, if somehow employers could find a way to reasonably trust that the code I have on my Github is indeed written by me then I think that should be strong indicator of my competence. Evaluating candidates who don't have any code in the open is a different matter altogether to which I have no solution.

[0] - http://leetcode.com

No offense, but I'm skeptical of responses like this. If you need a few hours or days to "warm up and grasp" an interview question like fizz buzz or card shuffling, then you're just not up to snuff.

For every good developer offended by coding in an interview, there are 50 idiots who can't code, who are using that as an excuse to con their way into jobs they're not qualified for. IMO, it's an acceptable trade off.

If you're that awesome you wouldn't be going through the usual interview process, anyway.

I find people that quickly do fuzbuzz type problems to be worse on average. The only way you can validate your interview assumptions is to randomly higher people you would have passed on. You could compare how important you think X is vs. how predictive it was for on the job skills, but few people actually onboard enough people to get good data.

Sometimes I've noticed I just don't "get" the problem being posed. Either it's because of ESL or well I just don't focus very well sometimes. It takes me a bit to figure out what's being asked and at that point it's usually very easy for me to go think about the solution and assumptions and such. But it does happen.

Unfortunately my bugs are typically too gnarly and need more context than a 1-2 hour interview allows, or I'd definitely incorporate them into interviews. In the best case, it's like free labour!

Then I'm OK with not working with you.

Even if you are exactly as you claim, MOST people who claim "I can code but don't care to demonstrate it during an interview" are actual disasters as co-workers. I've been there, done that, cleaned up the messes, and would prefer to pass on some good people to avoid that.

And yes, you do have to pass on some good people. There are competent programmers who freeze up during interviews. You do what you can to make the interview as accommodating as possible, but some people can't show what they've got. However the opportunity cost of passing a good person by is far less than the damage from hiring a bad one. This leads to being risk adverse.

I guess people get scarred both ways. I've certainly been on 20+ hour interview processes that have left me with an awful offer at the end which I just could not take.

Personally, I've never been a part of a company where the code test isn't:

1) Short (1 hour) 2) On their own time 3) A real problem (algorithms are OK in my mind as long as you help them with the core problem)

I do not expect everyone to know every algorithm... I guess it is kinda weird if you do not know Dijkstra's algorithm, but I only think it is weird because the courses I took focused heavily on it and similar algorithms.

But, do I want you to know all the same stuff I know? No, definitely not. I don't want 2 of me I want me and someone else that works well with me but ultimately has their own ideas.

So less "dysfunctional company" and more "I'm not good at it so you suck!"

Could this not be solved by telling the candidate what you expect and then telling them that if they can't program to the expected level that they will be fired on the spot. Leave it to them to demonstrate that they can program before or after they are hired. If the candidate can then they will be happy to demonstrate after they start. Everybody is happy.

I don't think so.

First of all nobody sane would take a job where they are expected to measure up to some unspecified measure or else get fired on the spot. And any competent HR department will tell you that carrying through on the threat will risk the potential for lawsuits. (They want a paper trail showing that the person should be fired.)

Secondly it takes a surprising amount of time for an incompetent programmer at an average organization to get discovered. You usually spend a period of time studying how things are set up before anyone expects you to do anything. And by the time you can be evaluated you've certainly used a bunch of other people's time with your questions. It is far more efficient to determine this in the interview process.

And thirdly, a creative company can more easily solve the problem by offering a choice of ways to demonstrate competence. See http://www.starfighters.io/ for an alternative to traditional interviews.

Pretty much every job I have had has had a three month probation period.

This just means you can be fired for any reason in the first 3 months. You can certainly be fired on the first day.

It is not illegal to fire someone who can't do what they were hired to do especially when they were told what was expected at the interview stage.

My thinking is the first x days on the job is spent doing programming tests. This should generate enough paperwork to satisfy any HR department. You then have the time to test all aspects of the candidates skills, rather than the limited range you can test in an interview.

That works.

In a lot of the US not only is it not illegal to fire people for incompetence, but you don't even need a reason to fire them. But stupid people when offended sometimes launch silly lawsuits alleging all kinds of crap, and those lawsuits can be expensive to defend. A lot of what HR does is stuff to reduce the frequency of such lawsuits, and to make the ones that still happen go away more cheaply.

My thinking is to move off the time and expense of testing candidates from the interview stage to as late in the process as possible. A really though test of a candidate is time consuming and to do it at the interview stage is not fair on the candidates and the company. You can provide any candidate with the full list of what they will be tested on in their first x days so they can decide if the job is for them or not (i.e. everyone is upfront with what is expected).

The only problem I see with this approach is Dunning-Kruger effects. My experience in hiring is it is pretty easy to pick candidates suffering from DK by comparing what they say with what they can demonstrated via their work history. It is the more marginal candidates where they seem non-delusional, but where they don’t have a perfect CV. These people are often overlooked by other companies, but they often turn out to be fantastic employees. Taking a chance on them can be a great.

Gee, that's the path I followed. Now as a chief architect, I guess I can't code anymore. Good to know!

Implication is not commutative.

The OP wrote a blanket statement stating if you follow this specific path you become "rusty" and ultimately end up not being able to code. He then states this becomes an issue when architecting solutions.

To me this is clearly non-sense as someone who's followed this path (and know others who have as well). Being an architect allows me to see the big picture and move the organization in the right direction (as we see it), while still being able to get into the trenches with my developers when something arises or help is needed. Granted, this is different for large enterprises but for startups/small/mid sized businesses, yes, us architects still get our hands dirty (or else we're irrelevant).

No, that was not what I said.

I said that there is a specific kind of bad candidate to watch out for who generally HAS followed that specific path.

I DID NOT say that ALL people who follow that path will become that kind of bad candidate. Or even most. Just enough that you can't afford to say, "This guy has been programming for 15+ years, is an architect, and sounds smart. I'll skip the programming test."

It is about your skill set, not your title. I have met architects who were unbelievable coders. And ones who were nightmares. But every good architect that I know was also a good programmer. They might or might not actually spend much time programming, but they clearly could do it.

My understanding of the reason is that a good architect needs to be able to mentally connect every level from abstract architecture down to actual code. If you can't, then you'll eventually absorb ideas that sound good but don't really work in practice. (A random example that I dealt with was someone who didn't understand the latency added by sequential RPC round trips. And that the latency gets worse if you're making the mistake of using XML as your on the wire format...) And the failure of said ideas can always be attributed to programmers having screwed up your brilliant architecture.

For the record, this observation about architects is not original to me. I spent a year at Google, and in interview training we were clearly told that Google does not have a position for a non-coding architect. This is not to say that Google does not have positions for architects. http://research.google.com/pubs/jeff.html certainly wears the architect hat well, and is behind the design of large chunks of fundamental Google infrastructure. See http://static.googleusercontent.com/media/research.google.co... for an example of his showing that skillset off. But they have to code. Which Jeff does. A lot.

> And that the latency gets worse if you're making the mistake of using XML as your on the wire format...

No it doesn't. That's not what latency is.

Not always, granted, but the format really can matter.

Grabbing a random benchmark, look at http://www.maxondev.com/serialization-performance-comparison.... It is in C#, but every language is going to give similar results. An efficient on the wire format like protocol buffers is a bit faster and a bit smaller than a sane text format like JSON. But XML is several times slower and several times bigger. He didn't test pretty-printing the XML, but that makes it several times slower and bigger still than plain XML.

This adds up sooner than you'd think. For a start there is a noticeable timing difference between an RPC call that fits in one packet and one that has to be split across two.

If you've got an application that spends a sizable portion of its time in serialization/deserialization, it is obvious that the format chosen will affect maximum throughput. (Many distributed applications spend most of their CPU time doing those two things.) It is harder for the format to have a noticeable impact on latency, but it both can and I've seen it happen.

I downplay the architect title as much as possible and tell prospective companies they ran out of non-management engineer promotions.

Reply on news.ycombinator.com