Hacker News Reader

Comment by nomel | Hacker News Reader

I once gave an interview to a PhD with 15 years of experience. He couldn't write a for loop at the end of the interview, but had great knowledge otherwise. We needed someone who could actually code. I had my boss join late, because it was so unbelievable. I was the only "no" for him. I was the only person that tried to make him type something.

I keep my question very light and completely work related. They're allowed to ask as many questions as they want. They don't even have to remember any algorithms (I have a review slide for the relevant ones they might pick). They just have to be able to think and be "seeking" in their mindset, asking questions to fully understand the context, then convert that to code. That's it.

View on HN

I'm all for hiring people who can figure things out and know how to figure things out. I'm not blind to the fact people will google and copy-paste-modify stackoverflow example code and don't have strong issue against hiring someone who would work that way.

So my simple whiteboard interview question started as "Print the numbers from 1 to 10" but then I had a few candidates that would just write the numbers out on the board.

Since it happened more than once I figured it was a me problem so I became more specific with "Write code to print the numbers from 1 to 10". But then one one candidate would out dumb me and write 10 lines of print statements.

So I thought it would be clever to force a loop of with a really large number: "Write code to print the numbers from 1 to 1 million." but I had one candidate who started to write out a bunch print statements and I had to stop him.

The latest iteration is "Using a for loop to print the numbers from 1 to 1 million putting one number per line." I usually get blank stares. It's either they think it's some sort of trick question or they don't know how to do it. One time I saw an implementation using an if statement to skip 0 and an extra print for the last 1000000.

The solution to that was to tell HR to let me phone interview them for 10 minutes before brining them onsite.

For the candidates that write 10 print statements, why not simply reject them? They're either ignorant or smartasses... Now if they do the right thing when told to write a loop, you just let them in the door, lol!

Does HR really think it benefits the company to hire folks who need to be told when to use a for loop? That sounds like a painful organization to work for!

What's more likely?

(1) The candidate was a criminal mastermind who somehow managed to fool everyone for 15 years.

(2) The candidate was just super nervous during the interview and experienced a kind of test anxiety.

I've personally been (2) several times.

> (1) The candidate was a criminal mastermind who somehow managed to fool everyone for 15 years.

Not "criminal mastermind", but do enough hiring and you will run into a lot of people who are convincing conversationalists but clearly haven't written much code in a very long time.

In a couple cases I gave these people benefit of the doubt and gave them a backup take-home problem (super trivial, 5 minutes for experienced engineers). They always came back with a solution, but when you asked them to walk you through it they couldn't really tell you what they wrote.

I understand that test anxiety is real, but having to discuss your code with others on the spot is also part of the job. If someone can't discuss even the most basic fundamentals of programming in a conversation, you can't dismiss it all as anxiety every time.

Well, interviews are mostly noise, whether they're conversations or coding. I wouldn't put much faith in them either way. Interviews are just a tiny snapshot and unlike real work in many important ways.

IMO the key is really to investigate the candidates as much as possible before they even walk in the door. Nowadays, many candidates have a large public footprint.

