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

291–300 of 489 posts

Re: How to Interview Engineers

#291

Post by crispyambulance »

arethuza wrote: post #240
lopatin wrote: post #166

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.

"time matters and you have to think on your feet" I've been in many stressful situations at work - none of them involved finding algorithmic solutions.

I once spent 2 days troubleshooting a machine vision system at bolt factory. Physically in the factory. On my feet. Standing behind an active vibratory hopper filled with bolts, while stake-holders were losing money hand-over-fist, and angry machinists who looked like a motorcycle gang stood next to me. And it was a Windows NT machine.

Not quite all about algorithms, but that was part of it :-)

Re: How to Interview Engineers

#292

Post by pogaxvr »

supran wrote: post #66
padobson wrote: post #36

Earlier quoted context omitted.

When did you last switch jobs? I recently went through a round of employment where I quit my job at the beginning. Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job. I can't imagine finding a new programming job while still working at the old job.

I've done this for nearly every job in the past. However, since moving to the Bay Area, I would never consider quitting my job just to look for another. As one commenter below said, you put yourself at a disadvantage when you're bargaining for compensation. I can agree that it's pretty difficult to find a new job while still working. However, most companies let you work from home nowadays. You can just interview duri…

However, most companies let you work from home nowadays.

I don't think that's even slightly true.

Re: How to Interview Engineers

#293

Post by [deleted] »

_ptgt wrote: post #144
mattnewton wrote: post #55

Earlier quoted context omitted.

I think this is a crazy expectation. I last switched jobs while working at Apple last October. Having the BATNA of your current employment is crucial to the negotiation process and I can't imagine forgoing that- if you have no current income that's an insane bargaining handicap. Anyone with experience absolutely is not going to go for "quit your job, and maybe we'll give you a new one after a week, maybe it won't wor…

Why would it be a bargaining handicap unless you're running out of money (i.e. desperate)? If you're a strong enough candidate to land an offer at a top firm, it isn't worth it for them to low-ball you and risk spending more resources looking for strong candidates. Besides, if you can get an offer at Company X, you can probably get an offer at one of their competitors as well (which is your leverage).

[deleted]

Re: How to Interview Engineers

#294

Post by quadcore »

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…

One question Ive been asked I really like is: write a program that print the odd numbers between 0 to 100.

Re: How to Interview Engineers

#295

Post by djb_hackernews »

bogomipz wrote: post #125
zippergz wrote: post #111

Earlier quoted context omitted.

I don't think "the final interview" means a single person. I took it to mean the onsite round, with however many people that entails, skipping the recruiter screen, phone screen, etc.

So why does it matter whether the first round of interviews is done by this company or the actual company doing the hiring? I would argue that as a candidate I would rather interview with as many of my potential coworkers as possible. Interviewing is a two way street. The more exposure to the actual people I would be working with allows me to make a better-informed decision. How is reducing my exposure better for me…

I'm with you on this. Of all of the teams at Apple/Facebook/Stripe etc I can guarantee there are at least 25% I would not want to be on, 30% I might not want to be on, 30% I might want to be on and 15% I would definitely want to be on.

So now I need to start from scratch to get all of the information I'd need to make the decision of what position I am interviewing for fits. What makes this doubly difficult is I've been "fast tracked" to the interview process where those discussions aren't expected.

The more I read about triplebyte the more I think their heart is in the right place but they are creating a market for lemons.

If triplebyte can create a system where the final interview is a cultural fit interview of no more than 2 hours and both sides feel they have enough information to proceed, then they are onto something.

Re: How to Interview Engineers

#296

Post by vonmoltke »

saw-lau wrote: post #290
deathanatos wrote: post #167

Earlier quoted context omitted.

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…

The whole for loop thing - absolutely! We used to ask people to right a function in C that converts an array of doubles from degrees to radians. It was amazing how many people had no idea and who had sailed through CV/resume screening, telephone interview, and 'technical discussion' part of the interview with ease.

If those people really "sailed" through your phone interview and technical discussion there is something very wrong with your phone interview format and technical discussion methods.

Re: How to Interview Engineers

#297

Post by roflc0ptic »

kafkaesq wrote: post #158
weaksauce wrote: post #138

Earlier quoted context omitted.

I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?

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…

>> "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 not a given, tho, that being able to talk about thinking is distinct from being able to think and being able to talk.

Re: How to Interview Engineers

#298

Post by vonmoltke »

pc86 wrote: post #277
ben_jones wrote: post #83

Earlier quoted context omitted.

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…

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

It's also a problem when those same companies want to bitch and whine about a "talent shortage" or a lack of diverse candidates.

Re: How to Interview Engineers

#299

Post by dsacco »

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 used to disbelieve hiring managers regularly encountered candidates who actually couldn't code, or whatever other basic technical thing was reported on their resumes. Such a possibility - even the audacity of it on a conceptual level - simply seemed beyond the pale for me. I had interviewed before and not done well, and that I could absolutely understand. But I had no way of relating to the idea of someone entering an interview without the fundamental mental schema requisite for doing the job.

Then I started interviewing people for engineering and security engineering roles. That's when I realized that unless you put a lot of effort into curating your candidate pipeline, you interview engineers who literally (without exaggeration!) cannot complete anagram toy programming questions in their "favorite languages." That was a sobering moment for me.

I'm in agreement that a lot of tech hiring is suboptimal, selects for noisy heuristics and is even (sometimes) sadistic. But I've also met engineers - typically people who have not done interviewing or hiring much - who think that reports of fizzbuzz failures have been greatly exaggerated. They have not been exaggerated.

I haven't interviewed anyone in over a year, but back when I was doing it weekly I used to mentally sigh with relief when the candidate I was talking to could actually approach technical questions, even if they ultimately didn't give winning answers. It is a sad reality indeed; the bar is low enough that you have an edge by merely engaging with the problem and reasoning about it with technical competence in an interview.

Re: How to Interview Engineers

#300

Post by kulu2002 »

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.

Such kind of situations are very common where you are relatively new, handling software for a safety critical system and entire production line is shut down due to some exception occurring in large complex hard-real time multithreaded s/w module developed by some past ghost employee who has forgot to comment the code with no documentation available and the plant manager is banging your head for downtime loss!
Post reply on HN