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

181–190 of 489 posts

Re: How to Interview Engineers

#181

Post by rasen58 »

gilbetron wrote: post #168
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…

I feel like that's a bad question to ask. An algorithm question at least lets you attempt it and you can see if they know things. But this question isn't something that people normally talk about or think about. I think older engineers would think this is a normal question to ask since they/you have seen the evolution of computers over time, and have actually seen the number of operations changing to get into the billions.

But this kind of thing may only be mentioned in one sentence in an intro computer systems course, and most young people wouldn't care about how many operations a CPU can do.

Re: How to Interview Engineers

#182

Post by mattnewton »

_ptgt wrote: post #144
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…

Why would it be a bargaining handicap unless you're running out of money (i.e. desperate)? If you're a strong enough candidate to land an offer at a top firm, it isn't worth it for them to low-ball you and risk spending more resources looking for strong candidates. Besides, if you can get an offer at Company X, you can probably get an offer at one of their competitors as well (which is your leverage).

Can probably get an offer is different from currently working at one of their competitors. It's a) a vote of confidence from another firm that this person is worth hiring b) an anchor point for your salary above where they would normally start the negotiations (yes even for "above average"). It removes all the guesswork of "can probable get an offer". You have one. Right now.

Additionally I've had negotiations stretch on for months. That isn't very comfortable with no income, and is an absolutely enourmous opportunity cost.

Re: How to Interview Engineers

#184

Post by mickg10 »

Apocryphon wrote: post #74
emerongi wrote: post #70

Earlier quoted context omitted.

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

What were you using them for?

Not sure about GP, but very recently, an open-addressing hashtable that could be traversed in both reverse modification and reverse insertion time order. There are actually some interesting subtleties when doing this for open-addressing hashtables (i.e., entries (and pointers to them) move around when the table rehashes).

Re: How to Interview Engineers

#185

Post by FT_intern »

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 most logical and clear answer for me (assuming I didn't already screw up by making assumptions about the data format, problem definition, etc.) is:

1. Figure out which appointment starts first

2. Check if first_appointment.end > second_appointment.start

So:

    boolean AreAppointmentsConflicting(int start1, int start2, int end1, int end2) {
      // first and second refer to the start time of the appointments.
      // The first appointment is the one with the earlier start time.
      int first_appointment_end, second_appointment_start;
      if (start1 > start2) {
          first_appointment_end = end2;
          second_appointment_start = start1;
      } else if (start1  second_appointment_start;
    }
That can be shortened to:

   return (start1 > start2 && end2 > start1) || (start1  start2) || start1 == start2;
Or shortened even further in https://news.ycombinator.com/item?id=14641485

The third answer would get massive upvotes for brevity on LeetCode. The first answer would be preferable for readability in an actual code base.

Re: How to Interview Engineers

#186

Post by adrianratnapala »

symlinkk wrote: post #180
gilbetron wrote: post #168

Earlier quoted context omitted.

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…

When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.

Well does it take about a second or about an hour to make one turn of the screw? If a carpenter doesn't know the answer to that in his bones, he won't be fastening many things together.

Re: How to Interview Engineers

#187

Post by lomereiter »

rasen58 wrote: post #181
gilbetron wrote: post #168

Earlier quoted context omitted.

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…

I feel like that's a bad question to ask. An algorithm question at least lets you attempt it and you can see if they know things. But this question isn't something that people normally talk about or think about. I think older engineers would think this is a normal question to ask since they/you have seen the evolution of computers over time, and have actually seen the number of operations changing to get into the bil…

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.

Re: How to Interview Engineers

#188

Post by solidr53 »

altharaz wrote: post #17

At my company our engineers defined the following process. First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity. Our process goes as follows: 1. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h. 2. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Or…

Are you serious?

Re: How to Interview Engineers

#189

Post by mikebenfield »

symlinkk wrote: post #180
gilbetron wrote: post #168

Earlier quoted context omitted.

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…

When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.

Whether this is a good interview question I don't know, but:

> When the hell would you ever need to know that?

I find this such a strange perspective. You're writing code for a computer. Sometimes you need to estimate how quickly it should run, or else estimate how quickly it could run with optimal code. Surely it's obvious that knowing how fast your computer does stuff, at least within 3 orders of magnitude, is a necessary ingredient to make that estimate.

And yet in your mind that fundamental fact is "useless trivia." Very odd.

Re: How to Interview Engineers

#190

Post by cakedoggie »

padobson wrote: post #36
angryasian wrote: post #23

Earlier quoted context omitted.

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

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.

That is ridiculous, you must have incredibly bad time management skills. Or do you actually think this is very common?

Post reply on HN