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

361–370 of 489 posts

Re: How to Interview Engineers

#361

Post by sqeaky »

pc86 wrote: post #279
alexashka wrote: post #132

Earlier quoted context omitted.

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…

TIL building products that make money (as opposed to pre-revenue VC-funded CRUD apps) with a team that enjoys their job and can be home by 4 every day is not "real development."

Not all teams that do what you suggest write garbage code as the GP implied. I have worked a places with large garbage and excellent code bases.

The places that have garbage and years of technical expect far less from their devs because they can get far less. These are also the places that prevent tickets for refactoring and never let devs pay down technical debt, then they get mad when development is slow. They value the next piece of "functionality", even if it as simple as new entry in a menu more than they value their future. When there is so much technical debt that adding that menu entry takes a skilled developer 60 hours this becomes the norm instead of a problem to solve as a business.

I would rather not hire a developer familiar with such situations and failing to fix them. Whether the failure was their ability to recognize or communicate the problem doesn't matter the problem existed and they were near it and it wasn't fixed. If I start having those problems I want people who aggressively deal with technical problems in my technical positions.

I can of course be persuaded to hire such a person if they explain what they did and they seem highly competent. Perhaps, they did do all the right things, did go above and beyond and the culture was still so toxic as to prevent progress, I have been there before. But the interviewer would need to convince me and I think that is the point of an interview.

Re: How to Interview Engineers

#362

Post by JoeAltmaier »

vorpalhex wrote: post #351
JoeAltmaier wrote: post #306

Earlier quoted context omitted.

I don't see a connection between pay and the interview process. Should the company also make their chairs one-third the height? Have one third the whiteboard marker colors? Feed you one-third of a lunch?

My willingness to jump through hoops is proportionate to how much I want to work with you. If you pay me well and treat me well, I want to work with you. If you're trying to hire me for 50% of market, my tolerance is much lower.

Then the filter would be "The skills of a Google Engineer, but can't get in there so might work here". All others need not apply?

Re: How to Interview Engineers

#363

Post by Ntrails »

alexashka wrote: post #350
dsacco wrote: post #299

Earlier quoted context omitted.

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…

Let me ask: what company do you work for and how much effort does it put into finding, attracting and most important! retaining! people who are any good? How much say do the people working on a team have, in who gets hired? I mean people who'll actually be working with the person day to day, not some manager. If the answer is 'we tell recruiting agencies we're hiring for vague role X, Y and Z', then why are you surpr…

Attracting more good people won't reduce the number of bad applicants (it will increase it).

Retaining staff doesn't mean that you aren't hiring at .2 headcount per annum.

Assuming that there's a basic process of CV review (by team members who would work with) followed by non technical phone interview. You will still have people who fail fizzbuzz. I'm not talking about small errors reading the problem - but the inability to even put a for loop in pseudo code onto the page.

The fact that the test is required is somewhat silly - but it's hardly limited to dull corporate roles.

Re: How to Interview Engineers

#364

Post by cl0wnshoes »

ubernostrum wrote: post #357
cl0wnshoes wrote: post #319

I've performed interviews and phone screens for years and out of all the techniques I've tried all of them typically end up with me thinking I'm doing it wrong. Basic domain questions, problem solving, white boarding, white boarding along side the person helping them out, coding in an IDE, take home projects. As of today, in Kansas City, I'm looking at around 4% pass rate, and close to 90% utter face palming failures…

You know the quote: if you encounter an asshole first thing in the morning, you encountered an asshole. If you encounter assholes constantly all day long, it's probable you're the one who's the asshole. If you have a 90% rate of "utter face palming failures", the problem isn't with the people you're interviewing, it's with the interviewer and/or the interviewing process.

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 instead of a char data type? Why do we use indexes? What is the purpose of a foreign key? A good majority of the candidates can only answer the join question.

'10 years experience, senior dev in ' can you write a function that returns the largest number in an unsorted array? Most struggle to even pseudo code it. Tell me something, anything about interfaces. Basic security question on SQL injection/xss/csrf/hashing/encryption. Without a doubt most have only heard of SQL injection and then they get that wrong. Most say hashing and encryption are the same thing.

