People suck at technical interviews (2014) • Hacker News Board

Re: People suck at technical interviews (2014)

#211

Post by doingmyting » Fri, Jun 10, 2016, 5:12 PM UTC

taneq wrote: post #111

MrLeftHand wrote: post #88

Earlier quoted context omitted.

Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying. The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, don…

I think the laundry list interview happens most when you're hiring to replace someone. My last job is having that issue, we were an R&D team so we learned on the job. They're having an impossible time replacing any of us because to combine that specific skill set you basically have to have been on that team (or its twin) for a couple of years. What they should be looking for is just someone with good basic skills who…

Damn, you hit the nail on the head! It's like after a divorce looking for someone exactly like your ex-wife down to the very minute detail.

Re: People suck at technical interviews (2014)

#212

Post by SilasX » Fri, Jun 10, 2016, 5:23 PM UTC

PuffinBlue wrote: post #26

There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture,…

Portfolios are a good heuristic, but you can't be sure the person actually wrote the code/took the pics, which is why you need some other way to verify they're actually capable of producing that work, not just copying it. Hence technical interviews.

Even for a programmer with a portfolio, it's vital that you be able to probe them with questions about design decisions and expose someone who didn't actually write it.

Does photography have some sort of solution to this problem? Can you ask a photographer about how they took a picture to easily reveal whether they actually took it?

I'm guessing there's less of a need to verify skill with photographers since most of the work is on a gig or piece-work basis where it's easy to terminate the relationship or refuse payment in case of obvious frauds. OTOH, what stops an unskilled from stealing a portfolio (or using with their consent) to get work? What happens if they produce usable work, but which doesn't look anything like the quality suggested like their portfolio?

Re: People suck at technical interviews (2014)

#213

Post by FussyZeus » Fri, Jun 10, 2016, 5:27 PM UTC

hanginghyena wrote: post #76

Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. En…

We do interviews in person where I ask a few basic questions and listen for the answer, then assign a somewhat complex problem to be solved in a pre-prepared iOS project. Google fully allowed. I'm not even looking for a 100% functional solution or even particularly elegant code, I want to see how a candidate reacts to pressure and how resourceful they are.

I would say the majority of our hires don't complete it and I always explain that's fine, the point is to observe the process they used to create whatever they created.

Re: People suck at technical interviews (2014)

#214

Post by brudgers » Fri, Jun 10, 2016, 5:27 PM UTC

cloakandswagger wrote: post #168

tayo42 wrote: post #167

Earlier quoted context omitted.

How would you do this without basically writing your own database from scratch?

Store it in memory? I doubt the amount of data they provided for a test problem was so tremendous that it required a database. In itself this is a good (dis)qualifier; if I give someone a problem and tell them the data will never exceed 10k rows, I expect them to be practical and not waste time setting up a database.

The flat line in the bathtub curve is where given "data will never exceed 10k rows" implies no database. On the inexperienced end, people don't understand that 10k rows doesn't require a database. On the experienced end, candidates probably oughtn't to believe it.

Re: People suck at technical interviews (2014)

#215

Post by whack » Fri, Jun 10, 2016, 5:31 PM UTC

Every time I read one of these articles, the author invariably ends up recommending solutions that have glaring holes, just as large as the ones he spends the entire time attacking.

In this case, the author begins the entire essay by telling us that we shouldn't hire on the basis of what someone already knows. One of his first solutions later presented is the exact opposite of this: find out about their level of existing knowledge, regarding specific technologies and frameworks.

He then goes on to rile against "team fit," because of its potential for bias. But his entire solution basically comes down to behavioral interviews, which are notorious for how bias-prone they are.

His solution basically tells us that we shouldn't consider fancy degrees or companies. And yet, in the span of 30-60 minutes, we should be able to form accurate judgement on how much talent and drive someone has, and what they will be able to do in the next 3 years? Sorry, but unless you're the Steve Jobs of character reading, there's no way you can do the above accurately. Everyone lies on interviews. They pad their accomplishments, and inflate what they have previously done. The only thing you achieve through such a discussion, is figuring out how good a talker someone is.

The following article sums up everything that is wrong with almost every "Hiring is Broken" critique ever. Every single approach people have ever thought up, is broken in so many ways, as ably demonstrated by many others. Unless someone has hard data to show why one technique's pros outweigh its cons, such discussions are almost always pointless.

http://www.thecaucus.net/#/content/caucus/tech_blog/684

Re: People suck at technical interviews (2014)

#216

Post by markbnj » Fri, Jun 10, 2016, 5:31 PM UTC

