Hacker News Reader

Comment by mrits | Hacker News Reader

"But why?"

Because most people can't. And they want to make sure you can.

Exactly this.

I interviewed lots of people for a small company and multiple times I became convinced the person across a table would be a good hire (based on past work experience and soft talk) only to see them bleed to death on the first technical question. Demonstration of technical skill is absolutely crucial for an interview.

Personally I don't care about pseudo code vs real or syntax errors, but the price of a bad hire is much higher than a few more questions or round for a candidate. Also FAANG will always have enough senior CV on their desk to miss a few good hire...

One of my biggest interviewing mistakes was voting "hire" on a guy despite his seeming difficulty with coding during the interview because he was such a great talker and had great sounding experience. He came on board, couldn't deliver on anything, and sapped the team's morale. There are plenty of people out there who have bullshitted their way through a career.

We always allow the candidate to use any reasonable language. We're not testing if someone knows Java/Python/Lisp (I wish). We're testing if they know any language. I can confirm seeing people with resumes who nevertheless could not write any code even in the language they professed to be "expert" in.

Same. I learned through experience to ask for a candidate to write a couple of lines of code.

Usually it's just some simple question that requires a single loop. We explicitly tell them they can use any language including one they want to make up as long as they are ok explaining how it works. When possible, I try to relate it to the conversation we've had up to that point.

I've had someone start off by writing "four" on the board when prompted to write a "for" loop and get stuck. I'm still not sure if he was truly inexperienced or just trolling. The resume looked solid to me and he spoke well about his experience. I had almost decided to just skip the coding question as a result.

Yep. I just want to actually see you plop some if-else and for/while loops on the board in any Googleable language. I'm the one with the laptop/phone and I can learn that language on the spot if I need to.

It's basically "find the first string in an array of string that has the letter 'b'" difficulty of questions. Anyone who actually codes can whip something up in a minute and we can move on. But it's always surprising how many people spend half an hour on that and still don't get anything workable.

If you can describe an acceptable algorithm with enough detail in words, you can code it.

If some guy had a good employment history, maybe a GitHub with some examples of their skills and described an algorithm to me... Why would I doubt their ability to write it in code?

I can. You can. But apparently, not everyone can.

> If you can describe an acceptable algorithm with enough detail in words, you can code it.

I wouldn't take that for granted. It's easy to gloss over details and edge cases when talking through an algorithm and it's not apparent until you actually write the code. Similar things happen when discussing things in meetings vs writing a formal document. I've interviewed plenty of people that were able to quickly come up with algorithms to solve a problem but really struggled to translate them into code.

Most people with 20 years of experience can't write basic code? Come on.

I have been a tech interviewer for a decade, and this is spot on. The entire reason FizzBuzz-style questions are popular in screening interviews is that most people fail them.

I imagine this problem is much worse at large, highly paid, highly desirable companies. My experience in hiring at smaller companies has not shown this. I've never had a candidate with 10+ years of experience who couldn't code.

We are a smaller org and hire occasionally for roles that are most suitable for early career applicants.

We always get several applicants with 10-20 years of experience who have programming projects on their resume or described in their cover letters.

But in our (very minimal) technical evaluations, lots of these candidates can't do anything at all. No coding, psueudo-code, nothing.

Usually, it turns out they have been really doing light IT work for years - using reporting tools, maintaining little scripts, even just some Excel jockeying. But they still think of themselves as software engineers.

My gut feeling is that lots of these candidates could learn (relearn?) to code, but have spent years not coding.

I don't have the numbers in front of me, but I would guess that the majority of these types of candidates (10-20 years of experience) that apply to our roles can't code in an interview situation and haven't been programming recently.

It is definitely not all of the experienced candidates who fit that profile. The few very experienced candidates we get who can code are often excellent but are looking for salaries well beyond our range.

You must not have tried to hire a software engineer before. In a hiring cycle I encounter multiple "Senior Engineers" who can't write basic code. Fizzbuzz. Can't do it. Engineers should absolutely expect to write real code in an interview. It's preposterous to think that someone can claim to have 20 years experience writing code and then be offended to spend 20 minutes doing it in an interview.

How do they react when they fail Fizzbuzz?

I make a judgement call - either I end the interview immediately or skip most of the rest of the interview, let them think they made it all the way through the interview and say that we will get back to them with a decision later. When I end it immediately they usually take it badly but these are times that I just can’t justify wasting any more time on them. The bad reactions run the normal gamut of bad human reactions: angry, sad, indifferent, humor, etc.

That's interesting:

> [I] let them think they made it all the way through the interview

Maybe then, although they get rejected later, they still won't be particularly upset at your company -- since the in person interaction was friendly and positive (i suppose), and you can take some time and write a friendly rejection email or phone call too (i suppose you have a template)

We hired one who couldn't. He turned out to be more of a mentor/big vision/best practices guy. Which is probably OK to have one or two of those if you're a large enough org.

But we had 3 devs. I think he gave some great advice (and looking back - still think so 12 years later), but it just wasn't what we needed at the time.

The funny thing is, when we let him go (he knew it was coming - he wasn't blind to the problems) he got hired at a company we worked regularly with. Things worked out much better for him there.

What was some of the advice, if you happen to remember?

This is the answer right here.

And it proves what exactly? Except that they have lost out on a good hire only because that hire is not familiar with that particular programming language that the interview is.

But that's not how it works. You are almost always free to use why language you want. There are exceptions to this but in those cases it would be clearly indicated in the job description.

We have approved languages for projects at work (Java, Scala, Go, and Python in special cases), but I let candidates use any language I can read, and it’s never been a problem.

These types of interviews are very similar to the Confucian Imperial Examination tests (Keju) of China [0]. The Keju's main purpose was to exclude peasants while giving the imperial bureaucracy the image of a meritocracy and therefore legitimacy. They also helped enforce a common culture, script, and style of writing for the large empire. To be clear, the Keju changed a lot as China's history evolved and it changed with China and is not a unified 'thing'.

The expense and time for study excluded many people and I have heard that whole villages would pool resources for just one son to buy the exam materials and take the time to study for the exam. Richer families didn't have need to sacrifice as such, of course. Typical success ratios were ~1:50 exam sitters. The Taiping rebellion was a direct result (among many) by such a man that failed his exams a few times (later declaring himself the brother of Jesus, but that's whole other story).

Though exam subjects changed over time, it typically included recitations of Confucian poetry, calligraphy, instrumental music, and other such gentlemanly subjects. You know, things you really need your bureaucrats to know to run an empire well.

Similarly with FAANGs (and previously with GMC/Ford/Chrysler, or in academia), the interview/exam is geared not towards the actual specifics of the job, but rather in the 'pruning' of the people and the appearance of legitimacy. They are selecting for people that will go through the hoops and the nonsense without questioning it and will make good bureaucrats (loyal, command-able, lacking vigor). Boat-rockers are selected out before they even start the irrelevant studying process.

[0]https://en.wikipedia.org/wiki/Imperial_examination

lot of paper tigers out there

Then pick up a phone and call their references. A "paper tiger" with 10+ years experience (since we are talking a senior position) likely could not have just "winged it through" the entire time.

Subjecting such person to a CS exam totally unrelated to what they will be doing (such as project management and leading a team of developers) is a complete waste of time for both sides and you still don't test whether that person has the skill they will actually need for the job.

But yay, you have found that they are great at inverting a tree or designing a complex hashing scheme at the whiteboard under pressure. Exactly what your company needs. Not.

Reply on news.ycombinator.com