How to Interview Engineers • Hacker News Board

Re: How to Interview Engineers

#301

Post by Jach » Tue, Jun 27, 2017, 1:38 PM UTC

macca321 wrote: post #283

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…

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 is gained by letting the candidate go off into the deep end for several minutes before they realize on their own, if they ever realize at all, that their initial approach was bad when it should be a simple question? If the purpose of a calendar question or fizzbuzz question (or my own initial coding question, "implement is_even") is to answer "can you code?" why does it matter if the solution isn't that great? If you have an answer to the question you can follow up with things like "can you code a better solution?" to distinguish passes, but interviewers should keep everything time boxed, there's other stuff to cover with such short time slots as 30-60 minutes. I like to test some sort of presence for knowledge about regexes and recognizing an application, so I borrowed Yegge's phone number regex question from his phone screen tips, and I'm happy enough if the person realizes that "there's some sort of pattern thing to do this" because that's a google away, happier if they can write a script that uses regexes correctly, happiest if they know or get close to the grep incantation, but if they start trying to write their own parser I'm going to stop them because that's going to take a lot longer than 10 minutes, especially if I say "oh yeah there's another number format we need to extract". But that person still might be a good hire, just not knowing about regexes at all. By keeping things time boxed I can make sure all the other areas I care about are covered and can judge if certain strengths can compensate for certain weaknesses.

Re: How to Interview Engineers

#302

Post by hhmc » Tue, Jun 27, 2017, 1:40 PM UTC

quadcore wrote: post #294

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…

One question Ive been asked I really like is: write a program that print the odd numbers between 0 to 100.

It's telling that I can't even read a problem as ostensibly simple as this without wondering if there's some deceptive special case I haven't considered.

Re: How to Interview Engineers

#303

Post by Bahamut » Tue, Jun 27, 2017, 1:48 PM UTC

watwut wrote: post #229

Bahamut wrote: post #210

Earlier quoted context omitted.

I've had it happen - just in my past job search the past few weeks, I had a total blankout in my last Google interview session in person on a dynamic programming question, and I'm pretty sure that ended up being the reason why I got rejected as I felt pretty good about all 4 of my prior sessions. I am about to start work as a senior engineer for Apple with 4 1/2 years of experience, after passing two back-to-back ons…

I know it happens, but I don't think it happens to majority of people. Bad days are caled that way because they happen once in a while, not constantly. You had good three interviews and one bad at Google. You passed well at apple. That really sounds like bad day. But then there are people for who practicaly any question beyond "lets talk in general about what you like and how passionate for technology you are" is unf…

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.

Re: How to Interview Engineers

#304

Post by FilterSweep » Tue, Jun 27, 2017, 1:51 PM UTC

Here's a concept I had a question about that I don't think gets discussed that often...

If a company were to offer a base salary at a mere third of the Google base salary for the same job, why should an applicant have to copy Google's depth of computer science abstraction in the coding interview?

Is the onus on the developer for even entertaining such a demanding question at a low pay, or does the current economy favor employers in such a way that developers have no other choice? Or rather, is the knowledge of available jobs asymmetric enough to where employers can pay pennies, piss, and peanuts for A-level employees?

Re: How to Interview Engineers

#305

Post by saw-lau » Tue, Jun 27, 2017, 1:52 PM UTC

vonmoltke wrote: post #296

saw-lau wrote: post #290

Earlier quoted context omitted.

The whole for loop thing - absolutely! We used to ask people to right a function in C that converts an array of doubles from degrees to radians. It was amazing how many people had no idea and who had sailed through CV/resume screening, telephone interview, and 'technical discussion' part of the interview with ease.

If those people really "sailed" through your phone interview and technical discussion there is something very wrong with your phone interview format and technical discussion methods.

That's a good point, and I don't really understand what we were doing wrong.

I guess the candidates could 'talk the talk' when we were asking them questions on their CV, or general high-level questions on, say, threading or design patterns; but when it came to the crunch they couldn't write code.

Maybe the candidates were just good at generating CRUD applications and binding data to forms, and have rarely needed to process data. Not denigrating that aspect of software developement at all - it's just not what we need in our department.

Re: How to Interview Engineers

