How to Interview Engineers • Hacker News Board

Re: How to Interview Engineers

#161

Post by le-mark » Tue, Jun 27, 2017, 1:51 AM UTC

blister wrote: post #58

scottLobster wrote: post #19

Earlier quoted context omitted.

I suppose it depends on your 5-year goals and the position, but as an entry-level developer my first thought would be: "Well as I'm interviewing here I would obviously see taking this position as a step foreword for all the reasons we've discussed. Naturally I don't see this position as the job I'll work until I retire, and obviously I'll be looking for at least some mild expansion of responsibilities in the future.…

Dude, you absolutely should be trying to be a manager in 3 years, if you want to go down the management track. Depending on company size, you should probably be a team-lead or something by then. Junior developers that remain "solo" workers after 3+ years in the industry is a bad sign for value. If you've been developing for a while, at the very least you should be put in a leadership position from a project perspecti…

There are a whole lot of senior developers who've done a turn as lead/manager, only to go back to dev. It's not for everyone, and promoting this narrative that it should be everyones goal is kind of shallow.

Re: How to Interview Engineers

#162

Post by Stratoscope » Tue, Jun 27, 2017, 2:07 AM UTC

barrkel wrote: post #129

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…

It's actually a tricky problem to think clearly about unless you start enumerating the cases, or get pen and paper out to draw some boxes. I don't think it's completely trivial to verbalise. But I also don't think a competent programmer should fail to work it out. I like the problem, and I'll probably use it in future :) It'll be a low bar for those times where you're getting the impression that a bigger task will be…

It may be easier to verbalize than we think. I just realized that for me the trick might be to not be too abstract and formal when first thinking it out, but look at it more like an everyday problem.

Instead of this:

"Given two appointments, one that starts at time A and ends at time B and another that starts at time C and ends at time D, how can I tell if they conflict?"

Re: How to Interview Engineers

#163

Post by DoofusOfDeath » Tue, Jun 27, 2017, 2:16 AM UTC

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?

Re: How to Interview Engineers

#164

Post by itsdrewmiller » Tue, Jun 27, 2017, 2:29 AM UTC

bogomipz wrote: post #153

tzs wrote: post #139

Earlier quoted context omitted.

> So why does it matter whether the first round of interviews is done by this company or the actual company doing the hiring? I think the idea is that if you do the first round with Triplebyte instead of with Apple, Facebook, Dropbox, or Stripe you are effectively doing the first round with Apple, Facebook, Dropbox, AND Stripe.

>"... you are effectively doing the first round with Apple, Facebook, Dropbox, AND Stripe." Except that I am not. By doing the first rounds with Tripplebyte I have squandered an opportunity to learn about and form an opinion about the people and team I might be working with in the future. The more answers I can get to my questions the better informed I am. I guess I don't understand this whole "we will fast track you…

Assuming you don’t pass 100% of on site interviews or you don’t take the first offer immediately, triplebyte will save you some amount of time. Beyond the force multiplier for pre-onsite interviews, they also can predict which companies you will have a higher success rate with for your on site. It’s not a guaranteed slam dunk for every single person (and you still have to pass their process) but I think the value proposition is pretty obvious to most people.

Re: How to Interview Engineers

#165

Post by Stratoscope » Tue, Jun 27, 2017, 2:36 AM UTC

aldarn wrote: post #93

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.

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]…

I was thinking along the same lines as you, but it turns out you only need two comparisons and one logical operator.

barrkel has a thorough explanation here:

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

Or, as I realized later, it seems helpful to me if I look at it as a practical problem instead of an abstract one:

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

Re: How to Interview Engineers

#166

Post by lopatin » Tue, Jun 27, 2017, 2:39 AM UTC

kafkaesq wrote: post #158

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?

Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview? This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by…

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.

Re: How to Interview Engineers

#167

Post by deathanatos » Tue, Jun 27, 2017, 2:43 AM UTC

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 have similarly asked "write a function, minimum(), that takes a list of integers and returns the smallest integer in the given list" for quite some time. It's disturbingly effective.

I've always asked something that involved a loop, to ensure that candidates understood how to write a for loop.

(I have a variant of the above, a "more complicated" question, that involves maintaining two pointers/iterators; that removes another huge chuck of candidates…)

Re: How to Interview Engineers

#168

Post by gilbetron » Tue, Jun 27, 2017, 2:43 AM UTC

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…

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 straight forward, and nervousness is the biggest issue. Sucky people whine about reversing a linked list or finding a cycle or whatever.

Re: How to Interview Engineers

#169

Post by losteric » Tue, Jun 27, 2017, 2:48 AM UTC

kafkaesq wrote: post #158

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?

Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview? This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by…

This is why it's important to start the interview with culture/work history questions to probe how they're feeling, watching their body language, before moving on to simple questions of increasing complexity.

I've literally started nervous people with "naively print the string 'hello'"... After warming up, the best one eventually completed my max-difficulty questions.

Re: How to Interview Engineers

#170

Post by deathanatos » Tue, Jun 27, 2017, 2:52 AM UTC

DonaldFisk wrote: post #160

supran wrote: post #53

Earlier quoted context omitted.

You're too forgiving. I turn down interviews when they list "linked lists, hashing, breadth/depth first search" on their study guide. I've never had to write a linked list EVER in my career, don't fucking bother me with that shit. Also, if the position is in a language where linked lists would be stupid (i.e. python), then I definitely reject that company. I can explain what everyone of them is, and why you'd want to…

(Singly linked) lists have many advantages (e.g. useful operations on them are side-effect free), but whether they should be used depends upon which problems you solve and which languages you use. It's unsurprising they're used all the time in Lisp, and functional programming languages generally. I'd advise against their use in C or other languages without garbage collectors. They're rarely needed in languages (such…

What language would you recommend using a singly-linked list in, aside from Lisp? Why is it any less valid in non-GC'd languages? (Aside from memory management in C is fraught with error, but that's a problem not unique to singly-linked lists.)

I've never looked (at least, that hard) at the language; it was always a question of "is this the appropriate data structure for this task?". Linked-lists have somewhat peculiar time complexities, but occasionally those line up with what you need. (Usually a vector is also as good, time-complexity-wise, and wins out by being contiguous. But if you need O(1) removal…)