(I also think employers interview way too many people. That's mostly a waste of time, better spent focusing on a relatively small number of the top candidates.)

Asking someone to code, even simple problems, should be the absolute minimum standard. Why should it be unexpected to not code when applying to a software development job?

I'm sure we all have stories about falling on our faces during a technical evaluation, it sucks but I wouldn't personally fault the interviewers passing on them.

> Why should it be unexpected to not code when applying to a software development job?

Software developer hiring is very different from most other hiring, but it seems that many software developers don't even realize how eccentric they are, because they've never been outside their own industry.

I suppose but until this industry adopts something like an engineering license like PE I don't think it's out of the question to ask people to code. It's the highest signal you can get from a candidate. It doesn't matter what their credentials are or what their experience is, if they're able to code you have some sort of baseline to go off of.

Please note I'm not saying ask leetcode questions, I can't even solve LC. I've failed many interviews at Facebook and Amazon because of LC; but other jobs I've accepted all asked some basic coding questions.

Professional licenses are local government requirements.

If you want the government to start regulating all programming, then the shit's really going to hit the fan. ;-)

I mean regulation isn't a bad thing, so I don't understand your comment.

If anything big tech needs to not only be regulated more, they should be broken up.

> If anything big tech needs to not only be regulated more, they should be broken up.

You're thinking of the wrong thing. We're not talking about breaking up big tech, we're talking about every little hair stylist needing a cosmetology license.

We're actually talking about software but okay.

Yes, we are. If you don't see the analogy, I'm not sure that I can help you.

Professional licenses and breaking up monopoly are totally unrelated regulations.

I have seen #1 many times (in non-interview settings).

- It's definitely possible to hold a tech job for 12-18 months without writing any working code and changing jobs that often isn't that big of a red flag. Also, people lie about their experience.

- The pool of people applying for a job has a very low intersection with the pool of people currently working at a job. In that intersection there is a very high subset of people who believe they may lose their job soon. Therefore the people applying to a job is largely people who either are not currently working, or will shortly be out of work. See also[1]

1: http://weblog.raganwald.com/2007/03/thank-you-for-writing-su...

This totally happens, but keeping the questions simple and the atmosphere friendly goes a long way to mitigating it. One thing my previous company did was to have a short take-home replace the live coding, then the candidates simply answered questions about it. A surprisingly large number of candidates plagiarised their submission from various blog posts online. Others were unable to answer any substantial questions about their work. All these people were senior and employed in big firms. These kinds of candidates outnumbered the obviously anxious candidates by maybe 10 to 1.

> All these people were senior and employed in big firms.

Which big firms?

I find it curious that a BigCo on one's résumé brings cachet, because BigCos are able to hide incompetence, even at the executive level, to a vastly greater extent than a small company. If you find someone who for example has around a decade of experience at a company of around ten people, it's going to be almost impossible for that person to have done nothing of value.

> These kinds of candidates outnumbered the obviously anxious candidates by maybe 10 to 1.

Anxiousness is not necessarily obvious. My stomach could be churning and my mind racing, but a stranger probably wouldn't be able to tell.

Indeed, but then I can’t measure the true positive rate. :) I suppose we’re really talking about having an anxiety disorder that impedes the ability to deliver vs feeling anxious on the day. The former should manifest noticeably somehow, by definition.

As for which companies? Basically any large enterprise except absolute top-tier tech. I wouldn’t necessarily call such people incomponent though - I’m sure they were perfectly good button-pushers within the corporate machine. Low-skill high-specificity.

> I suppose we’re really talking about having an anxiety disorder that impedes the ability to deliver vs feeling anxious on the day. The former should manifest noticeably somehow, by definition.

I'm not really sure what you mean. First, anxiety is on a continuum, so I wouldn't propose a dichotomy here. Second, lots of people have situational anxiety, which I wouldn't call a "disorder". For example, a great fear of public speaking is pretty common.

Of course poor performance at some specific task, e.g., an interview or a speech, is manifestly noticeable, but the cause of that poor performance isn't necessarily manifestly noticeable. In other words, you can't necessarily tell whether it was caused by a lack of skill or competence or just temporary anxiety. Or maybe lack of sleep the night before.

I’ve personally seen (1) and that hire wreaked havoc in the org with his silver tongue, without being able to deliver any real value. (Not a criminal mastermind obviously. But damaging enough, was unable to implement our version of fizzbuzz and was brought on board as an “architect” anyways.)

I understand not being able to deliver any real value, but I don't understand how a new hire can wreak havoc in an org, unless the org itself is already quite dysfunctional.

A person is assigned work, and they need to be able to do it, without being a deadweight on their peers. At the very best, you're just dumping a SWE salary's worth of dollars into a ghost. I've never worked anywhere that didn't have plenty of work, and so that's an eng we could have had, but effectively did not.

IME these people talk a lot of talk, but they don't deliver contributions. Like the simplest script could take a quarter? I don't endorse code metrics, but, e.g., 1 PR / quarter (of really simple stuff), unless that PR is blowing my socks off or had some complex amount of research or some reason behind it, is underperforming.

You expect negative returns for a new employee like the first 6–12 months. This is well after that, where it's clear that they're not putting in the effort to understand the systems around them, or they lack fundamental skills (like experience writing actual code), or more often, both.

> A person is assigned work, and they need to be able to do it, without being a deadweight on their peers.

I wouldn't call this "wreaking havoc", but I think only wisemang can explain what exactly they meant by that.

> You expect negative returns for a new employee like the first 6–12 months.

Wow, I wouldn't expect that. In my opinion, an experienced programmer should be able to start contributing something within weeks. If they can't, then "can" them.

