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

321–330 of 489 posts

Re: How to Interview Engineers

#321

Post by lkrubner »

weaksauce wrote: post #138
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 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?

See "Embarrassing code I wrote under stress at a job interview" which was discussed on Hacker News here:

https://news.ycombinator.com/item?id=9478906

Re: How to Interview Engineers

#322

Post by watwut »

FilterSweep wrote: post #311
watwut wrote: post #229

Earlier quoted context omitted.

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?

Observation after seeing countless schoolmates answer questions for grade. There were only few people that would be blacked out regularly no matter what age.

Yes, I have faced questions I could not answer. I did my best and that was it. That is however not blackout - that is me not knowing the answer. Blackout is when you temporary can't recall.

Re: How to Interview Engineers

#323

Post by watwut »

Bahamut wrote: post #303
watwut wrote: post #229

Earlier quoted context omitted.

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.

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.

Re: How to Interview Engineers

#324

Post by Jach »

crdoconnor wrote: post #261
yetihehe wrote: post #232

Earlier quoted context omitted.

And for me that was a perfect interview. First quick question by email to see if I was interested, then some simple test to see if I can really program, then quick interview to see if I have required domain knowledge (all questions were about knowledge required to program effectively, not abstract "how to move mount fuji"). For an introvert programmer like me it's a perfect interview schedule. Also it helps when you…

I gave up on those the last time I wasted 4 hours of my life on one of those tests and never even got a rejection email. It wasn't a hard test and I didn't do badly. Nowadays I just point them at my github. If a body of open source isn't enough to get an interview I'm not interested in working there.

Are you against coding tests in general (especially when you have open source work to point to) or just as a prerequisite to speaking with someone?

Re: How to Interview Engineers

#325

Post by arethuza »

crispyambulance wrote: post #291
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 spent 2 days troubleshooting a machine vision system at bolt factory. Physically in the factory. On my feet. Standing behind an active vibratory hopper filled with bolts, while stake-holders were losing money hand-over-fist, and angry machinists who looked like a motorcycle gang stood next to me. And it was a Windows NT machine. Not quite all about algorithms, but that was part of it :-)

Yes, and I've set up a demo of an interactive TV system in a cupboard at a large London hotel (standing room only!)...

Also found that the probability of someone finding the porn in the demo by randomly pressing remote buttons pretty much approaches 1 as number of button presses approaches infinity...

Re: How to Interview Engineers

#326

Post by rmah »

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…

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.

Re: How to Interview Engineers

#327

Post by jerrylives »

stephenbez wrote: post #64
mattnewton wrote: post #55

Earlier quoted context omitted.

I think this is a crazy expectation. I last switched jobs while working at Apple last October. Having the BATNA of your current employment is crucial to the negotiation process and I can't imagine forgoing that- if you have no current income that's an insane bargaining handicap. Anyone with experience absolutely is not going to go for "quit your job, and maybe we'll give you a new one after a week, maybe it won't wor…

I had a YC company that wanted me to do a trial week. They wanted me to quit my job when I said I couldn't take off a week of vacation. When I said no, they wanted me to come out Friday through Monday and since the whole company works on the weekend, they would get 4 days to work with me. At that point I said I wasn't interested.

Dude.

I just finished working for a YC company that not only demanded a two week trial period, but after doing that trial period instead kept me on a contract billed for eight hour days but then insisted I must be in the office from 9 - 6:30 (their "engineering hours"). They wanted me to work close to 50 hours a week for no health insurance while underpaying hours and forcing me to attend all company events including weekend "hackathons" (haha so fun). It was a nightmare and I'm glad to be out of it.

The irony is that it was a company that prides itself on giving people stable jobs and healthcare.

Re: How to Interview Engineers

#328

Post by js2 »

watwut wrote: post #205
lomereiter wrote: post #187

Earlier quoted context omitted.

They might not care, but in that case this question essentially tests if a person understands what 'GHz' means and can think logically, which is not that much to ask.

Why would web programmer think about processors and GHz is beyond me. There are jobs where it might matter, but for most of them it is completely irrelevant.

I know we can treat a lot of the technology we use as a black box, but not knowing even the basics of that technology indicates a lack of curiosity. I'd be shocked to find a competent programmer who couldn't answer the question.

A similar question: approximately how many IPv4 addresses are there?

See also: "Latency Numbers Every Programmer Should Know"

Re: How to Interview Engineers

#329

Post by padobson »

bogomipz wrote: post #122
padobson wrote: post #36

Earlier quoted context omitted.

When did you last switch jobs? I recently went through a round of employment where I quit my job at the beginning. Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job. I can't imagine finding a new programming job while still working at the old job.

>"Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job." Can you break down how much time you spent on each of those tasks that they took up the equivalent of an entire 8 or 9 hour work day 5 days a week? I think you might be in the minority with your outlook. Most people…

Sure, here's an approximate breakdown:

Morning: 1-2 hours: Study a chapter of CLRS Algos book 1-2 hours: HackerRank 1-2 hours: Studying trivia of technology X

Afternoon was all about sales - updating social networks, filling out applications, talking to recruiters on the phone, scheduling interviews, etc. I probably applied to about 250-300 companies.

I made tweaks as I went - I found that recruiters preferred to talk in the morning, so I eventually inverted the whole thing. I started to sniff out which companies were serious about hiring and which perpetually advertise for talent

This is just a rough framework. Sometimes I'd spend the whole morning on CLRS, or a tricky Hacker Rank problem, other times I'd spend the whole day interviewing.

Before I spoke with anyone at a company, I always did research on them, the company, the company's market, and the technologies they were interviewing for.

Re: How to Interview Engineers

#330

Post by pogaxvr »

detaro wrote: post #312
pogaxvr wrote: post #289

Earlier quoted context omitted.

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.

Clock rate != operations. It's like you didn't bother to read what I wrote.
Post reply on HN