Live data from Hacker News

The dystopian world of software engineering interviews

jarednelsen.dev

721–730 of 851 posts

Re: The dystopian world of software engineering interviews

#721
post #485

Earlier quoted context omitted.

They probably assumed someone else did the debugging. People assume the worst in these situations because they haven’t bothered to learn about the person.

Why would they assume that?

I’m guess that’s the reason they never got back to him.

Re: The dystopian world of software engineering interviews

#722
post #701

Earlier quoted context omitted.

I remember once interviewing for a startup my friend was working at because I wanted to work with said friend. It was mainly a PHP/Laravel job, but I didn't care. I had a high opinion of said friend and stacks are just tools to me -- you can do good work in just about anything. Go in for the in-person interview which goes extremely well, but talking to their two most senior engineers it seemed like they had just rece…

" Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist." I'm pretty laid back generally and I'm willing to overlook many things, but I think this is one of those where I'd vote against hiring, since I'd never want to maintain such code. Following the logic of algorithms would be for instance really hard because of having to jump around all t…

Yes, spaghetti-code is much better! /s

> Following the logic

That's what names are for. I prefer to find _afterLeft_ spread all over the place rather than `x2This spaghetti line: `x2<=x1&&x1+w1<=x2+w2&&y2<=y1&&y1+h1<=y2+h2`, in my opinion, is much harder than `inside`.

Re: The dystopian world of software engineering interviews

#723
post #699

Earlier quoted context omitted.

Having worked on the spend side of things and at high stakes (9 figure budgets), targeting and how to improve it is extremely intellectually stimulating. More than anything else I've done in my career, even. This is especially true when you have constraints, like being in a regulated industry such as legal marketing. The only problem is that it's hard to command a salary commensurate with how good you are at it unles…

"targeting and how to improve it is extremely intellectually stimulating" I thought the answer to that was a rather bland "by gobbling up even more information about everyone"?

Not all data points are useful. Different pools have different profitability advertised in different ways.

Some highly useful data is hard to get directly or requires significant and/or stealthy spend.

Re: The dystopian world of software engineering interviews

#724
post #701

Earlier quoted context omitted.

I remember once interviewing for a startup my friend was working at because I wanted to work with said friend. It was mainly a PHP/Laravel job, but I didn't care. I had a high opinion of said friend and stacks are just tools to me -- you can do good work in just about anything. Go in for the in-person interview which goes extremely well, but talking to their two most senior engineers it seemed like they had just rece…

" Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist." I'm pretty laid back generally and I'm willing to overlook many things, but I think this is one of those where I'd vote against hiring, since I'd never want to maintain such code. Following the logic of algorithms would be for instance really hard because of having to jump around all t…

That's not how that works out in practice though. When each function does one thing, the cognitive load is low and you name things appropriately that make understanding each function on its own easy. You can scan an area of code quickly and find problems without having to build the whole house again in your brain.

It's much clearer when you hit some unintended edge case then having to maintain a mental model of a huge function doing a lot of things.

If your way of grading someone's code is to make sure you can build the whole house in your head, rather than have an exhaustive set of test cases to validate your specification and a simple "each function is appropriately named and does exactly what's intended in the correct manner", then the grading method is the problem, not the code.

Re: The dystopian world of software engineering interviews

#725
post #112

Earlier quoted context omitted.

I'm bad at taking tests. I'm also bad at playing guitar when someone is looking or even when recording myself (and pretty good when playing without anyone looking). I get anxious and self-conscious and that gets in the way of good public performance. This does not translate to public speaking - I'm pretty good at that, and I'm not afraid of audiences of just about any size - my largest so far was ~1K people. I someho…

You just described me haha. In my Google phone screen, I fumbled around on solving an easy-moderate problem - so much so that when it ended, I felt that there was no way even I would hire me. And once it ended, I wrote the code for it in probably 10 minutes. Also, arranging it so that it was the first in the loop did not help either. The only good thing about the process was that the recruiter was nice about the whol…

Do you think that there's something an interviewer could have done to help you get the solution written within the interview instead of after?

Re: The dystopian world of software engineering interviews

#726
post #308

> 23 interviews and I didn’t get a single offer That's… an unusually consistent signal. Suggests to me that either this person is getting into the wrong interviews (eg junior interviewing for senior role—though they say that's not the case), or more likely there's some hidden variable, like a bad reference, bad BO, really noticeable "culture" misfit, or other "red flag". Regardless, the general points are spot on; it…

I think OP should use interviewing.io and take the feedback seriously. It's likely to be helpful if they want to actually pass those interviews. But there are other ways for a non-traditional candidate to make it.

Not sure why this comment is being down voted. Seems like a sensible suggestion.

Re: The dystopian world of software engineering interviews

#727
post #464

I'm in my late 50s and after 10+ years at same company I found myself on the job market. 1998 was the last time I had any real interviews - after that point it was all networking with no real tech interviews. After much cursing at the advent of white boarding and code tests, I finally just caved and bought a leetcode subscription and starting working problems I hadn't seen since the late 80s in college. Long story sh…

It showed that you were able and ambitious enough to learn (re-learn) a somewhat complex skill in a reasonably short time. This seems like a very desirable property to me, and a good substitute for having strong talent or recent experience of algorithm design and implementation.

Re: The dystopian world of software engineering interviews

#730
post #105

Earlier quoted context omitted.

As someone who interviews, you'd be shocked how many "senior engineers" can't write a function with two for-loops.

I once interviewed a "senior engineer" who was nearly twice my age. I was very intimidated; his resume indicated that he should be the one interviewing me , not the other way around. We chatted for a while, and I felt really good about him. However, I had a gut feeling I should just check to make sure he could do the equivalent of fizz buzz. I said something like "Sorry for this formality, I know it might be seen as…

It's a story I've been told. Candidate is being interviewed for a senior position, there are three employees conducting the interview: one HR rep, one (non-technical) manager and one senior engineer.

The engineer supposed to help with the interview arrived late so the HR rep and manager briefed him, basically telling him the interview was going well and that they were considering hiring him unless he had any objections.

Going back, he asked the candidate a simple Fizz Buzz question, something like finding the largest element in an array. All hell broke loose suddenly. He was outraged and started telling them that, back in his country he was a university professor and that this was beneath him. The interview ended with the candidate arguing for 10 minutes that he shouldn't have to do this test. If I recall, at this point the senior engineer just left the room and didn't bother with the remaining 15 minutes of the interview.

Needless to say they didn't hire him. HR was shocked as he seemed to be a great hire.

Fast forward a few years later, I'm the one interviewing and I systematically get great resumes who can't implement a simple version of word count in 30 minutes.

Post reply on HN