Follow-up to “The dystopian world of software engineering interviews” • Hacker News Board

Re: Follow-up to “The dystopian world of software engineering interviews”

#251

Post by ProZsolt » Sun, Feb 23, 2020, 12:27 AM UTC

karatestomp wrote: post #177

watwut wrote: post #158

Earlier quoted context omitted.

How it happened?

I tend to basically forget how to use a computer when people are watching. To prep for interviewing I also have to try to memorize a bunch of stuff about some relevant language because otherwise, without surrounding stuff to crib from, I'll straight-up forget basic shit about it, and that doesn't always stick. I'm talking like "what does method invocation look like in this language?" Under pressure it can and does ha…

That hit me where it hurts most. I sometimes forget how to declare a class or how to initialize it, because when I working just click to another file and look it up. I had an interview a few days ago where I came out as a complete moran. I did a take-home test which I was proud of. I expected we will discuss that. It was pair programming. I did some silly mistakes at the beginning and my brain shut off after ~15 minutes. In the end, they said: "We will notify you..."

Re: Follow-up to “The dystopian world of software engineering interviews”

#252

Post by hakfoo » Sun, Feb 23, 2020, 12:27 AM UTC

PragmaticPulp wrote: post #170

inertiatic wrote: post #128

I don't know, hiring seems inherently broken. Not just the algorithmic part, even the part leading up to it. You have to impress a recruiter or an HR drone by listing all the buzzwords that are currently trendy. Then, even after the algorithmic questions and interviews where you prove you can DO the job, you get rejected. Every company I've worked for had trouble hiring. I'm working for a company that also has troubl…

> I don't have a better way of doing things This is my least favorite part about discussing interview techniques. It's taboo to say anything other than "interviews are broken", as if there is some alternative perfect practice that companies are voluntarily choosing not to use. If no one, including the author of the linked article, can think of anything better, doesn't that mean that companies are already using optima…

I wonder if a sensible option might be short term contract-to-hire scenarios.

You have three promising candidates? Instead of trying to extract signal from gimmick interview tactics, hire them all and put them on a 3-month contract with the opportunity to renew to full time. Then you're giving them real weork instead of easily crammed questions, and remove some of the anxiety affecting interview performance.

Re: Follow-up to “The dystopian world of software engineering interviews”

#253

Post by ChrisMarshallNY » Sun, Feb 23, 2020, 12:28 AM UTC

achievingApathy wrote: post #248

ChrisMarshallNY wrote: post #245

Earlier quoted context omitted.

I'm not so sure about that. The lobbying for more H1Bs seems to indicate otherwise. I am quite aware that most positions are for folks that don't have my level of expertise. I just love designing and writing software; especially software that connects to devices. I'll do it; whether or not anyone pays me.

No one wants to buy the cow when they get the milk for free. :)

As long as they are happy with MIT open-source, on my terms, no big deal. They are welcome to knock themselves out.

If they want to own it, though, and have more of a say in what it does, that's another story.

Re: Follow-up to “The dystopian world of software engineering interviews”

#254

Post by klipklop » Sun, Feb 23, 2020, 12:29 AM UTC

apta wrote: post #237

klipklop wrote: post #222

Earlier quoted context omitted.

The "standardized" interview at companies like Google has lead to them hiring mostly White/Asian males though... I have had plenty of people tell me that interviewing at Google is essentially a roll of the dice these days. You can answer all the 5x interviews in a satisfactory manner and still get rejected. I feel "just wing it" can lead to somebody talented from a non-traditional background getting a chance at a gre…

> hiring mostly White/Asian males though Which seems reflective of the underlying pool of applicants.

Has a company like Google ever released data proving this? Latino's make up a fairly large number of the people that live in the bay area (23.5% [1]) yet there are like what 3.6%[2] of those people working at google. Seems like a pretty big gap.

It would be interesting to see what their application/success ratio demographics are like.

1. http://www.bayareacensus.ca.gov/bayarea.htm 2. https://www.wired.com/story/googles-employee-diversity-numbe...

Re: Follow-up to “The dystopian world of software engineering interviews”

#255

Post by karatestomp » Sun, Feb 23, 2020, 12:29 AM UTC

juped wrote: post #244

karatestomp wrote: post #177

Earlier quoted context omitted.

I tend to basically forget how to use a computer when people are watching. To prep for interviewing I also have to try to memorize a bunch of stuff about some relevant language because otherwise, without surrounding stuff to crib from, I'll straight-up forget basic shit about it, and that doesn't always stick. I'm talking like "what does method invocation look like in this language?" Under pressure it can and does ha…

This is a really common experience. Work samples were supposed to be the answer to this, though I've had really awful experiences with work-sample companies.

Luckily I've also been doing this long enough that for every one that asks for a project or wants me to live-code, there are two that chat with me for 2-4 hours and come away eager as hell to get an offer to me before I accept one somewhere else, so it's not that big a deal. I mostly just wish places were more transparent about this stuff so if they're gonna whiteboard me I could either put in some targeted prep work so I (maybe) don't look like an idiot, or else say "thanks but no thanks" and save us both some time if I can't or don't want to cram that week.

Re: Follow-up to “The dystopian world of software engineering interviews”

#256