#306

Post by JoeAltmaier » Tue, Jun 27, 2017, 1:55 PM UTC

FilterSweep wrote: post #304

Here's a concept I had a question about that I don't think gets discussed that often... If a company were to offer a base salary at a mere third of the Google base salary for the same job, why should an applicant have to copy Google's depth of computer science abstraction in the coding interview? Is the onus on the developer for even entertaining such a demanding question at a low pay, or does the current economy fav…

I don't see a connection between pay and the interview process. Should the company also make their chairs one-third the height? Have one third the whiteboard marker colors? Feed you one-third of a lunch?

Re: How to Interview Engineers

#307

Post by mpetrovich » Tue, Jun 27, 2017, 1:57 PM UTC

aldarn wrote: post #195

mpetrovich wrote: post #147

We've had success with take-home coding challenges. After 1-2 technical phone screens, we send applicants a coding challenge for which they have 48 hours to complete. The coding challenge is representative of some of the work we do (e.g. Given our API, create a D3 visualization of X) and should take applicants several hours to complete. In submissions we look at everything from overall program structure and approach…

Do you specifically hire D3 developers? This sounds like a pretty difficult "coding challenge" for a non-D3 guy, let alone someone who may not even primarily use javascript. Having used D3 sparingly before i've found it something that requires a fair amount of upfront domain knowledge to get much done beyond something extremely simple (unless of course you copy an existing example, which is what I always did). This s…

No, we're not specifically looking for experienced D3 devs. That particular challenge can be completed with the simplest D3 viz if desired (of which there are hundreds of examples online) and doesn't even require prior D3 experience (I didn't have any when I applied). We do look for a solid working knowledge of JS, however, and an ability to learn new tools quickly.

The 48 hour time limit is a relatively arbitrary timebox and isn't a hard limit; we value quality over speed.

Re: How to Interview Engineers

#308

Post by logfromblammo » Tue, Jun 27, 2017, 1:58 PM UTC

watwut wrote: post #52

fwefwwfe wrote: post #26

Earlier quoted context omitted.

Ok, now do it for someone with 5 and 10 years of experience.

That question is easier with experience, because you know more about how positions look like in practice and what you disliked in the past.

Here's my honest answer:

I don't know, because based on my experience, your company won't even exist as a separate entity five years from now, and if it doesn't lay most of us off before the acquisition, the purchasing company will just afterward. So I'll probably be sitting right where we are right now, answering the same question again. But maybe--just maybe--the company will last that long, and grow, and I'll be sitting in your seat, asking it. But since I am where I am, that obviously hasn't happened yet.

Re: How to Interview Engineers

#309

Post by Jach » Tue, Jun 27, 2017, 2:01 PM UTC

et-al wrote: post #149

weaksauce wrote: post #138

Earlier quoted context omitted.

I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?

> 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 your main goal, right? or why ask it?) you could turn your prior vagueness into an opportunity to see if they can formulate test cases and refactor their approach to account for different inputs, if needed, or if you see them accounting for them as they go you can ask e.g. "why are you taking the absolute value?" and see if they're thinking about the input order or if they're just doing it because that's what they saw somewhere.

Re: How to Interview Engineers

#310

Post by dsacco » Tue, Jun 27, 2017, 2:02 PM UTC

symlinkk wrote: post #180

gilbetron wrote: post #168

Earlier quoted context omitted.

A weeder question I've used: How many operations can a modern CPU perform per second: A) Thousands, B) Millions, C) Billions We'll accept C, and B with explanation. I'd say roughly 75% of the people I've asked (who have gotten through a phone interview) cannot answer it with any ability. People whine about the difficulty of interviews, but honestly, almost everyone we've ever hired have said the interview was pretty…

When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.

That's not the correct analogy, because the carpenter uses the screw driver as a tool, not as a platform. The screwdriver is analogous to code, not the CPU.

I would absolutely ask a carpenter how quickly he can complete a project, and I would hope he has a realistic first order approximation of how fast he can complete (process) screw driving tasks.

That said, I disagree with the question being discussed here, because I'd rather just ask him about his speed and performance; I wouldn't ask him how fast he can screw things in :) (that's a minute detail compared to the actual work).