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

81–90 of 489 posts

Re: How to Interview Engineers

#81

Post by kornish »

ionwake wrote: post #76
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 funny part is I reckon you would struggle to answer the question yourself when put on the spot, if you had no prior experience of it. Just my opinion of course and I am speculating.

What's your basis for that speculation?

The solution is a simple predicate. Assuming both events are internally consistent (i.e. end time after beginning time) they won't overlap so long as the beginning of the first comes after the end of the second OR the beginning of the second comes after the end of the first.

Seems like a good weed-out problem.

Disclaimer: no prior experience with the problem.

Re: How to Interview Engineers

#82

Post by walshemj »

angryasian wrote: post #23
padobson wrote: post #9

Spending a week working beside an engineer (or seeing how they complete a substantial project) almost certainly provides a better measure of their abilities than watching them solve interview problems for 1 hour Trial employment is expensive for the company. [...] Trial employment (and large take-home projects) are expensive for the candidate. I can't help but think there's way to mitigate that expense among several…

If I'm already employed, it be weird to take a week off just to work for another company. Also ramp up time takes at least a day or two. This whole process seems troublesome for both the employee and employer

And a breach of contract in 95+% of cases this 1 week trial only really works for new grads and any how as the USA is at will what is the issue here.

Re: How to Interview Engineers

#83

Post by ben_jones »

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 many companies hire with the number one goal of reducing false positives. By definition this approach is going to unfairly reject a number of candidates. I would argue that it also dehumanizes a number of candidates, forcing them in aggregate to play a numbers game until they are in the top 20%-40% of the pool (if they ever get there) where companies then begin vying for them.

It is as you put: depressing as hell. And this is among white collared, educated, demographics. Imagine how it must feel to be an uneducated demographic in most other parts of the world...

Re: How to Interview Engineers

#84

Post by pinot »

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'm not a programmer but wouldn't

if (endtime[1] > starttime[2]){status=conflict}

work? Assuming time is encoded in epoch format.

Re: How to Interview Engineers

#85

Post by YorickPeterse »

angryasian wrote: post #23
padobson wrote: post #9

Spending a week working beside an engineer (or seeing how they complete a substantial project) almost certainly provides a better measure of their abilities than watching them solve interview problems for 1 hour Trial employment is expensive for the company. [...] Trial employment (and large take-home projects) are expensive for the candidate. I can't help but think there's way to mitigate that expense among several…

If I'm already employed, it be weird to take a week off just to work for another company. Also ramp up time takes at least a day or two. This whole process seems troublesome for both the employee and employer

    > it be weird to take a week off just to work for another company
It's not even weird, it's just downright insane. No person should be expected to essentially work for free for a week without any guarantees they will get anything out of it.

Re: How to Interview Engineers

#86

Post by emerongi »

stevenwoo wrote: post #77
emerongi wrote: post #70

Earlier quoted context omitted.

I've written at least 5 linked lists in the past year. They're quite useful.

Five different implementations of linked lists?

Yes. To be fair, this is the first time in my life I can clearly remember implementing a number of linked lists.

I'm pretty sure my lifetime total is not much greater than 5.

Re: How to Interview Engineers

#87

Post by dragonwriter »

pinot wrote: post #84
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'm not a programmer but wouldn't if (endtime[1] > starttime[2]){status=conflict} work? Assuming time is encoded in epoch format.

And assuming that "1" and "2" refer to the appoints in order of start time, but they may not be given in that order.

Re: How to Interview Engineers

#88

Post by radicaldreamer »

supran wrote: post #59
jobu wrote: post #5

"15% dislike academic CS (and think that talking about CS is a sign that a candidate will not be productive)" That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.

I have a CS degree from CMU, and I've only run into that sort of attitude once. The interviewer nit-picked my solution to some character array manipulation question. I didn't get an offer. The interviewer wrote some snarky comment on his Twitter the day after my interview; something about "the difference between a computer scientist and engineer". Six months later his company was bought and chopped up. He got laid of…

It’s a loss for any interviewer to let pedigree bias them one way or another. If you’re willing to be interviewed, then they’ve got a pretty good opportunity to make a much more informed decision than letting their bias do it for them.

Re: How to Interview Engineers

#89

Post by rezashirazian »

pinot wrote: post #84
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'm not a programmer but wouldn't if (endtime[1] > starttime[2]){status=conflict} work? Assuming time is encoded in epoch format.

also if (endtime[2] > starttime[1]){status=conflict}

Re: How to Interview Engineers

#90

Post by dcwca »

pinot wrote: post #84
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'm not a programmer but wouldn't if (endtime[1] > starttime[2]){status=conflict} work? Assuming time is encoded in epoch format.

That's half of it, but doesn't account for the case when starttime[1] is later than endtime[2] and they don't intersect.
Post reply on HN