How to Interview Engineers • Hacker News Board

Re: How to Interview Engineers

#411

Post by watwut » Tue, Jun 27, 2017, 8:38 PM UTC

cookiecaper wrote: post #345

watwut wrote: post #218

Earlier quoted context omitted.

Guess I Am lucky that I meet good programmers who were not above theory and continually keep themselves informed. Contrary to what you write, there is no dichotomy between the two and your coding skills are not harmed by learning theory or keeping interest in it. I also think that if knowing something harms me in the eyes of the company, then I do not want to work there. Such environment must be demotivating for lear…

You're continuing to conflate knowing theory with focusing too much on theory in the interview process. I don't think anyone begrudges candidates for knowing theory. It's when their answers are primarily theoretical instead of primarily practical that the issue comes into play.

> You're continuing to conflate knowing theory with focusing too much on theory in the interview process.

That sounds like the social skills issue. If the interviewer signals change of topic is needed and interviewee does not follow, you definitely know the person has limitation in the social skills area. Also, if the person can not talk about practical aspect, they can't.

However, "15% actively dislike overt CS discussion" does not suggest companies that merely wanted to talk about practical aspect and could not. It suggest companies that are hostile towards people who attempt to talk about theory - talk about it too much and you are primary theoretical despite being also capable practicaly.

In any case, I do not want to work somewhere where I am expected not to talk about what I know (beyond the normal "don't have long monologues they areally not interested in"). I want my collegues to talk about what they know too.

Re: How to Interview Engineers

#412

Post by alexashka » Tue, Jun 27, 2017, 8:47 PM UTC

Ntrails wrote: post #363

alexashka wrote: post #350

Earlier quoted context omitted.

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

I can think of half a dozen ways to attract applicants in a way that'd significantly increase the quality of the applicants while at the same time significantly decreasing the number of the applicants.

See, you are assuming a basic process of a job board and anyone applying for the position.

I am saying you are so entrenched in mediocrity that you can't fathom there are much better ways.

I will say this though - they all require a fundamental shift from 'fill seats with people for minimum amount of pay, to do uninteresting work, with least amount of complaining' to actually giving a shit about people you work with, yourself, and your life :)

Re: How to Interview Engineers

#413

Post by skyshaker124 » Tue, Jun 27, 2017, 8:58 PM UTC

0xffff2 wrote: post #134

As someone with an actual accredited engineering degree, I find it bizarre that Silicon Valley has decided that the term "engineer" doesn't even need to be qualified anymore. Even without getting into the flame war over whether "software engineers" are real engineers or not, there's a very large pool of engineers to which this post doesn't apply at all. I can't be the only one in the latter pool that reads HN, can I?

You're not the only one. I have a Master's and it was hard. I went for my engineering degrees after more than a decade as a technician and programmer in telecom. It's a world of difference. A cert from Microsoft or Cisco or whomever doesn't compare. We earn the title, they enjoy it.

Re: How to Interview Engineers

#414

Post by cr0sh » Tue, Jun 27, 2017, 9:02 PM UTC

qb45 wrote: post #281

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…

> But this kind of thing may only be mentioned in one sentence in an intro computer systems course, and most young people wouldn't care about how many operations a CPU can do. TBH, I'm slightly disturbed by these "young people" who have completely no idea how machines actually work. But the question is silly because there are better ways to ask people if they know in case you require that they know and you probably s…

> TBH, I'm slightly disturbed by these "young people" who have completely no idea how machines actually work.

