Live data from Hacker News

How to Interview Engineers

blog.triplebyte.com

431–440 of 489 posts

Re: How to Interview Engineers

#431

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.

The stressful situations tend to be things like "We just broke the production database, we need to figure out how to recover the data ASAP"... not "We need a new algorithm in FIVE MINUTES!"

>We just broke the production database, we need to figure out how to recover the data ASAP

I know you did not mean it this way, but in some ways that's even worse. If that type of thing were routine enough to merit asking every interviewee that question, I would seriously reconsider working there.

Re: How to Interview Engineers

#432
post #417

Earlier quoted context omitted.

Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them. Apparently some people take whatever warm body shows up.

> Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them. It would only be valid not to hire them if they have already taken measurements and noted them down. If they can't do…

And because of that the kinds of answer we would expect from such a carpenter in that situation is, "Hmm ... how big is the room and what size of board are you using? 2 inch, 3 inch, 5 inch, or so mix? That's pretty popular these days. How much extra do you want - I usually recommend 15% so you have some in case you need to repair."

Likewise, for the original question, I'd expect some sort of discussion or nuanced answer. Something like, "Well, most modern CPUs are rated at the GHz, so on the basic level, we can say on the order of billions of operations - but we're getting a lot more cores, and given SIMD and such, you could actually go an order of magnitude or two over that, in theory. But if you are doing something that takes lots of clock cycles, it could drop down into 100s of millions, I suppose."

What you don't want to hear is a deranged ranting, like some people are doing in this very thread, or "I dunno" and a blank stare.

Re: How to Interview Engineers

#433
post #59
post #5

"15% dislike academic CS (and think that talking about CS is a sign that a candidate will not be productive)" That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.

I have a CS degree from CMU, and I've only run into that sort of attitude once. The interviewer nit-picked my solution to some character array manipulation question. I didn't get an offer. The interviewer wrote some snarky comment on his Twitter the day after my interview; something about "the difference between a computer scientist and engineer". Six months later his company was bought and chopped up. He got laid of…

I'm not sure I'd want to work at a place that was hiring me based on just the school I went to. Similarly, I don't want to work at places that screen on irrelevant "CS fundamentals", because some of my favorite developers to work with would never be hired there.

Re: How to Interview Engineers

#434
post #151

Sometimes I ask candidates to come up with a question for the interview, something that would allow them to put their best foot forward. Any thoughts on that?

The question is really under-constrained and it's not clear what you are trying to figure out.

I ask things like, "what's the most interesting bug you've encountered?" or "what have you been excited about learning recently?" to try to find a topic we can have a conversation about in a domain they are familiar with and interested in.

Re: How to Interview Engineers

#435

One thing I find interesting is the absolute conviction that every interviewer has that they got it right when the reject a candidate. No "reject" decision can ever be reconsidered or questioned by anyone, ever.

If I were in charge of a giant company I'd hire every 50,000th applicant or whatever, just so we had a control to see if our interview process was worth the time.

Re: How to Interview Engineers

#436
post #159

Earlier quoted context omitted.

I highly doubt I would ask if the inputs are sorted. I wouldn't expect them to be (why would they be, after all?), and I'd probably just give a solution that works regardless.

I think you just received some good interview advice, unintentionally.

Not for interviewing for a company with reasonable interview practices.

Re: How to Interview Engineers

#437
post #251
post #103

Earlier quoted context omitted.

So, we've gathered data on exactly these points over the last 2 years. And what we've found that the decision that gets the best signal is often not what feels most accurate to the interviewer. For example, my guess before running these experiments would have been that simply looking at progress (how far a candidate gets through a problem) would be a bad measure of interview performance. I'd expect that things like s…

Have you tried IQ testing instead of algorithm questions to measure intelligence?

There is no such thing as a single "intelligence". "IQ" is measuring at least three different forms of cognitive ability, is an inherently flawed and culturally biased tool and may be illegal to administer unless you can prove it's relevant to the work.

Additionally, what matters is not natural talent but the set of skills and techniques an individual has built up using those talents, compensating for their weaknesses and taking advantage of their strengths. I've met plenty of very, very smart people who flounder the first time they encounter a code base they can't hold entirely in their head at once: someone who was less "smart", with a smaller working memory, but who has been developing skill with abstraction and system metaphors since CS 101 is often a better actual developer.

The myth that developers need to be "smart" is pernicious, and the cause of most of the really horrific code bases in this industry.

Re: How to Interview Engineers

#438
post #251

Earlier quoted context omitted.

Have you tried IQ testing instead of algorithm questions to measure intelligence?

There is no such thing as a single "intelligence". "IQ" is measuring at least three different forms of cognitive ability, is an inherently flawed and culturally biased tool and may be illegal to administer unless you can prove it's relevant to the work. Additionally, what matters is not natural talent but the set of skills and techniques an individual has built up using those talents, compensating for their weaknesse…

> [IQ tests] may be illegal to administer unless you can prove it's relevant to the work.

Not any more than any other means of assessment on which outcomes differ on a protected axis of discrimination like race; yes, the rule was first articulated in a case involving a fairly blatant use of IQ tests to effect racial discrimination, but it is by no means restricted to IQ tests.

Re: How to Interview Engineers

#439
post #332

Earlier quoted context omitted.

I spent a year not working and had no trouble lining up dozens of interviews when I started looking. However, it did take several months before (a) my interview game was up to par, and (b) I found a company I actually wanted to work for.

What did you do for the year off? I've always believed that tech is one of the most generous industries for this sort of "resume gap" of a year+ but if the question comes up I don't think most people would think highly of answers like "sleep" or "video games", even though more socially acceptable answers like "travel" aren't all that different... I wonder how much it varies from tech company to company. Last time I d…

Generally I told people that I had done a tiny bit of contract work (true) and had been working on my own project (somewhat true, although it never got past the conceptual stage). There were a couple other things, which I won't elaborate on for anonymity's sake, but they were not programming related at all. Even on the projects, interviewers never really dug deep into them.

I suppose sleep and videogames aren't great answers. Taking time off to travel or explore some other interest is almost certainly fine in SV.

Ultimately, I think most places are so hard up to find qualified candidates that as long as you pass the interview and don't come off as a total slacker, you're probably fine. But if you're career-minded and applying to a place that has their career tracks worked out (read, not most startups), you probably want to give that impression to your future engineering manager.

Re: How to Interview Engineers

#440
post #425

Earlier quoted context omitted.

>> "Thinking aloud" ... is a specific metacognitive skill Is there evidence for this claim? I'm inclined to believe it but that's experiential. It's also something I've never had to work to acquire, but that could be a cultural thing (my family and friends talk a lot about thinking) or a personal history thing (I have a minor learning disability, and it has forced me to develop strong, conscious meta-cognition). It's…

the idea to "think aloud" is downright silly. people who "talk to themselves" are labelled idiots. mental dialogue is supposed to be mental. call it social conditioning if you will. spelling out your thoughts for someone else to hear them just so they can take note of them for evaluation is the polar opposite of normal human interaction.

Let's just say that it's at best a corner case in the the toolbox of approaches our brain has for tackling problems. Yes, it's something we make use of once in a while. But more like a "caught you in the hall, here's my idea" approach. Never in a "solve this now in 5 minutes or yer OUT!" sense.

The problem with the modern interview process is that not only elevates the later approach way out of proportion to its actual significance -- but basically makes in the centerpiece of your interactions with the company and potential team members, on that fateful day.

Post reply on HN