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

131–140 of 489 posts

Re: How to Interview Engineers

#131

Post by barrkel »

delinka wrote: post #126
Stratoscope wrote: post #114

Earlier quoted context omitted.

Hmm.. Perhaps I did misunderstand something. But if the test for a conflict is: b > c and a > d with conflicting appointments from 1-3 and 2-4: a = 1, b = 3, c = 2, d = 4 won't that evaluate to: 3 > 2 and 1 > 4 true and false false (no conflict) I could be wrong, but I think you have to do all four comparisons as in aldarn's comment: https://news.ycombinator.com/item?id=14641043 (no fair peeking!)

Just make sure your data is correct, and a single comparison works: https://gist.github.com/anonymous/c02d74eb75a51dce8dcbc027a3...

Your code has two comparisons; one to figure out which one starts first, and another to figure out whether the first one ends before the second one starts. This isn't getting your data correct; knowing which one comes first isn't part of the problem description :)

Re: How to Interview Engineers

#132

Post by alexashka »

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…

Depending on what you're hiring for, it's really not all that depressing.

If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly.

Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically.

If you want people to do real development, those are hard to come by. If what you really need is someone to maintain some bloated codebase and make it worse, but not too fast, then most people will do just fine.

Another thing is: what do you really want from a candidate? What led you to start asking them trivia questions in the first place?

The really good ones will be put off by trivia because it brings them zero value. If you ask questions that actually pertain to the field you're hiring for, it'll go over much better.

For example I applied to work at a major bank, and got asked a bunch of security questions, which exposed me not understanding how main in the middle attacks worked. The interviewee had requested that I go home, do a bit of research and email them the answer.

This brought them value because they found out that's an area I have little knowledge in, and it provided me with value because it pointed me in the right place to go research.

Trivia puzzles don't add value to anyone. Frankly if you're doing trivia and are upset by the response you're getting, a part of that is your fault :)

Re: How to Interview Engineers

#133

Post by FLUX-YOU »

bg4 wrote: post #44
rsyring wrote: post #6

Earlier quoted context omitted.

I had a guy work for me that was very academic minded regarding programming. He had a hard time letting go of the "pure" way of doing things and taking a good/practical approach to just getting stuff done. It can definitely be, but won't always be, a detriment in my experience.

I've worked at places where well-meaning 'just get stuff done' people created mountains of technical debt that hobbled the project in the long term. Made them look great, though. Great programmers should hopefully recognize and implement a proper balance between practicality and rigor, as necessary. They should also exhibit self-awareness and self-restraint, which sounds like the real problem for the guy you mention.

>I've worked at places where well-meaning 'just get stuff done' people created mountains of technical debt that hobbled the project in the long term. Made them look great, though.

Those people were just getting a bit better at building things. They were building experience. It just so happens you found their bad code that they'll realize was terrible a few years from now.

We can't simultaneously hate our own previous code and expect everyone else to delivery perfectly when they first start (or even at mid-level).

Re: How to Interview Engineers

#134

Post by 0xffff2 »

As someone with an actual accredited engineering degree, I find it bizarre that Silicon Valley has decided that the term "engineer" doesn't even need to be qualified anymore. Even without getting into the flame war over whether "software engineers" are real engineers or not, there's a very large pool of engineers to which this post doesn't apply at all. I can't be the only one in the latter pool that reads HN, can I?

Re: How to Interview Engineers

#135

Post by flukus »

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

Does anyone really test for specifics like this? I thought the goal was to ensure the candidate understood that dates and times are abstract numbers, anyone that applies a mathematical operator should pass it. Yes this would still filter out a lot of people.

Re: How to Interview Engineers

#136

Post by Stratoscope »

barrkel wrote: post #124
Stratoscope wrote: post #114

Earlier quoted context omitted.

Hmm.. Perhaps I did misunderstand something. But if the test for a conflict is: b > c and a > d with conflicting appointments from 1-3 and 2-4: a = 1, b = 3, c = 2, d = 4 won't that evaluate to: 3 > 2 and 1 > 4 true and false false (no conflict) I could be wrong, but I think you have to do all four comparisons as in aldarn's comment: https://news.ycombinator.com/item?id=14641043 (no fair peeking!)

