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

391–400 of 489 posts

Re: How to Interview Engineers

#391

Post by silverpikezero »

dsacco wrote: post #299
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…

I experienced the exact same feelings as you. Until I started interviewing candidates in quantity, I had no clue how many candidates cannot complete FizzBuzz. The reported failure rates of this simple test are completely legitimate. In my own interviewing, it comes out at about 50/50. The 50% who do pass often make some significant conceptual mistake, for which I'm generally pretty forgiving since interviews can be a stressful experience. This question comes at the end of a hiring pipeline that does 2 phone screens before the on-site happens.

Re: How to Interview Engineers

#392

Post by citizens »

altharaz wrote: post #17

At my company our engineers defined the following process. First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity. Our process goes as follows: 1. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h. 2. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Or…

How did the engineers who designed that process get hired? What was wrong with the process that landed you your existing team?

Lastly...why are the engineers coming up with the hiring process anyway? Is this common in other professions?

Re: How to Interview Engineers

#394

Post by saagarjha »

taejo wrote: post #255
saagarjha wrote: post #249

Earlier quoted context omitted.

Would you mind explaining in a bit more detail what you mean here? I'm not quite sure where you're getting those numbers from.

They mean 10^9 and 10^6, and that each "operation" in a complex algorithm is often something like a hash-table lookup, which may be constant time, but takes closer to 1000 clock cycles than 1.

Ahh, I got it. For whatever reason I didn't associate 109->10^9 and 106->10^6.

Re: How to Interview Engineers

#395

Post by gwbas1c »

danielbarla wrote: post #269
Steeeve wrote: post #215

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

The question of relevance reminds me of an anecdote. (Before that though; I tend to agree with your points.) A distant acquaintance interviewed for a secretary position. It didn't go well, because she was asked a general knowledge question (something along the lines of: "name some of the planets in the solar system"). She was furious with how irrelevant and unfair this was. It makes me wonder though, would I have hir…

One of the things I like to do is ask a factual question about a technology listed on the candidate's resume that isn't required to know in order to hack something together, but is something that "you should know" if you've been working in a particular technology for a few years.

These are part of the warm-up, I'll ask one or two right at the beginning of the interview and then move to the real questions.

Examples are: "How does the autorelease pool work?" (Objective C before everyone switched to ARC.) or "How do you ensure that an object is garbage collected," (C# and Java.)

These are more about judging a candidate's real knowledge versus stated knowledge. Someone who's spent 8 years in Objective C better know how to use the autorelease pool; and someone with at least a year of experience in a garbage collected language better know how to ensure that an object is collected.

Re: How to Interview Engineers

#396

Post by collyw »

meggar wrote: post #260
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…

Technically, all three answers are correct. (A) is correct because a modern CPU CAN perform Thousands of operations per second.

Not if it is turned off.

Re: How to Interview Engineers

#397

Post by collyw »

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…

Thats actually a really interesting way of interviewing, and probably matches the way most people have to work.

Re: How to Interview Engineers

#398

Post by collyw »

notadoc wrote: post #374
cyrux004 wrote: post #197

Earlier quoted context omitted.

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

It's just a variation on the typical logic/creative thinking questions that a lot of people and companies obsess over. "Well they're a great candidate otherwise but they totally failed the boiling water on alternate planet question, so let's keep searching" - believe it or not, that's a real mentality out there. I don't get it and never have.

Maybe its just me but I find a lot of algorithmic interview questions are just as hit and miss as these obscure questions if you need to do it in an interview.

I had a phone interview with Google and was asked to come up with a variation of a soduko solver. Couldn't get it there and then, but half an hour later walking down the road, a really elegant solution came to me.

Re: How to Interview Engineers

#399

Post by weaksauce »

InitialLastName wrote: post #388
sqeaky wrote: post #349

Earlier quoted context omitted.

Some developers are expected to work on the systems that processes a bajillion dollars of whatever per day and when it screws up they are often on the line for it. I am not saying it is right, I am just saying at some shitty places it is.

Right or wrong, in some systems when something goes wrong, somebody dies. At some point, there's somebody on the line for that, whose responsibility it is to say "This code is good enough". That's a high-pressure situation, so if you're hiring for that, it might make sense to interview under pressure.

> Right or wrong, in some systems when something goes wrong, somebody dies.

I have worked on systems that could cause operator death or disfigurement or damage... they are tested quite thoroughly in general and have reasonable failsafes and redundancy. It's not like they are coded on a whiteboard.

being on site at a customer facility while there is a ton of noise does stress you out a bit but most of the coding and testing is done in the office.

> That's a high-pressure situation, so if you're hiring for that, it might make sense to interview under pressure.

I think the jobs that have that kind of pressure are rare and interviewing like that should be the exception not the norm.

Re: How to Interview Engineers

#400

Post by collyw »

bogomipz wrote: post #130
stephenbez wrote: post #121

Earlier quoted context omitted.

Since it was in 2014 and I don't know if they still do this, I won't name them. I guess the lesson learned is to ask what the interview process looks like before getting involved. However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me, and tell me they wanted me onsite for a week.

>"However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me" This is a huge red flag in my opinion and I would recommend people not agree to this. Why? Because it shows complete disregard for the candidate. "Pass a test and you can speak to an actual human being." Its demeaning. It also shows just how useless many recruiters…

Yep, Skyscanner's HR people keep contacting me asking me to jump through hoops for them.

Initially it was a Hackerrank challenge, now its a (100% Javascript) "Full Stack" take home exercise before you even get to speak to anyone technical.

Post reply on HN