Think about open source projects: nobody takes 6-12 months to "get up to speed" before contributing to a project. That would be ridiculous.

> Wow, I wouldn't expect that. In my opinion, an experienced programmer should be able to start contributing something within weeks. If they can't, then "can" them.

> Think about open source projects: nobody takes 6-12 months to "get up to speed" before contributing to a project. That would be ridiculous.

I'm trying to be generous, and to say that the people under discussion in the comment are past the 6-12 mo timeframe to avoid needing to fend off "but maybe they just need more time/experience/etc."

But I also do think 6 mo is about the "productive" point. This doesn't contradict "start contributing something within weeks" — you should contribute something within your first week, ideally, if the company has their stuff together. But it's 6 mo, IMO, until one has got a good grasp on the architecture, and more importantly, the theory of the system at hand, and can make their own salient decisions about how to grow it that are going to fit well into the existing theory of it.

But again, I'm just putting it out that that we're well past the "initial onboarding" phase of an employee, and tried to pad the amount to avoid commentary.

I agree negative return for that long is not necessarily expected. Definitely fair for some period of onboarding though.

The havoc I was referring to was more due to the person’s political skills and ability to shift the blame for his own shortcomings to people on his team, while those on the team were unaware of how he’d throw them under the bus while managing up. The failure at “fizzbuzz” was a red flag that got ignored by management (yes there was some existing dysfunction in the org).

And so — figuratively speaking — someone who couldn’t even build a doghouse ended up being tasked with architecting a shopping mall, then attempted to deliver a skyscraper (and failed miserably at it).

Yes, I've also seen 2 several times. I've also requested second rounds for each time I noticed it. I'd rather the interview not be about the interview. My judgement could be wrong, but being someone who ALSO has a problem with 2, and just being nervous in general, I feel my perception of this is at least reasonable.

This person had a very very niche job, at two orgs, with no work/growth outside of that very specific thing. This lack of doing anything else was a flag one of the high level managers saw.

Obviously I don't know you or this guy so I'm not trying to dispute your story, but I'd like to point out people get nervous with these things, or misunderstand the question.

I got a friend of mine an interview at a BigCo I used to work at. Since he was already a friend, I wasn't allowed to be part of the interview as that might be a conflict of interest, but I did see the review that the interviewer wrote, which said that he didn't know what a for loop was.

Now I had done several projects with this friend, he was someone that I knew was quite competent at coding (and I had seen him write multiple for loops in the process). After he was already declined I did kind of ask about it and he explained that he was asking a clarifying question about how many times something needed to be repeated, they didn't directly answer, so he assumed that that meant "potentially forever" so he did a while loop with a break condition. The interviewer had taken this to mean that he didn't know how to do a for loop.

Now it's possible that my friend was lying to me, but again I had previously seen him write lots of code and I knew he was smart and able to do that, so I'm inclined to believe him.

Yep, I’ve had exactly the same experience. Super-simple questions, qualified candidates from large companies - almost total disaster on “hello world”.

That's a common trope I hear a lot, and of course sample size of one so take it with a grain of salt, but I've done tons of interviews with varying levels of engineers, and I've never seen any of the senior people fail FizzBuzz or anything like that (I never thought about testing Hello World), and most even do fine on the simpler data structures problems.

Maybe I've just gotten lucky, but I really haven't observed it. I've interviewed plenty of bad engineers, even senior level, but they usually knew the basics and had trouble with the lateral thinking required to solve the problem.

I suspect you're late in the screening process, or there's some effective filter before you. I've seen hire rates of 1 in 100, in big orgs!

If you still need to use for loops on a regular basis then there's something wrong with your chosen programming language. The rest of us have moved on to languages with higher level constructs that eliminate the need for explicit iteration.

I'm being a bit facetious of course. For loops (or the equivalent) are still needed in low-level code. But lately I'm very reluctant to use them as there's usually a better design if you step back and think about the problem a little.

A for loop with more than four lines of internal logic probably does need to be refactored. A for loop with less lines can usually be turned into a list comprehension or invocation of the map function. But a four loop with just a few lines is often clean and easy enough to understand, and will pass my review.

I'm assuming we're working in Python here, which are already much more elegant and pythonic than C/C++ style loops:

for i in my_iterable: ...

Reply on news.ycombinator.com