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

101–110 of 489 posts

Re: How to Interview Engineers

#101

Post by bumbledraven »

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). We can then distribute the negation using [De Morgan's laws](https://en.wikipedia.org/wiki/Negation#Distributivity) to arrive at this: the appointments conflict just when b > c and a > d.

Re: How to Interview Engineers

#102

Post by threepipeproblm »

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 think it's largely just human nature. People don't know what they don't know, and those who "make it" without college are often particularly disdainful of academics. They may also be hesitant to hire those with a deeper background (which is a general phenomenon in many areas). In many fields, the percentage who can "make it" without higher education may be higher, but it's certainly do-able in our industry -- especially if they stick to a certain kind of software. Someone in this position may develop a real knack for avoiding hard problems (in the computational complexity sense) without ever quite realizing that is what they are doing. I almost didn't go to college, since I thought I knew it all, and had plenty of offers when I graduated high school. One of the most general things I learned was how much useful stuff there was to know, that I would have never fathomed.

In my experience, people are often hesitant to hire people who are higher on some (perhaps tacit) measure of nerdiness. Only when people want to win badly enough and it's clear that others are doing better, will many people start questioning such biases.

Re: How to Interview Engineers

#103

Post by ammon »

gaylemcd wrote: post #95

I agree with much of this. Some additional comments: > Ask questions as close as possible to real work: This is achieved by making interview question as similar as possible to the job you want the candidate to do (or to the skill you're trying to measure). This "or" thing in parentheses is really important. Interviews should not be "as similar as possible to the job." They should be all about the skill you want to me…

So, we've gathered data on exactly these points over the last 2 years. And what we've found that the decision that gets the best signal is often not what feels most accurate to the interviewer.

For example, my guess before running these experiments would have been that simply looking at progress (how far a candidate gets through a problem) would be a bad measure of interview performance. I'd expect that things like style and how communication how careful a candidate was being would render pure progress a mad metric. However, when we compare pure progress to a subjective score the interviewer gives the candidate (ignoring specific reasons, does the interviewer think the candidate is a good engineer after the interview), we found that pure progress is more predictive of success at companies! (To be clear, we don't only look at progress at Tryplebyte. We've also found other things to be predictive.)

The same is true (among our candidates at least) for question difficulty. Easy, straightforward question (write a command line interface to store and retrieve key-value pairs) are more predictive of success at companies than question that try to target intelligence (calculate how much water would collect in a histogram)

Re: How to Interview Engineers

#104

Post by venture_lol »

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…

If the candidate starts by drawing 2 lines, then marking start and end on the lines, you know you would be off to having a good chat

Re: How to Interview Engineers

#105

Post by Stratoscope »

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…

Consider appointments from 1-3 and 2-4:

a = 1, b = 3, c = 2, d = 4.

Do they conflict?

Re: How to Interview Engineers

#106

Post by mattnewton »

stanleydrew wrote: post #71
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…

This is silly. Your BATNA can be the amount a competing company is willing to pay you in another offer. If you lack confidence that you'll be able to find at least another two job offers in a timeframe that makes you comfortable, then I agree don't quit your job. Anyone with experience shouldn't lack that confidence though.

I'm not wealthy enough to wait for a better offer indefinitely, and the places I was applying to are for all intents and purposes. Negotiating with only X months of runway is very different.

Your argument also assumes that I have a competing offer already when negotiating, but how did I get that competing offer? If you have a job, that solves the chicken and egg problem. If you don't, you don't have the leverage to anchor that first offer, which anchors the second, etc.

Having done both at similar skill levels, I can tell you the outcomes are much better with a job in hand.

Re: How to Interview Engineers

#107

Post by bogomipz »

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.

Wow this is next-level outrageous!

Could you share the name of the company so others might avoid them and avoid wasting their time with such nonsense?

Re: How to Interview Engineers

#108

Post by aldarn »

jon_richards wrote: post #96
aldarn wrote: post #93

Earlier quoted context omitted.

This is close but you need to ensure the start time is before the other ends, and test for the second one starting before the first also. There's four cases: [appointment 1 start] [1 end] [appointment 2 start] [2 end] (case 1 - no overlap, appointment 1 first) [appointment 1 start] [appointment 2 start] [1 end] [2 end] (case 2 - overlap, appointment 1 first) [appointment 2 start] [appointment 1 start] [2 end] [1 end]…

Your cases don't consider [1 start][2 start][2 end][1 end] or the opposite, but your pseudocode still covers those cases.

True, I didn't include those cases as they are not unique in terms of why there is / isn't a conflict. But you're right, worth including for completion.

Re: How to Interview Engineers

#109

Post by bogomipz »

>"After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe)."

Can anyone from any of these companies confirm this? This strikes me as really odd. So only one employee from FB, Apple, Dropbox, and Stripe needs to interview a candidate that Tripplebyte say is a "Go"? I'm having a hard time believing that.

Re: How to Interview Engineers

#110

Post by aldarn »

e12e wrote: post #100
pinot wrote: post #84

Earlier quoted context omitted.

I'm not a programmer but wouldn't if (endtime[1] > starttime[2]){status=conflict} work? Assuming time is encoded in epoch format.

I'd say so. The "assuming time encoded"-bit is important though - I rather think starting with the data is valuable: Can I assume the times are in a sane date format/datatype? If not, start with e1 = toSaneDateFormat(endtime1), s2 = toSaneDateFormat(startime2) (Fill in if interviewer is interested). Then, as you say, a check for overlap is easy - but maybe one wants to be more fancy, like: if (timeDelta(e1, t2) At an…

This is a great example of why the OPs question could be a good or terrible interview question -- it's not clear if they want the obvious technical solution (comparing datetimes) or a wider discussion about "what is a date time and how is the data represented", "what are the real world / business implications", "here is existing technology using intervals that will solve it" etc as you mentioned.

In my experience interviewers are usually looking for the technical solution despite the business oriented solution usually being much more applicable (and thus relevant) in the day to day role.

Key thing to remember here as an interview candidate is to clarify with the interviewer the scope of the question and the nature of the answer they're looking for. If for instance the interviewer starts with the simple technical solution and then probes the business aspects this might be a nicely rounded question.

Post reply on HN