Live data from Hacker News

How to Interview Engineers

blog.triplebyte.com

221–230 of 489 posts

Re: How to Interview Engineers

#221
post #205

Earlier quoted context omitted.

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.

Why would web programmer think about processors and GHz is beyond me. There are jobs where it might matter, but for most of them it is completely irrelevant.

[deleted]

Re: How to Interview Engineers

#222
post #177

Earlier quoted context omitted.

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.

I've been a developer for years and worked for multiple companies: the most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10. Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.

Same here, and have worked on some extremely high-profile, complex things. Never _ever_ have I been as stressed as when asked to perform interview whiteboard questions. It simply doesn't compare.

Re: How to Interview Engineers

#223
post #53
post #28

Earlier quoted context omitted.

> how many people can get into a train Can't speak for everyone, but I'd turn away and walked out the instant I hear this or similar BS (which is totally unrelated to "approaching new problems" or "stress management" in programming at least)

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…

For me it is opposite. If the company gives reasonably sized study guide, I am cool with it. I also implemented linked list like structures (it was not linked list but similar). You don't need to memorize it to suceed, the construction is pretty logical.

Re: How to Interview Engineers

#224

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.

It really depends on the job. stress in general is one thing but stress on a pedestal is another. some types of people(programmers fall into this category often) are not good at embarrassment so they shut down and can't think. it's not bad because they can be brilliant without the social pressure but with that they are not ideal. if the job doesn't have that requirement it's silly to drop them for it.

Re: How to Interview Engineers

#225

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…

Realistically it's a) since everyone needs to go up to the cloud and back these days.

Re: How to Interview Engineers

#226

Where I work, we'd be totally happy to ask interviewees how to reverse a binary search tree. As soon as an actual developer creates a pull request that does as such. Which hasn't happened yet. So we don't ask about things like that. And everyone seems happier.

I don't get it. Programmers are surrounded by trees. The filesystem, your code's AST, dependency trees, the HTML DOM, any JSON ... why do people consider it so unreasonable to ask a question about simple manipulation of a well-understood tree data structure?

Unless you're writing a database or browser engine, you will never have to implement a binary tree. So it is effectively trivia knowledge. It's like asking how the x86 CPU architecture works, because it's the platform on which most code runs.

Re: How to Interview Engineers

#227
Looking for a job has become a full time job. In depth technical discussions about the technicalities, then about technical quirks, onsite visits and time spend on researching what on earth the company is doing and what their project is about, then the curse of the industry - take home assignments. Once I signed my last employment contract I said to myself "I'm exhausted, there is no way I'll move a finger during the first months of employment in this company".

Also I learned to be more picky. "Want to see my code and apps? Show me your code, show me how you work!" Eclipse required? Bad workflows with weird limitations? "This is how we do it here, it works for us" attitude? High discipline environment with daily standups? Cheapskate workplace/outsourcing center? Sorry, I'm passing.

Re: How to Interview Engineers

#228
post #216

Earlier quoted context omitted.

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.

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.

Re: How to Interview Engineers

#229
post #203

Earlier quoted context omitted.

I wonder how all those people unable to answer interview question passed school. I don't think they are fraudsters, they are simply not too good programmers who can't solve simple problems by themselves. Many dudes believe themselves to have technical talent just for memorising done basis. That does bit imply problem solving ability. Momentary blackouts happen - rarely.

I've had it happen - just in my past job search the past few weeks, I had a total blankout in my last Google interview session in person on a dynamic programming question, and I'm pretty sure that ended up being the reason why I got rejected as I felt pretty good about all 4 of my prior sessions. I am about to start work as a senior engineer for Apple with 4 1/2 years of experience, after passing two back-to-back ons…

I know it happens, but I don't think it happens to majority of people. Bad days are caled that way because they happen once in a while, not constantly. You had good three interviews and one bad at Google. You passed well at apple. That really sounds like bad day.

But then there are people for who practicaly any question beyond "lets talk in general about what you like and how passionate for technology you are" is unfair and causes black out entry single time. Thay is entirely different.

Re: How to Interview Engineers

#230

Earlier quoted context omitted.

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.

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 craftsmanship of the bookshelf, because he's built many excellent bookshelves to industry standard effectiveness in the past and measuring the number of screws he can turn in a second hasn't been relevant to the work.

Post reply on HN