The test is the opposite of (X ends before Y starts) and (Y ends before X starts). You only need two comparisons. With two events, X going from xb to xe, and Y going from yb to ye, you have these possible sequences: xb xe yb ye (no conflict) xb yb xe ye (conflict) xb yb ye xe (conflict) yb ye xb xe (no conflict) yb xb ye xe (conflict) yb xb xe ye (conflict) As long as (xb >= ye or yb >= xe) there's no conflict. You c…

Yeah, you have it right. I had a nagging feeling that two comparisons ought to be enough, and something was just reversed in bumbledraven's formula. My first thought was that the 'and' should have been an 'or', but that was wrong. It was the comparisons that were reversed, as you demonstrate.

Just to compare with the previous comments, if we put your notation back into the a-b c-d format, then it would be:

conflict = c It's interesting to note how the choice of names makes such a difference. With the arbitrary names a, b, c, d for the four times, it's harder to think about whether the expression is right. Which was 'c' again?

Your names xb, xe, yb, ye are still terse, but once you know that x means one appointment and y means the other, and be and e mean beginning and end, it makes it much easier to think about it.

Re: How to Interview Engineers

#137

Post by cookiecaper »

watwut wrote: post #60
cookiecaper wrote: post #54

Earlier quoted context omitted.

It's not about "liking" theory. It's about talking about issues as theory as opposed to practicalities. You can like theory as much as you want, but if you don't talk about the real application, people will assume you've gone to class but haven't put it into practice.

It is interviewers job to get rid of illogical assumptions like this. This particular assumption is odd, experienced people often moves to talk about theory - sometime literally because they expect interviewers to be interested in that.

I don't think it's odd. The article says that 15% of Triplebyte's clients dislike it when things get too theoretical. Absent other signals, veering deep into theory on the assumption that interviewers generally like that is clearly the wrong idea.

My experience is that most people are happy to leave school behind, and they invoke theoretical concerns only when they are applicable and relevant. People want to hear about you've built and what you've done, they don't want their compsci textbook recited back to them.

If a candidate only has heavily academic projects, or can only discuss projects in heavily academic terms, interviewers may assume that the candidate is either a student or a researcher, and in either case, that person is probably not a fit for a conventional programming job (but they may be a great fit for a much cooler job in R&D somewhere).

Some companies really value an intensive academic background, but not all or even most of them (the article says that only 40% "need to see" academic CS skills, 15% actively dislike overt CS discussion, and that leaves 45% that didn't respond or don't care or whatever -- 60/40 split that talking less CS is at least harmless if not beneficial).

The takeaway, IMO, is to keep things at the high level, and stay focused on real, practical experience until prompted otherwise.

Re: How to Interview Engineers

#138

Post by weaksauce »

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?

Re: How to Interview Engineers

#139

Post by tzs »

bogomipz wrote: post #125
zippergz wrote: post #111

Earlier quoted context omitted.

I don't think "the final interview" means a single person. I took it to mean the onsite round, with however many people that entails, skipping the recruiter screen, phone screen, etc.

So why does it matter whether the first round of interviews is done by this company or the actual company doing the hiring? I would argue that as a candidate I would rather interview with as many of my potential coworkers as possible. Interviewing is a two way street. The more exposure to the actual people I would be working with allows me to make a better-informed decision. How is reducing my exposure better for me…

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

Re: How to Interview Engineers

#140

Post by beachy »

crdoconnor wrote: post #18
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.

>Academic CS isn't really necessary for most programming jobs Knowing how to code quicksort or reverse a binary tree isn't, but an understanding of normalization definitely is...

I always use normalization/database design as an interview question. I firmly believe that good questions about database design can really identify the candidate's skills and weaknesses in this area:

- it works well sitting around a whiteboard, which is a nice friendly dynamic that emulates how we really work

- it doesn't require detailed/arcane recollection of specifics, is more conceptual. Who wants to fail someone because they don't remember a parameter or some specific details of how TreeMaps work?

- it can't be faked - no-one can talk their way through a database design discussion unless they really have an aptitude for it

- its interesting. Who doesn't want to spitball around, say, modelling what Uber's database might look like behind the scenes.

I would say there are plenty of decent programmers around who can't (or haven't) done any real database design work, but if its a core skill (SaaS app development) that you really need, then its an easy one to detect at interview.

Post reply on HN