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

211–220 of 489 posts

Re: How to Interview Engineers

#211

Post by watwut »

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…

Making sense of his codebase is harder then writing from scratch. Maintenance programmIng requires a lot of puzzle solving. What it does not require is modern technology. E.g. maintenance programmer should answer this question easily and have problem it you ask about react.

You don't want to work with people who can't solve trivia like this. Something like man in the middle can be learned, basic problem solving takes time to develop.

Re: How to Interview Engineers

#212

Post by jrowley »

watwut wrote: post #205
lomereiter wrote: post #187

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.

When youre writing a complex SPA app and your performance is dragging on that cheap Android, it's nice to be able to reason about things like clock speed, memory usage, etc.

Re: How to Interview Engineers

#213

Post by [deleted] »

cyrux004 wrote: post #197
notadoc wrote: post #157

My own 2 cents for interviewing, for engineers and most other vaguely technical positions but perhaps broadly applicable: - Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity - Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview - Don't ask time-wasting stupid questions about manhole covers, boiling bagels…

Can you expand on the boiling bagels on mars question ? Havent heard of that before

[deleted]

Re: How to Interview Engineers

#214

Post by patrec »

fghvbnvbnfe wrote: post #196
mikebenfield wrote: post #189

Earlier quoted context omitted.

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

I agree that it is "useless trivia." The reason is that things today are "fast enough." These days most slowdowns aren't the result of the CPU not executing instructions fast enough. Other factors dominate, such as memory access patterns, network delays, and interfacing with other complex software such as databases. Unless you are doing compute-heavy code, the speed of the CPU isn't much of a factor in estimating how…

I'm not infrequently surprised how people don't spot that something is orders of magnitude slower than it should be or pick the wrong architecture because they can't or won't do simple mental math to work out very roughly how long it should take to move some data around in memory, ssd or over the network or perform some simple computation on it.

I'm having trouble believing that people who think a CPU can do thousands of instructions per second will do well at this (or reasoning about the memory hierarchy).

Re: How to Interview Engineers

#215

Post by Steeeve »

I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employment tasks.

It seems to me like an enormous amount of time wasted for both interviewers and interviewees.

When considering someone for a development/engineering role there are a few basic questions to figure out:

1. Does this person have competence within our technology stack?

2. Can this person communicate clearly?

3. Is this person productive/can this person be productive in our environment?

4. Does this person have characteristics that will allow them to succeed in our environment?

Making people jump through hoops like some sort of dancing monkey while they are on a job hunt is needlessly cruel and is a waste of everybody's time.

If you regularly see people who can't succeed with what you consider basic engineering questions, you either have a recruiting problem or you yourself have a communication problem.

If you expect an interview candidate to expend 8 hours or more working on interview tasks, you should be presenting a unique enough opportunity to justify it.

If you expect an interview candidate to whiteboard a solution to a coding problem that they received in the room, that should be part of your everyday work experience and you should go through the process yourself in front of them so that they have an understanding of what your expectations are.

If you want to review their code and talk with them about it to determine competency, provide an example of your own code and a set of questions and answers that would be successful.

Don't put engineers through a gauntlet of challenges that you would have trouble successfully navigating under the pressure of feeding your own family. They have more than one company they are interviewing with and each company has their own focus. Put them in a position to succeed and give them the chance to do so. That's what you want out of your own people - the ability to succeed given a reasonable amount of guidance and clear parameters for success. If you can't provide the guidance or the parameters for success for an interview, how can anyone expect to succeed in your actual working environment?

Re: How to Interview Engineers

#216

Post by 0xbear »

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.

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

Re: How to Interview Engineers

#217

Post by ryandrake »

bogomipz wrote: post #204
ryandrake wrote: post #198

Earlier quoted context omitted.

Let me try to answer: Say you plan to interview at Apple, Facebook, Dropbox, and Stripe. Lets say each company requires 2 rounds of interviews. Without these guys, you're doing two rounds at each company = 8 interviews. With these guys, you do one round with them, and one round with each of the companies = 5 interviews. If that's how Triplebyte works, it would be a huge time saver.

Does every engineer unquestionably want to work for any and all 4 of those companies? Aren't these very different companies? Is there any significant commonality here other than Tripplebyte has some connection at all of these?

Pick N other companies, then. As long as TripleByte has this kind of relationship with at least 2 of them, it's a time saver. I could easily see myself interviewing for 20 companies in a single job search. Needing only one "pre-screen" for all of them would be nothing short of miraculous.

Re: How to Interview Engineers

#218

Post by watwut »

cookiecaper wrote: post #137
watwut wrote: post #60

Earlier quoted context omitted.

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

Guess I Am lucky that I meet good programmers who were not above theory and continually keep themselves informed. Contrary to what you write, there is no dichotomy between the two and your coding skills are not harmed by learning theory or keeping interest in it.

I also think that if knowing something harms me in the eyes of the company, then I do not want to work there. Such environment must be demotivating for learning. And i need to continuously learn. It is ok if they don't care and it is awesome if they are interested in different things that me (I can learn from them). Especially if we are talking about small companies where people who interview you reflect wider culture. Working in environment where people sort of punish you for knowing things they don't know is road to mediocrity. I want to work with collegues that will motivate me to learn - that is super important in length term.

So that leaves 85% of companies where I can talk about theory and not be harmed at all.

Re: How to Interview Engineers

#219

Post by Loomie »

watwut wrote: post #203
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…

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.

When people are actively watching me to judge me, my brain just goes blank. It's happened to me almost every time in technical interviews where I was asked to solve a problem in front of the interviewers, and it's happened to me at school too in oral examinations. Written exams were not a problem.

This never happens in normal work, even when working under pressure with a deadline that has to be met and not enough time to make it.

It's just a completely different setting and purpose. In one case I'm solving a problem for the sake of being judged and that judgement may impact my whole life for the coming years. In the other case I'm solving a problem because there is a practical need for it and I'm just doing my job.

It has nothing to do with being a good programmer or not, it has nothing to do with my actual ability to solve a problem either.

Re: How to Interview Engineers

#220

Post by nice_byte »

mikebenfield wrote: post #189
symlinkk wrote: post #180

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.

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

I see your point, but hardly anyone counts "operations" anymore. Besides, what even is an "operation" on a modern CPU? You could say, an operation is an entire CPU instruction, but the truth is that the instructions you see in assembly files are not really that atomic. So then do you count each microcode instruction as an "operation"? But even then the question is impossible to answer, because depending on the type of workload your execution time will vary significantly. For example, straight up doing math with some registers will always be faster than reading/writing memory, and reading memory in a cache-friendly way will be faster than jumping all over the place, etc.

Anyway, my answer to the question would be, "a lot". You need to know the specifics of workload and cpu to be more precise.

Post reply on HN