Live data from Hacker News

How to Interview Engineers

blog.triplebyte.com

421–430 of 489 posts

Re: How to Interview Engineers

#421

Earlier quoted context omitted.

Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet. That's why I think rejecting a programmer for losing their core competencies like problem solving, i.e. freezing, under a medium amount of pressure is valid.

>Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet Not once in my career had I had to fix a problem in an hour, let alone 10 minutes. I have had senior people get mad at me when I couldn't give an answer during a meeting - that's the closest to an interview type scenario where you need the answer now. But even then, I did not stress that I'd los…

Do you work on services that are expected to be working 24/7? It's not exactly uncommon for a production service to have problems and need to be fixed ASAP.

Re: How to Interview Engineers

#422
post #323

Earlier quoted context omitted.

I disagree - different people could have dufferent triggers for a fight or flight response. For one of my best friends, anxiety is her trigger. It is super important to try to ease a candidate into being comfortable to get the important information you need as an interviewer, as interviews are inherently stressful for candidates, and you almost never want to be testing a candidate's stress coping abilities.

I agree, but here the topic is simple question being considered unfair, because someone might be too stressed. I would argue that asking questions is not unfair level of stressing people.

It's not simply a matter of "asking questions". It's about getting asked (often gratuitously difficult)† in an intrinsically awkward and confrontational situation -- quite often by someone who not only might not have adequate social skills for the task; there's a good change they may not really know why they're asking that question of you in the first place.

"I dunno - they put me through this stuff, or some variant, on my way in. So now I guess it's my turn to dish it out on the people trying to climb in after me" seems to be about the order of reasoning in place behind these "methods".

† As in, was an open problem in the literature and/or folklore for years before some (now) highly respected came up with the first reasonably adequate (but like as not, overcomplicated and/out outright flawed, at the outset) solution. We know the "usual suspects" that get asked -- I don't need to list them here. But ff you genuinely think that any candidate you can (reasonably) expect to find in response to your muddled job postings will genuinely be able to solve these problems for you at the whiteboard for you -- from the void, as it were -- as opposed to regurgitate carefully practiced solutions they found from cobbling together lists of "problems Google and FB like to ask" -- you're seriously kidding yourself.

Re: How to Interview Engineers

#423
post #384

I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employment tasks. It seems to me like an enormous amount of time wasted for both interviewers and interviewees. When considering someone for a development/engineering role there are a few basic questions to figure out: 1. Does this person have competence within our t…

You say we need to figure a few basic things out, how do we do if a person has basic confidence if not by asking them questions. Please keep in mind that resumes nor any other data from the candidate can be trusted, because a huge amount of candidates lie or are mistaken about their own skill. I once interviewed a candidate who claimed to have 10 years of SQL experience but couldn't write a query on the order of "sel…

maybe instead of doing this hoopadoop all the time, its time to accept that fulltime employment is a concept that made sense when most workers were doing assembly line things.

hire specialized contractors to do the things you need done.

ive never been asked stupid fizzbuzz but have so far not been able to sufficiently fail at a job. weird.

Re: How to Interview Engineers

#424

Earlier quoted context omitted.

The interview question I was referring to is the appointment overlapping one. It's a middle school math question and it's a lot easier than failing over a database without data loss.

I've been doing this for 20 years and I'm not even sure where I'd start on your middle school math question. I hate working with calendars and dates and I don't think I know anyone who enjoys it and can write totally bug free code that takes care of all edge cases. I'm sure good at fighting database fires though. This probably is at the heart of the answer to the question "how could this programmer with such a long r…

Don't over complicate it. Given two number ranges, of UTC timestamps, determine if they overlap. I think you know where to start with that.

Re: How to Interview Engineers

#425

Earlier quoted context omitted.

Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview? This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by…

>> "Thinking aloud" ... is a specific metacognitive skill Is there evidence for this claim? I'm inclined to believe it but that's experiential. It's also something I've never had to work to acquire, but that could be a cultural thing (my family and friends talk a lot about thinking) or a personal history thing (I have a minor learning disability, and it has forced me to develop strong, conscious meta-cognition). It's…

the idea to "think aloud" is downright silly.

people who "talk to themselves" are labelled idiots. mental dialogue is supposed to be mental.

call it social conditioning if you will. spelling out your thoughts for someone else to hear them just so they can take note of them for evaluation is the polar opposite of normal human interaction.

Re: How to Interview Engineers

#426
post #264

