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

381–390 of 489 posts

Re: How to Interview Engineers

#381

Post by Terr_ »

kevhito wrote: post #265
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.

No. Here are possible carpenter equivalents, all of which I'd absolutely consider a minimum low bar... > How many nails does it take to build a house? a) hundreds b) thousands c) millions d) billions > How many rooms are in a house? a) tens b) hundreds c) thousands > How thick is a house wall? a) inches b) feet c) miles

Number of nails as analogy for CPU operations? That's not hiring a programmer, that's hiring a computer.

What I mean is that -- thanks to all the programmers of yesteryear -- most programmers operate at a much higher level of abstraction when building anything that big.

Re: How to Interview Engineers

#382

Post by bogomipz »

padobson wrote: post #329
bogomipz wrote: post #122

Earlier quoted context omitted.

>"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." Can you break down how much time you spent on each of those tasks that they took up the equivalent of an entire 8 or 9 hour work day 5 days a week? I think you might be in the minority with your outlook. Most people…

Sure, here's an approximate breakdown: Morning: 1-2 hours: Study a chapter of CLRS Algos book 1-2 hours: HackerRank 1-2 hours: Studying trivia of technology X Afternoon was all about sales - updating social networks, filling out applications, talking to recruiters on the phone, scheduling interviews, etc. I probably applied to about 250-300 companies. I made tweaks as I went - I found that recruiters preferred to tal…

>" I started to sniff out which companies were serious about hiring and which perpetually advertise for talent"

Would you be able to share how you sniffed them out or what techniques worked for you?

In my opinion this is one of the largest time sinks. Companies that aren't really hiring.

I see this repeatedly on the HN "Who's Hiring" thread. Companies just perpetually advertise the same roles and very often these are the same companies who seem to have no problem wasting other's people time with flakey recruiters or ghosting or just never responding to candidates. I would love to know if there is a commonality you found?

I also wish there were a better way to share experiences regarding these perpetual time wasters, something akin to hosts respond percentage on AirBnB. And I personally don't consider Glassdoor to be a very good experience or trustworthy outlet.

We often hear about the shortage of talent. And while I don't doubt there is an amount of shortage, I am often left wondering what percentage of this are companies completely broken hiring process. I also wonder whether these companies are even aware of how broken their process and their recruiters are.

Re: How to Interview Engineers

#383

Post by 0xbear »

pogaxvr wrote: post #330
detaro wrote: post #312

Earlier quoted context omitted.

And low Mhz range is in the millions, which they said they would accept as an answer with that explanation.

Clock rate != operations. It's like you didn't bother to read what I wrote.

The worst thing you realistically can do to stall your CPU is miss cache every time you read data from RAM. If you do this for every instruction (which would be quite a feat in itself), you divide your instruction throughput by about 200. But even then, and even on the shittiest modern CPU you'll be retiring millions of instructions per second.

Re: How to Interview Engineers

#384

Post by sqeaky »

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…

You say we need to figure a few basic things out, how do we do if a person has basic confidence if not by asking them questions.

Please keep in mind that resumes nor any other data from the candidate can be trusted, because a huge amount of candidates lie or are mistaken about their own skill. I once interviewed a candidate who claimed to have 10 years of SQL experience but couldn't write a query on the order of "select * from table_name". Fully half of all people I have interviewed failed to convince me they could write anything more complex than "Hello World".

I am not advocating hours and hours of needless hoops, but a candidate for just a about any programming job should be able to Write a working fizzbuzz implementation. Questions on the order of fizzbuzz can and do eliminate a huge number of possible candidates.

Re: How to Interview Engineers

#385

Post by restalis »

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.

The question may be to asses tech-savvy-ness of the candidate (i.e. if he/she knows the SI prefixes, what the range of the modern CPU frequencies is and how do those values reflect on computing performance). There is one kind of programmers that learned their trade just to make a buck and don't care much about their working tools, and there is another kind that finds interest in computers in general. Interviewers may prefer the second kind.

Re: How to Interview Engineers

#386

Post by cl0wnshoes »

ubernostrum wrote: post #375
cl0wnshoes wrote: post #364

Earlier quoted context omitted.

That's what I keep questioning and why I've tried various methods. After screening resumes along with coworkers, at various companies I've worked at, we'll pre-screen or not, bring them in and ask them questions from their resume. Resume says 'I'm an expert in SQL'. Great, lets start some every day foundational questions. What is the difference between an inner join and an outer join. Why might we use a varchar inste…

So let me ask you an "easy" question: for your interview questions, are you consistent in what you ask, and do you have a consistent approach to evaluating a candidate's response? I ask this because some of your "foundational" questions are not as simple as you might think (I could talk for literally hours about XSS and the only conclusion I could give you would be "there's no sure-fire way to prevent it", for exampl…

I try to be consistent with my questions, but it depends on how well the candidate is answering them as to the depth I go into a subject. Generally I ask the candidates about previous projects and work my questions into the conversations. It usually isn't a rapid fire pop-quiz type interview.

Tell me about a project you had the most fun working on. You tell me you started working on a SPA in Angular 2 and I ask if you've heard of some common attacks like XSS or CSRF. You say yes to both and I ask if you had any preventive measures in place or how you would go about trying to prevent them (I'd stop you if you kept going on and on). We'll work our way through the projects stack best we can in the same manner.

We generally used recruiters at all the companies I worked at due to lack of applications. I agree they're part of the issue. I also phone screen for recruiters so at least some of them are doing their due diligence (no idea how they act on my reviews though).

Re: How to Interview Engineers

#387

Post by kbsletten »

pc86 wrote: post #275
missblit wrote: post #201

Earlier quoted context omitted.

It's all fun and games until one of your appointmets is specified in rfc2550 format, and the meeting room is on a big ship crossing the international date line on the same day daylight savings time changes for the ship's country while a new timezone is voted into effect. Meanwhile the other meeting room is a videoconfrerence between the international space station and a ship travelling at close to the speed of light,…

Also the meetings are in different rooms with entirely different attendee lists, so whether they conflict or not is irrelevant.

Unless there is some other mutable state that they both interact with that may cause a race condition. :)

Re: How to Interview Engineers

#388

Post by InitialLastName »

sqeaky wrote: post #349
abramz wrote: post #343

Earlier quoted context omitted.

I don't put out fires under the watchful eye of a would be colleague or employer.

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.

Re: How to Interview Engineers

#389

Post by nsxwolf »

lopatin wrote: post #366
nsxwolf wrote: post #346

Earlier quoted context omitted.

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!"

The interview question I was referring to is the appointment overlapping one. It's a middle school math question and it's a lot easier than failing over a database without data loss.

I've been doing this for 20 years and I'm not even sure where I'd start on your middle school math question. I hate working with calendars and dates and I don't think I know anyone who enjoys it and can write totally bug free code that takes care of all edge cases.

I'm sure good at fighting database fires though.

This probably is at the heart of the answer to the question "how could this programmer with such a long resume have botched this interview so badly?" It would be insane to believe they've never added value to any organization and have just been coasting along all this time. Maybe your interview sucks and isn't good at finding value.

Re: How to Interview Engineers

#390

Post by restalis »

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…

I've taken recently a row of interviews. I've had my first whiteboard exercise and it wasn't as bad as I've expected to be. It actually proved to be very useful, as I could abstract away details that I otherwise had to deal with if I had to implement the solutions on a computer. I've also had those five interviewers on the other side of the desk! It was pretty funny for me, but I concede it may have been stressful for somebody else.
Post reply on HN