Post by ScottFree » Sun, Feb 23, 2020, 12:38 AM UTC

biztos wrote: post #187

inertiatic wrote: post #128

I don't know, hiring seems inherently broken. Not just the algorithmic part, even the part leading up to it. You have to impress a recruiter or an HR drone by listing all the buzzwords that are currently trendy. Then, even after the algorithmic questions and interviews where you prove you can DO the job, you get rejected. Every company I've worked for had trouble hiring. I'm working for a company that also has troubl…

I worked at a company where the interview process was basically "ask them about their experience, successes, and failures, and do whatever technical screen you feel works." Other than asking about failures (not everyone does) it was just "eh, wing it, tell us what you think." The hiring manager had to then weigh the responses and convince his/her manager if it was a go (we once rejected someone on ethical grounds aft…

> we once rejected someone on ethical grounds after they passed all the interviews

What did they do? Suggest sacrificing a puppy to moloch to make a feature release go smoothly?

Re: Follow-up to “The dystopian world of software engineering interviews”

#257

Post by frosted-flakes » Sun, Feb 23, 2020, 12:38 AM UTC

hakfoo wrote: post #252

PragmaticPulp wrote: post #170

Earlier quoted context omitted.

> I don't have a better way of doing things This is my least favorite part about discussing interview techniques. It's taboo to say anything other than "interviews are broken", as if there is some alternative perfect practice that companies are voluntarily choosing not to use. If no one, including the author of the linked article, can think of anything better, doesn't that mean that companies are already using optima…

I wonder if a sensible option might be short term contract-to-hire scenarios. You have three promising candidates? Instead of trying to extract signal from gimmick interview tactics, hire them all and put them on a 3-month contract with the opportunity to renew to full time. Then you're giving them real weork instead of easily crammed questions, and remove some of the anxiety affecting interview performance.

That would make switching jobs really hard, effectively making the interview process three months long. Only now, candidates have to quit their current job before they can interview, and if the first "contract" doesn't end in a job offer, the candidate no longer has a job.

Re: Follow-up to “The dystopian world of software engineering interviews”

#258

Post by no_wizard » Sun, Feb 23, 2020, 12:43 AM UTC

JMTQp8lwXL wrote: post #209

no_wizard wrote: post #83

Earlier quoted context omitted.

In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can’t over allocate or reallocate an existing engineer for it. Like refactoring existing code. Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It’s a great way to get them familiar with the code base and train them up. I haven’t see…

Well-tested code doesn't necessarily lead to code quality. Leaky abstractions will eventually show their hand, in an environment that's not as sanitized as a unit test.

Unit test !== only type of test though.

Functional tests are a must. I would also say that in this day and age integration tests are also a must. I don’t think there is any domain now where you are commonly interfacing with only your code end to end, some level of integration is happening and that should be tested too.

Nothing’s perfect because we are human, I will say though that having proper functional, unit, and integration tests for a codebase I don’t see this issue crop often and when it does it becomes apparent, and then you write a test for that and then you have coverage for that etc.

Software is an organism composed of changing structures, after all.

Re: Follow-up to “The dystopian world of software engineering interviews”

#259

Post by joyeuse6701 » Sun, Feb 23, 2020, 12:46 AM UTC

PragmaticPulp wrote: post #183

ipnon wrote: post #66

What is tragic here is the amount of effort that is now expended by young computer scientists into the game of algorithms. Whereas a young programmer in the past may have spent their extra days writing games in Basic or static web pages, hackers these days seem to do Leetcode until the wheels come off. We are failing to bring certain softwares into existence by effectively requiring programmers to their effort into t…

> What is tragic here is the amount of effort that is now expended by young computer scientists into the game of algorithms. This is a funny topic to me. A decade ago, before Leetcode, Hackerrank, and Cracking The Coding Interview , it was common for developers to complain that software developers were losing touch with algorithmic knowledge. HN-type websites were full of discussions about clueless software engineers…

I do choose between one or the other, I do not have time to do both.

Re: Follow-up to “The dystopian world of software engineering interviews”

#260

Post by ProZsolt » Sun, Feb 23, 2020, 12:46 AM UTC

PragmaticPulp wrote: post #165

LordFast wrote: post #61

I've personally seen no correlation between people who can solve problems and program when watched by another person versus people who can solve problems and program when left alone with a real problem, and ample of time to noodle on and resolve it on their own. The same is true for writers: most are likely not to be interested and/or able to do their best work when watched over the shoulder by another person. The /r…

> I've personally seen no correlation between people who can solve problems and program when watched by another person versus people who can solve problems and program when left alone with a real problem, and ample of time to noodle on and resolve it on their own. At most of my companies, we tried moving exclusively to take-home interview problems for this reason. Short problems that could be solved in 2-4 hours of t…

Take-home test is my preferred method, but

- only after I had a face to face (can be on skype, but not on phone) interview with a hiring manager/engineer, so I know I really want to work for that company. Job ads usually not very useful determinating that (Interview should work both ways.)

- Not used as a prescreening. It should prove that I really know what I'm talking about. Otherwise, maybe I'm just wasting my time (See above)

- No more than 2-4 hour (we agree on that)

- We review my code. It's good for both of us. I get feedback, the Interview gets more inside why I did what and if I really write the code. (Optional, but prefered)