Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Interview Engineers

blog.triplebyte.com

Post reply on HN
Print view View original

371–380 of 489 posts

Re: How to Interview Engineers

#371

Post by poikniok »

qb45 wrote: post #278
alexashka wrote: post #132

Earlier quoted context omitted.

Depending on what you're hiring for, it's really not all that depressing. If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly. Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically. If you want people to do real development, those are…

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)?

Re: How to Interview Engineers

#372

Post by pklausler »

dsacco wrote: post #299
pklausler wrote: post #73

The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No lo…

I used to disbelieve hiring managers regularly encountered candidates who actually couldn't code, or whatever other basic technical thing was reported on their resumes. Such a possibility - even the audacity of it on a conceptual level - simply seemed beyond the pale for me. I had interviewed before and not done well, and that I could absolutely understand. But I had no way of relating to the idea of someone entering…

Original comment poster here.

I have conducted literally hundreds of technical interviews. To me, too, it was a jaw-dropping realization that some candidates can arrive who literally have no idea how to program a computer. I don't know how they get through school (with high GPAs, even), held their last job, or impressed their phone screener. I don't even want to speculate. The sad fact is that trivial, two-minute, easy-peasy exercises can and will expose some candidates as being unable to work through them, even with the most friendly and patient coaching.

So I always ask at least one trivial question that can be solved in a minute or two with a couple of basic relations and a Boolean connective.

Re: How to Interview Engineers

#373

Post by Terr_ »

ubernostrum wrote: post #354
lopatin wrote: post #166

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.

Why not go all the way, then? Armies train people by having them run obstacle courses with guns being fired all around them. Do a "realistic" interview, then, to really test how someone does "under pressure". Have them sitting alone in the room, and a screaming angry manager runs in yelling obscenities at them about how the production system is down, it's costing the company millions of dollars, and if they want to h…

Relevant comedy skit: https://youtube.com/watch?v=iRtBvo9grLw

Re: How to Interview Engineers

#374

Post by notadoc »

cyrux004 wrote: post #197
notadoc wrote: post #157

My own 2 cents for interviewing, for engineers and most other vaguely technical positions but perhaps broadly applicable: - Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity - Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview - Don't ask time-wasting stupid questions about manhole covers, boiling bagels…

Can you expand on the boiling bagels on mars question ? Havent heard of that before

It's just a variation on the typical logic/creative thinking questions that a lot of people and companies obsess over.

"Well they're a great candidate otherwise but they totally failed the boiling water on alternate planet question, so let's keep searching" - believe it or not, that's a real mentality out there. I don't get it and never have.

Re: How to Interview Engineers

#375

Post by ubernostrum »

cl0wnshoes wrote: post #364
ubernostrum wrote: post #357

Earlier quoted context omitted.

You know the quote: if you encounter an asshole first thing in the morning, you encountered an asshole. If you encounter assholes constantly all day long, it's probable you're the one who's the asshole. If you have a 90% rate of "utter face palming failures", the problem isn't with the people you're interviewing, it's with the interviewer and/or the interviewing process.

That's what I keep questioning and why I've tried various methods. After screening resumes along with coworkers, at various companies I've worked at, we'll pre-screen or not, bring them in and ask them questions from their resume. Resume says 'I'm an expert in SQL'. Great, lets start some every day foundational questions. What is the difference between an inner join and an outer join. Why might we use a varchar inste…

So let me ask you an "easy" question: for your interview questions, are you consistent in what you ask, and do you have a consistent approach to evaluating a candidate's response?

I ask this because some of your "foundational" questions are not as simple as you might think (I could talk for literally hours about XSS and the only conclusion I could give you would be "there's no sure-fire way to prevent it", for example), and others border on pop-quiz material, which is not really a great way to evaluate someone.

Another question that's important to ask: you say you're working with recruiting companies. Have you tried not doing that? Recruiting companies don't exist to find you qualified people, they exist to spam you with résumés. Recruiting companies have been known to flat-out alter résumés to make them better match the set of keywords you said you wanted. And my own experience is that recruiting companies are the source of a huge percentage of headaches in hiring. Cutting out the middlemen can and likely will drastically increase your success rate.

Re: How to Interview Engineers

#376

Post by Terr_ »

Jach wrote: post #309
et-al wrote: post #149

Earlier quoted context omitted.