An alternative to an "interview" would be something more like an exam: have candidates try to solve a (relatively simple) problem in limited time, with or without external resources. Candidates would be watched, would know they're being watched, but would not see themselves being watched, which would probably take a lot of stress out. You could even test many candidates at the same time this way. And you could setup…

My current employer does this.

You're sat in the conference room, given a machine that has a screen monitor program running, and a set of tasks to perform on the code. You are told where to find the code in the introduction on the sheet of instructions. You are allowed to use any resource via the computer (so nothing you've brought in like a phone or laptop is allowed; basically, all work has to be "shown"). Then...go.

Outside the room, the dev team watches the process. We want to see how you go about each problem, what resources you use, etc.

It's always surprising the number of people who go for an hour or more and do nothing. Just sit there (or seemingly sit there - there's no keyboard or mouse activity).

When I interviewed, they actually gave me an online test; the job was supposed to be for javascript, but the online was in PHP (which my prior position used, and I had been using for years). Passed that, and came in for the on-site part. I thought it was odd that they first tested me for PHP. Did a bit of face-to-face interview, then they wanted me to do the watched javascript portion (single page app).

I first sat and read the problems, formulated some possibilities in my head, then jumped in. 30 minutes later I was done, and popped open a new file to write something to that effect (figuring if they were watching, they'd come back in). I sat for several more minutes, then they came back.

"How's it going?"

"Alright...umm, hey, I'm done."

"No way! Are you serious? Are you sure?"

Odd...

"Yes."

Apparently they had never had anyone finish the test that quickly, and get it completely right - especially someone who also had PHP skills, and had already demo'd them in the first test, which was also done correctly. I found this rather odd, as neither test was that particularly difficult.

Apparently, though, it's not uncommon in our industry. I'm not sure what to make of that...

Re: How to Interview Engineers

#427
post #278

Earlier quoted context omitted.

Determining if two intervals overlap is not a trivia question but a trivial question for a programmer and hiring people who can't do better than O(n²) probably is good only for really boring maintenance projects where the workload lags far behind Moore's law. I'm not necessarily saying that such things don't exist, but not my cup of tea.

What do you think n here is when you say O(n^2)?

The number of seconds in these intervals, see the top level post.

Re: How to Interview Engineers

#428

Earlier quoted context omitted.

>Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet Not once in my career had I had to fix a problem in an hour, let alone 10 minutes. I have had senior people get mad at me when I couldn't give an answer during a meeting - that's the closest to an interview type scenario where you need the answer now. But even then, I did not stress that I'd los…

Do you work on services that are expected to be working 24/7? It's not exactly uncommon for a production service to have problems and need to be fixed ASAP.

Do most programming jobs expect that? I think not.

It's like interviewing a doctor who will be someone's primary care physician. Give him/her a set of symptoms, and fail him if he doesn't diagnose it inside of 10 minutes. And then justify it with the expectations in surgery or ER.

Re: How to Interview Engineers

#429
post #384

Earlier quoted context omitted.

You say we need to figure a few basic things out, how do we do if a person has basic confidence if not by asking them questions. Please keep in mind that resumes nor any other data from the candidate can be trusted, because a huge amount of candidates lie or are mistaken about their own skill. I once interviewed a candidate who claimed to have 10 years of SQL experience but couldn't write a query on the order of "sel…

> Please keep in mind that resumes nor any other data from the candidate can be trusted That's not a problem that is unique to software, yet nobody asks directors to prove their budget forecasting skills during an interview, or has their tech writers go through the process of building automated indexes or varied pagination. If you suspect someone can't write fizzbuzz, send them packing. Don't waste their time or your…

Tech writers are certainly asked to create technical documents to demonstrate their skills. Chefs might be a good model too; it absolutely the case that before hiring a chef they have to plan a menu and cook.

We aren't business people: we do actual productive things.

Re: How to Interview Engineers

#430

I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employment tasks. It seems to me like an enormous amount of time wasted for both interviewers and interviewees. When considering someone for a development/engineering role there are a few basic questions to figure out: 1. Does this person have competence within our t…

The question of relevance reminds me of an anecdote. (Before that though; I tend to agree with your points.) A distant acquaintance interviewed for a secretary position. It didn't go well, because she was asked a general knowledge question (something along the lines of: "name some of the planets in the solar system"). She was furious with how irrelevant and unfair this was. It makes me wonder though, would I have hir…

Why? Everyone has some things that are "common knowledge" that they don't know. Trivia isn't called "trivia" because it matters.
Post reply on HN