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

271–280 of 489 posts

Re: How to Interview Engineers

#271

Post by Yizahi »

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.

When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.

(1) because "it is faster" and "my dad always did this" and "you don't pay for my saw, so shut up"

Re: How to Interview Engineers

#272

Post by qb45 »

justinpombrio wrote: post #156
zumu wrote: post #143

Earlier quoted context omitted.

If you were writing code, I would argue against using De Morgan's laws just because you can. You're saving a few characters to make the code less obvious. Please correct me if there's some other benefit.

Usually after a mathematical simplification like this, you can find a direct explanation for it. In this case you can reason: If two appointments conflict, that means that there is a time when they are both active. Thus each of their end times are after both of their start times. Of course, each appointment ends after it started, so that just leaves that each appointment ends after the other started. So if the appoin…

I would say, if the transformation makes the code and the reasoning behind it simpler then do it. Otherwise, know that any decent optimizing compiler can do this trick by itself so what you write only influences readability.

Re: How to Interview Engineers

#273

Post by qb45 »

ball_of_lint wrote: post #119
bumbledraven wrote: post #101

Earlier quoted context omitted.

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

You have a mistake in the last not of your formula. The opposite of d a, not a>d.

This mistake could be made more "eyesoreous" and possibly avoided by naming the begin/end times b1, b2, e1, e2 instead of opaque letters. I would fire the OP for that alone :p

Re: How to Interview Engineers

#274

Post by pc86 »

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 get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality

Mother of god

Re: How to Interview Engineers

#275

Post by pc86 »

missblit wrote: post #201
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 all fun and games until one of your appointmets is specified in rfc2550 format, and the meeting room is on a big ship crossing the international date line on the same day daylight savings time changes for the ship's country while a new timezone is voted into effect. Meanwhile the other meeting room is a videoconfrerence between the international space station and a ship travelling at close to the speed of light,…

Also the meetings are in different rooms with entirely different attendee lists, so whether they conflict or not is irrelevant.

Re: How to Interview Engineers

#276

Post by qb45 »

deathanatos wrote: post #167
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 remov…

Funny, I remember being blown away when somebody asked me this question on my first internship interview. Only later I read about FizzBuzz and became enlightened ;)

Re: How to Interview Engineers

#277

Post by pc86 »

ben_jones wrote: post #83
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 many companies hire with the number one goal of reducing false positives. By definition this approach is going to unfairly reject a number of candidates. I would argue that it also dehumanizes a number of candidates, forcing them in aggregate to play a numbers game until they are in the top 20%-40% of the pool (if they ever get there) where companies then begin vying for them. It is as you put: depressing as…

> By definition this approach is going to unfairly reject a number of candidates.

This is only a problem if the interview/hiring/capitalism process is meant to be fair.

> Imagine how it must feel to be an uneducated demographic in most other parts of the world

The less privileged here certainly had jobs in HS and college where you just filled out an application, the manager made sure you weren't a convict or on drugs, and you got the job. The "uneducated demographic in most other parts of the world" is probably not solving algorithm quiz questions on a whiteboard.

Re: How to Interview Engineers

#278

Post by qb45 »

alexashka wrote: post #132
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…

Determining if two intervals overlap is not a trivia question but a trivial question for a programmer and hiring people who can't do better than O(n²) probably is good only for really boring maintenance projects where the workload lags far behind Moore's law.

I'm not necessarily saying that such things don't exist, but not my cup of tea.

Re: How to Interview Engineers

#279

Post by pc86 »

alexashka wrote: post #132
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…

TIL building products that make money (as opposed to pre-revenue VC-funded CRUD apps) with a team that enjoys their job and can be home by 4 every day is not "real development."

Re: How to Interview Engineers

#280

Post by FilterSweep »

lopatin wrote: post #166
kafkaesq wrote: post #158

Earlier quoted context omitted.

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.

This is far too much of a simplification of (grand)Parent.

you don't know the circumstances that 30 year old programmer with a 2 year old child at home is facing. You could also be like certain firms and immediately nix him on the "merits" of ageism.

A female programmer might have travelled 2000 miles to just receive an abstraction question out of left-field over an irrelevant concept to the job. She flew out on this uncertainty, and she's in a rather discriminatory field.

26 year old dev has probably built CRUD apps all his short career. and, you're asking him to implement (isBinarySearchTree Boolean) on a whiteboard on the spot.

Post reply on HN