I do blame myself, the failure rates are incredibly high. But when resumes looks great and onsite can't pseudo code a simple loop, or answer basic questions about something they claim expertise in, what can you do? Require and call references to make sure the the lead dev with 12 years experience and decent companies isn't lying? Because the result of most of my interviews appears that people inflate their resumes and flat out lie.

Re: How to Interview Engineers

#365

Post by crdoconnor »

Jach wrote: post #324
crdoconnor wrote: post #261

Earlier quoted context omitted.

I gave up on those the last time I wasted 4 hours of my life on one of those tests and never even got a rejection email. It wasn't a hard test and I didn't do badly. Nowadays I just point them at my github. If a body of open source isn't enough to get an interview I'm not interested in working there.

Are you against coding tests in general (especially when you have open source work to point to) or just as a prerequisite to speaking with someone?

Just as a prerequisite.

Re: How to Interview Engineers

#366

Post by lopatin »

nsxwolf wrote: post #346
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.

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.

Re: How to Interview Engineers

#367

Post by deathanatos »

rpeden wrote: post #284
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…

A decently clever candidate could sneak out of that first one without a loop. Something like numbers.reduce((a,b) => Math.min(a,b)) would do it in JavaScript. In general, if a candidate realizes they can use reduce for that purpose, in my experience interviewing candidates they probably wouldn't have much trouble doing it with a loop, and it would usually be a signal they're going to have a pretty good interview. The…

As of yet, nobody has used reduce(). If they did, and especially if they followed it with a coherent explanation of what reduce does & how it worked (and convinced me they've not memorized reduce for a singular purpose, but understand it well enough to apply it generally), I'd definitely accept it.

If they can also write, or at least quickly approximate, the for-loop solution too, then I'd say I've gotten an excellent signal: not only can the candidate write a for loop, but he or she might also have some experience with a functional paradigm from somewhere.

Re: How to Interview Engineers

#368

Post by pragmaddux »

gilbetron wrote: post #335
rasen58 wrote: post #181

Earlier quoted context omitted.

I feel like that's a bad question to ask. An algorithm question at least lets you attempt it and you can see if they know things. But this question isn't something that people normally talk about or think about. I think older engineers would think this is a normal question to ask since they/you have seen the evolution of computers over time, and have actually seen the number of operations changing to get into the bil…

So you would be completely comfortable interviewing someone that claimed to have done 10 years of systems programming, including optimization, and yet when asked that question, just shrugged their shoulders and said, "I dunno"? Even if you asked them how fast a modern processor was and they still said, "I dunno"?

In your scenario, the question makes sense.

Personally, the question reads like "have you ever pieced-together a computer?" and one could argue that the question could weed out better candidates for certain positions. A growing number of younger engineers have only used machines that come glued-together, and never had to compare performance vs. price as they chose a CPU.`

Re: How to Interview Engineers

#369

Post by bogomipz »

crdoconnor wrote: post #261
yetihehe wrote: post #232

Earlier quoted context omitted.

And for me that was a perfect interview. First quick question by email to see if I was interested, then some simple test to see if I can really program, then quick interview to see if I have required domain knowledge (all questions were about knowledge required to program effectively, not abstract "how to move mount fuji"). For an introvert programmer like me it's a perfect interview schedule. Also it helps when you…

I gave up on those the last time I wasted 4 hours of my life on one of those tests and never even got a rejection email. It wasn't a hard test and I didn't do badly. Nowadays I just point them at my github. If a body of open source isn't enough to get an interview I'm not interested in working there.

Agreed. My experience is that recruiters are pretty flakey people(and I'm being charitable in that) - they regularly fail to keep scheduled calls, fail to follow up after asking you for some times to chat, take weeks or even months to respond resume submissions for jobs they are posting etc.

I have no problem with competency testing provided I have already spoken to someone on the team and established contact and registered interest with someone besides a recruiter.

Re: How to Interview Engineers

#370

Post by poikniok »

marcuslager wrote: post #270
venture_lol wrote: post #104

Earlier quoted context omitted.

If the candidate starts by drawing 2 lines, then marking start and end on the lines, you know you would be off to having a good chat

To have a good chat I would hope they drew a coordinate system, mapped both appointments in Euclidian space, and then did an intersect between vector A (first appointment) and vector B (second appointment) to see if there are any data points in common.

What does this mean?
Post reply on HN