I agree with you here, but I would like to think if I were interviewing someone and they told me such, I would then ask something like "How would you go about finding this information out?", and continue down that line (I wouldn't just accept "I'd google it", I'd want something more in depth, even though that would technically be correct).

Re: How to Interview Engineers

#415

Post by cr0sh » Tue, Jun 27, 2017, 9:13 PM UTC

pfarnsworth wrote: post #258

mikebenfield wrote: post #189

Earlier quoted context omitted.

Whether this is a good interview question I don't know, but: > When the hell would you ever need to know that? I find this such a strange perspective. You're writing code for a computer. Sometimes you need to estimate how quickly it should run, or else estimate how quickly it could run with optimal code. Surely it's obvious that knowing how fast your computer does stuff, at least within 3 orders of magnitude , is a n…

What is the clock speed of your iPhone or android phone? I personally have no idea and it's the one computer I use most frequently.

My phone, and your phone too (possibly) is something like 1.2 GHz per core, with 4 cores; most phones have a similar spec (and those numbers are going up, too); basically figure 1-2 GHz per core, with 2-4 cores generally.

That said, when I started using computers, my first machine ran at 897 Khz on an 8-bit CPU, and had 16k of RAM. I was 11 years old, and this was a pretty standard machine for the time, unless you had real money (and even there, on the top end - not counting minicomputers or mainframes - you'd be lucky to break 8 MHz and a meg of RAM).

But I know I am of a different era. And honestly, I've stopped caring about CPU speeds too, because lately they don't change much (top end is about 4-5 GHz per core; servers can have around 32 cores - though that is increasing too).

What should be cared about is memory usage per process, and how the software you are using (or which multiple people are using) delegates that out. For instance, with PHP (not sure with PHP 7) you have one process per user, and depending on how much memory those processes take, will ultimately lead to an upper limit on the number of users that can be served at one time. In that case, knowing your memory usage and constraints of the server could be very important (there are a ton of other factors to consider as well, I know).

Re: How to Interview Engineers

#416

Post by cr0sh » Tue, Jun 27, 2017, 9:15 PM UTC

fghvbnvbnfe wrote: post #194

adrianratnapala wrote: post #186

Earlier quoted context omitted.

Well does it take about a second or about an hour to make one turn of the screw? If a carpenter doesn't know the answer to that in his bones, he won't be fastening many things together.

It takes significantly less than a second to turn a screw once. A couple orders of magnitude less actually, to give it some relation to the computer question. Which really just demonstrates the point, I think. At some point things are "fast enough" that it just doesn't matter. We've reached that point with computers. Unless you are working in a niche field that needs serious compute, the sources of performance proble…

> At some point things are "fast enough" that it just doesn't matter.

...and 640K will be enough for everyone!

Re: How to Interview Engineers

#417

Post by cr0sh » Tue, Jun 27, 2017, 9:20 PM UTC

gilbetron wrote: post #336

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.

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 the calculation to convert their measurements to square footage and then to linear feet of board (with margins to allow for different board widths) - that'd be something different.

Even there I would argue one could still say "I don't know", simply because you haven't specified how you want the flooring oriented per room/area (and if it goes on the bias, it gets tricky quick), or if there is any kind of special patterns or inlays you want, etc.

Until you have the full specification at hand, you can't really give more than a ballpark answer, which in the case of flooring calcs could be wildly off (agile doesn't really work for real-world engineering like it can for software).

Re: How to Interview Engineers

#418

Post by nsxwolf » Tue, Jun 27, 2017, 9:21 PM UTC

cr0sh wrote: post #406

nsxwolf wrote: post #347

Earlier quoted context omitted.

Most programming jobs do not actually demand one make this form of Sophie's Choice. Perhaps the Valley is so diseased, but it's not the only game in town.

> Perhaps the Valley is so diseased, but it's not the only game in town. Hear! Hear! One of the things that bothers me a lot about HN is the near assumption that if you're a software engineer and not in SV (or have never been in an SE job in SV) - you don't count as much. I'm biased, I will admit: I've never held a software engineering job in the Valley. That opportunity has never occurred, nor have I tried to pursue…

And now imagine you have 4 little kids like me and how that affects the equation! You want me to move out to Seattle, Amazon? Do you have any idea how much you'd have to pay me to have anything like the lifestyle we have in the Chicago suburbs?!

The attitude out west is "You want to earn enough to raise a family? You should have thought about that before you had kids".

It also seems to me that the people who have the most trouble with work/life balance in development jobs, at least out here, is that they are too afraid of saying "no".

Re: How to Interview Engineers

#419

Post by cr0sh » Tue, Jun 27, 2017, 9:28 PM UTC

Yizahi wrote: post #271

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.

When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure. (1) because "it is faster" and "my dad always did this" and "you don't pay for my saw, so shut up"

> When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.

They do make such blades for angle grinders; they tend to be "universal" blades to cut wood, metal, and ceramic/brick. There are also "chain" blades, which are meant for high-speed carving of wood (they look like a chainsaw chain wrapped around a circular blade).

Likely, if you really wanted to do it and had nothing else handy, a cutoff blade would probably cut wood just fine (take care to watch for too much friction, though). Alternatively, a circle of file folder paper chucked in would work as well.

Re: How to Interview Engineers

#420

Post by Steeeve » Tue, Jun 27, 2017, 9:43 PM UTC

sqeaky wrote: post #384

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 "sel…

> Please keep in mind that resumes nor any other data from the candidate can be trusted

That's not a problem that is unique to software, yet nobody asks directors to prove their budget forecasting skills during an interview, or has their tech writers go through the process of building automated indexes or varied pagination.

If you suspect someone can't write fizzbuzz, send them packing. Don't waste their time or yours. They've already instilled a lack of confidence which would mean that they would be facing adversity on day 1.