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

311–320 of 489 posts

Re: How to Interview Engineers

#311

Post by FilterSweep »

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…

> but I don't think it happens to majority of people

Do you know "majority of people" or have interviewed them?

Have you yourself faced an interview question at an abstraction level far below your area in this field?

Re: How to Interview Engineers

#312

Post by detaro »

pogaxvr wrote: post #289
0xbear wrote: post #247

Earlier quoted context omitted.

But that's not what's being asked by OP. Their question is rather simple, and software engineer should be able to answer it on autopilot, without even engaging her brain. As a hiring manager I would end the interview right there and then after the failure to answer something like this.

As an interviewee, I would roll my eyes at the ignorance of the interviewer. This is the sort of question that reveals the ignorance of the person asking it. The correct answer is "yes". What is 'modern'? There are very modern embedded CPUs that operate in the low MHz range. How much power is being provided? A 'modern' CPU can be underclocked to ridiculous levels for power savings. What's an operation? Are we talking…

And low Mhz range is in the millions, which they said they would accept as an answer with that explanation.

Re: How to Interview Engineers

#313

Post by FilterSweep »

baddox wrote: post #159
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.

I highly doubt I would ask if the inputs are sorted. I wouldn't expect them to be (why would they be, after all?), and I'd probably just give a solution that works regardless.

I think you just received some good interview advice, unintentionally.

Re: How to Interview Engineers

#314

Post by bogomipz »

ryandrake wrote: post #217
bogomipz wrote: post #204

Earlier quoted context omitted.

Does every engineer unquestionably want to work for any and all 4 of those companies? Aren't these very different companies? Is there any significant commonality here other than Tripplebyte has some connection at all of these?

Pick N other companies, then. As long as TripleByte has this kind of relationship with at least 2 of them, it's a time saver. I could easily see myself interviewing for 20 companies in a single job search. Needing only one "pre-screen" for all of them would be nothing short of miraculous.

Let's say you avoided interviewing with 4 future team mates from company Company A by using Tripplebyte.

And come to find out most of those 4 people you didn't have a chance to interact with during the interview process are completely toxic and unprofessional. You only find this out after you have accepted the job.

If you find yourself looking for a new job again in month then Tripplebyte hasn't really saved you any time have they? I am not sure where this idea comes form that just because the company is "Apple, Facebook, Dropbox and Stripe" does not automatically mean that everyone on every team is a great personally or one you would want to work with.

When I interview with a company and I don't think I am alone in this I am also interviewing the company. I am thinking "are these people I could work with?" The novelty of working on Big S.V. Company eventually wears off and if it's a bad fit for you on personality or culture then you are either going to be unhappy, looking for a new job or both. I and I imagine many others are OK with a slower process if it means being able to make a better informed decision.

Re: How to Interview Engineers

#315

Post by anshou- »

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…

Given two StartDate values (SDa, SDb) and two EndDate values (EDa, EDb) of a fully qualified date type:

No Overlap -- EDa Overlap -- SDb I have this written on a PostIt in my binder.

Re: How to Interview Engineers

#316

Post by FilterSweep »

cnp wrote: post #222
zimzam wrote: post #177

Earlier quoted context omitted.

I've been a developer for years and worked for multiple companies: the most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10. Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.

Same here, and have worked on some extremely high-profile, complex things. Never _ever_ have I been as stressed as when asked to perform interview whiteboard questions. It simply doesn't compare.

Sometimes, you just have to appreciate the Torvalds-level of arrogance expressed in some of replies on HN.

Re: How to Interview Engineers

#317

Post by rmah »

arethuza wrote: post #240
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.

"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).

Re: How to Interview Engineers

#318

Post by DenisM »

DoofusOfDeath wrote: post #163
DenisM wrote: post #151

Sometimes I ask candidates to come up with a question for the interview, something that would allow them to put their best foot forward. Any thoughts on that?

I've never seen it done, but it sounds like there's potential. How has it played out when you've done that?

Not well. Candidates get disoriented and can't come up with anything relevant. It's a very small dataset though.

Re: How to Interview Engineers

#319

Post by cl0wnshoes »

I've performed interviews and phone screens for years and out of all the techniques I've tried all of them typically end up with me thinking I'm doing it wrong. Basic domain questions, problem solving, white boarding, white boarding along side the person helping them out, coding in an IDE, take home projects. As of today, in Kansas City, I'm looking at around 4% pass rate, and close to 90% utter face palming failures.

I check my ego at the door, I try to make the person as comfortable as possible, small talk, help them out as much as I can, provide them with answers or explanations when they get something wrong. I've never asked an algorithm or data structure question, I've rarely asked a patterns question. Most people can't answer basic every day questions.

Overtime my goal in interviews turned into making sure the interviewee left with more domain knowledge than when they came in hoping it will help them do better somewhere else.

Ended up creating a pre-screening service that asks the same basic questions and in the end provides the user with a study guide based on how they answered. Currently piloting with two local recruiting companies and I'm finding the same similar statistics of failure/success. Maybe that makes me the issue :)

Re: How to Interview Engineers

#320

Post by ambicapter »

bumbledraven wrote: post #101
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…

> given the starting and ending times of two calendar appointments, determine whether or not they conflict. Say the first appointment goes from a to b and the second goes from c to d . What does it look like if the appointments _don't_ conflict? This happens just when one appointment ends no later than the other begins; in other words, when b ≤ c or d ≤ a . So, the appointments conflict just when not( b ≤ c or d ≤ a…

If one appointment is wholly contained in the other, then b > c and a .
Post reply on HN