dragonwriter wrote: post #180

tayo42 wrote: post #167

Earlier quoted context omitted.

How would you do this without basically writing your own database from scratch?

> How would you do this without basically writing your own database from scratch? It obviously is, for a suitable loose use of the term, "writing your own database from scratch" (unless you are using an existing library, for which many languages have ones that can be leveraged in the stdlib, including often ones that bring in SQLite). But doing a database of this extremely minimal complexity, or leveraging existing l…

I absolutely agree with this. Moreover, this basic approach of giving the candidate a reasonable set of requirements, a quiet space, and as much time as necessary is hands-down the best way I can think of to asses competency. It's how I was assessed by a company at which I just accepted a SRE position. There was a homework project, a few "personality" interviews, and then a work day for which I was compensated. I was stressed out with performance anxiety leading up to this naturally, but it ended up being a blast.

I was looking for a couple of months before I went through the process with my current employer, and some of the experiences were just horrible: one company put me through 7 interviews with a single engineer each time, lasting 30-45 minutes, and then brushed me off with a two sentence email. Another wanted me to design an algorithm in 20 minutes while they watched via screen share, and if I couldn't do it in 20 minutes I wasn't good enough for them. Several asked me to take timed tests with prominent counters flashing in the corner. It's just stupid.

So I think personally we should support employers who understand how software is made, and are willing to create the right conditions for you to really practice your craft, and then judge what you've made and how you interacted with potential team mates.

Re: People suck at technical interviews (2014)

#217

Post by scottlamb » Fri, Jun 10, 2016, 5:34 PM UTC

MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

> What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code.

This could have been poor communication on their part, or it could have been a test of your communication. Was there an opportunity to ask about requirements before coding up a solution?

When I interview (usually in person), I encourage candidates to ask questions. I'd certainly never ding anyone for asking "can I use ?" but my answer might be no.

I'm not a total jerk. When I see candidates make a bad assumption, I'll try to correct them, but depending on the assumption and their communication style that might take 10+ minutes (of 45). I don't want interviews to be about speed, but losing that much time (maybe more than once!) hurts for sure. I'm probably thinking of another candidate who asked the right questions, described an efficient algorithm and its time/memory complexity, implemented it, debugged it, and moved on to something else.

Ideally, interviews are a microcosm of the job. And at least in concept, that principle holds here: on the job, people often rush the requirements and design work, which wastes much more time than it saves and/or causes the project to fail.

Re: People suck at technical interviews (2014)

#218

Post by anarazel » Fri, Jun 10, 2016, 5:40 PM UTC

kragen wrote: post #135

MrLeftHand wrote: post #88

Earlier quoted context omitted.

Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying. The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, don…

My first tech job assignment required SQL. I didn't know it, didn't claim I knew it, got the job, read the O'Reilly book on SQL on the plane on my way to California. I learned about joins (although maybe not the JOIN keyword). This was about the time MySQL came out, and years before Postgres added SQL support, so at the time your rather pathetic argument might have had merit, because there wasn't actually a way to ge…

> This was about the time MySQL came out, and years before Postgres added SQL support

Didn't those happen nearly at the same time? Postgres95 (which PostgreSQL started from) had support for some subset of SQL (including inner joins): https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f... outer joins were added a bit later: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

Re: People suck at technical interviews (2014)

#219

Post by jghn » Fri, Jun 10, 2016, 5:42 PM UTC

lmm wrote: post #189

jsudhams wrote: post #110

Earlier quoted context omitted.

Agree with you MrLefHand, But would it not be responsibility of sql programmer to keep himself update? even if it is not possible in company. Like we never get to touch AD in any company because most of them already have it setup but we still go and test in VM with eval editions and such?

Sometimes you don't know what you don't know. I was completely torn apart the first time I was interviewed for a Scala position, because the guy didn't believe I could possibly have spent three months doing Scala professionally and didn't know basic List methods like fold (we'd been avoiding using Scala collections because we knew the migration was coming, and had just been writing Scala with the Java collections).

My first scala job was with a group that didn't like to use a lot of the more FP-like constructs such as folding. So I also didn't have experience with that after three months. You could argue that meant I wasn't really using scala but I wasn't totally clueless.

Re: People suck at technical interviews (2014)

#220

Post by mknocker » Fri, Jun 10, 2016, 5:46 PM UTC

Too often, the team fit is put aside and you end up with people who does not play well with others in your team. Technical interview can be ok but I would not put too much details into it. I have been in technical interviews where people were asking questions about obscure API calls and they were expecting applicants to come up with questions that were not relevant to the job.