> not fully thinking it through What I like about pklausler's example is that it allows for people to find edge cases without too much technical knowledge. If I have a candidate who doesn't ask about the inputs (e.g. "are the appointment sorted?"), I'd be wary. Engineers are often given vague specifications they need to clarify or account for.

If you want to test for the ability to gather requirements and clarifications from vague requests, then test for it directly, don't bake it in as a hidden test you expect people to account for when the overt problem is just implementing a comparatively crystal clear toy question even if you say things like "number" instead of "positive integer". Assuming they can implement anything that seems to work at all (which is…

Yeah, I think the important thing is that the candidate should not have to "read the interviewer's mind" when it comes to what style of question is being asked.

Unfortunately, this can also occur because the interviewer isn't clear on their own goals in the first place. They asked the question before really knowing what data points they want to come away with.

Re: How to Interview Engineers

#377

Post by Terr_ »

Jach wrote: post #301
macca321 wrote: post #283

Earlier quoted context omitted.

The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right. Half the time I pick a good solution and half the time I've rushed in and picked the wrong one. If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The…

Having had the chance to do some interviewing over the last few years I think the most important thing on my side is to know what I'm trying to test for with any particular line of questioning. I don't always see that level of self-awareness in fellow interviewers. (The worst is the sort who say "if they don't do X when I'm asking for Y, I'm going to score them down." Do they really care about Y then?) What exactly i…

Yeah, instead it's like: "Here's an interesting question that I like because I feel I already understand it well. Let's see what they do with it, and then I'll go with whatever gut feeling I end up with. This is easy, I'm a good interviewer."

Re: How to Interview Engineers

#378

Post by restalis »

rmah wrote: post #326
macca321 wrote: post #283

Earlier quoted context omitted.

The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right. Half the time I pick a good solution and half the time I've rushed in and picked the wrong one. If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The…

Here's a tip: most live programming interview questions should be answerable within a few minutes. Any approach that you think will take a half hour is the wrong approach.

"Any approach that you think will take a half hour is the wrong approach."

Unless the interviewers haven't given much thought themselves. "Hey Joe, we have to interview a guy in 20 min. and I can't remember where are those damn interview questions. Gather up a few for me, will ya?"

Re: How to Interview Engineers

#379

Post by Jemaclus »

danthemanvsqz wrote: post #78

Interesting read from the POV of the staffing agency and hiring company. But why should I jump through those hoops when I don't even know if I'm interested in the job? I really think the hiring companies need to sell me on them before they ask me to spend an hour of my time.

I agree. I had an interview yesterday where they passed, and the reasoning was "You didn't seem interested in the job." And I sort of think that's hilarious, because nobody tried to sell me on the job. Nobody told me exactly what the job would entail. I never met the hiring manager, even though I was on-site for 5 hours. And clearly they weren't interested in me... It just seems weird that I have to be jizzing my pants to work for them, but they don't even have to try to sell me on the role.

And this goes doubly true for any company that reaches out to me first. Like, if I apply to your company, then yeah, you have an expectation of me being interested in the company. But if you reach out to me, then maybe you're the one who needs to sell yourself to me.

I don't really get that attitude by employers. Whenever I'm interviewing candidates, I really try to sell them on the role. I try to tell them what's awesome about it, why they should want to work here over literally anywhere else in the world, and why you WANT to sit next to us for the next six months and work with me and my team on projects. Part of my job as an interviewer is to not only gauge your ability and interest, but to convince you that we're the best place for you to be.

Or... do interviewers really think I selected their company is the only company I even considered talking to? We're engineers. We have options. You (the company) have to meet me at least halfway.

Incidentally, I've often wanted to ask my interviewers to solve a tech challenge. I don't want to join a company where the team is incompetent and I'm constantly cleaning up after them. Oddly, that's never a consideration that companies allow candidates... ;)

Re: How to Interview Engineers

#380

Post by pmiller2 »

rmah wrote: post #317
arethuza wrote: post #240

Earlier quoted context omitted.

"time matters and you have to think on your feet" I've been in many stressful situations at work - none of them involved finding algorithmic solutions.

I once had to diagnose and fix a bug in a financial system that went belly up under extremely heavy load -- causing the company lose tens millions of $'s per hour (literally). Turned out to be a timing problem caused by satellite comms latency. The solution required us to modify how a couple different algorithmic worked. That situation was highly time sensitive and over-the-top stressful (for me anyway).

I'm sure you would acknowledge that's a very exceptional situation, right? That's the point of this whole subthread: that this kind of stress is exceptional in a work situation.
Post reply on HN