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

241–250 of 489 posts

Re: How to Interview Engineers

#241

Post by hvidgaard »

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.

It's absolutely relevant. On more than one occations I've had performance issues land on my table with the developer that wrote the code saying "it's not that bad, it's going through 100.000 elements". They simply don't have a relation to how much a modern computer can do in a given timeframe.

Usually I can guide them to understand where the bottleneck is, but every so often I have to rewite it so performance is acceptable.

Re: How to Interview Engineers

#242

Post by hvidgaard »

moduspol wrote: post #230
adrianratnapala wrote: post #186

Earlier quoted context omitted.

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.

The carpenter may simply know that turning the screw is imperceptibly instant in his experience, and that if the bookshelf isn't getting built quickly, the bottleneck is virtually never because he's waiting on screws to be turned. He's going to have to make a trip to the store anyway so he isn't concerned with whether turning the screw requires a tenth or a thousandth of a second. He's more focused on the design and…

If he is good, he can reason about it on the spot. If he can't, I very much doubt that he can design anything excellent. That requires critical thinking to understand what it is being used for, what is good, and importantly what solutions are unsuitable for the problem he is trying to solve.

Re: How to Interview Engineers

#243

Post by tzs »

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.

> Your cases don't consider [1 start][2 start][2 end][1 end] or the opposite [...]

Your notation there, where instead of a pair of start/end pairs you have a list of tagged times, reminds me of a good approach if one is doing a generalized version of the problem: given a list of N appointments, find conflicts.

Make a list of tagged times, where a tagged time is a triplet (time, 1, name) if appointment named "name" starts at time "time", and is (time, -1, name) if appointment named "name" ends at "time".

Sort the tagged time list with time ascending as the primary sort key, and the start/stop tag ascending as the secondary key.

Now to find conflicts you simply scan through the tagged times list, keeping a running total of the start/end tag values. If the running total is greater than 0 when you begin to process a given entry, that entry has a conflict with an earlier appointment, and the running total is how many earlier appointments it conflicts with.

As described above, this lets you print a list of what appointments have conflicts with earlier appointments, but it doesn't give an easy way to say which earlier appointments conflict. If you want to do that, it is straightforward. Just add a set data structure, and during the scan of tagged times add "name" to the set when you encounter an appointment's start, and remove "name" when you encounter an appointment's end. When you find a conflict, the set contains the names of all of the earlier appointments the present appointment conflicts with.

The above assumed that two appointments do not conflict if the ending time of the first is the same as the starting time of the second. If that should be counted as a conflict, just change the sort so that the secondary key is sorted descending instead of ascending.

Re: How to Interview Engineers

#244

Post by yosefk »

mychael wrote: post #239

> background-blind interviews, looking at coding skills, not credentials or resumes. Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers." > An interview can result in a bad engineer being hired and later fired (a false…

It's hard to know if a patent holder or system architect actually did the work or just took credit for it. It's easy to check if someone can print out a binary tree. Certainly a "system thinker" who can't write the simplest code and assumes it's for "monkeys" to do it is worthless both as a programmer and in any higher-level capacity, whereas someone who can program might be able to do meaningful higher-level work.

Re: How to Interview Engineers

#245

Post by hvidgaard »

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 assume that the question is meant to give insight into how they solve a problem that on the face of it looks straight forward?

It isn't though. First assume that all datetime stamps are in UTC, otherwise we have opened a can of worms that still trip experienced developers. Now draw a "timeline" and start enumerating the different cases. Then you can make a reasonable solution. But I would only expect this from experienced developers or people with a higher degree.

Re: How to Interview Engineers

#246

Post by fnord123 »

mychael wrote: post #239

> background-blind interviews, looking at coding skills, not credentials or resumes. Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers." > An interview can result in a bad engineer being hired and later fired (a false…

>Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."

I agree that the article gets this wrong. It reminds me of Diego Forlan's time at Manchester United.

Diego Forlan is/was an Uruguayan striker at Independiente (Arg) where he scored 36 goals in 77 games (a very good rate). He then moved to Manchester United (Eng) in January of 2002 and was anticipated to take off. He made 18 appearances in the 2001-2002 season but failed to score. It took him until October to net his first Premier League goal.

He was loved by the fans as he has/had a great attitude and had some delightful near misses. He also famously scored twice against Liverpool[1]. But he continued to struggle at United, scoring only 17 goals in 63 appearances until he was sold to Villareal (Esp) in August of 2004. In his first season at Villareal he won the Pichichi Trophy (golden boot for La Liga) and the European Golden Boot. What a turnaround!

Forlan went on to have a terrific career and is considered one of the best Uruguayans to play modern football (soccer). His time at United was certainly a misstep but it wasn't because he was bad. And it wasn't because United were bad. It just didn't work. Sometimes it just doesn't work.

[1] https://www.youtube.com/watch?v=49Zym0gaZqA

Re: How to Interview Engineers

#247

Post by 0xbear »

seangrogg wrote: post #228
0xbear wrote: post #216

Earlier quoted context omitted.

No, it's more like asking a roofer how about the area he can cover with shingles per hour. Information of vital importance.

Let's be real, if a roofer was asked anything comparable to a programming question it would be to provide an accurate approximation of the total number of roofing contracts completed globally within the last half-minute on the back of a coffee-stained napkin.

But that's not what's being asked by OP. Their question is rather simple, and software engineer should be able to answer it on autopilot, without even engaging her brain. As a hiring manager I would end the interview right there and then after the failure to answer something like this.

Re: How to Interview Engineers

#248

Post by pavlakoos »

jk563 wrote: post #238
pavlakoos wrote: post #234

Some engineers I interviewed got "offended" by ElonMusk-like questions and refused to answer :)

What type of questions do you mean?

Imagine a cottage with all 4 walls facing south. And there is a bear visiting it. What is the color of bear's fur?

Re: How to Interview Engineers

#249

Post by saagarjha »

lurker83256 wrote: post #236
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…

This question is trickier than it sounds. Sure 10 9 clock cycles per second, but estimating for actual human-perceived ops for an algorithmic problem one should use 10 6. (Source: USA Computing Olympiad problems.)

Would you mind explaining in a bit more detail what you mean here? I'm not quite sure where you're getting those numbers from.

Re: How to Interview Engineers

#250

Post by rf15 »

> 9. Make decisions based on max skill, not average or min skill

This is a strict specialist search - here, too you should make a decision depending on your requirements and future outlook: Do you need a generalist that can branch out and specialise, or strictly a specialist that only does the thing you need right now?

(Also let's not argue which is better, specialist or generalist - deep down, each of us already knows and made the choice ;) )

Post reply on HN