Live data from Hacker News

The dystopian world of software engineering interviews

jarednelsen.dev

101–110 of 851 posts

Re: The dystopian world of software engineering interviews

#101

Earlier quoted context omitted.

How do you sort an infinite stream?

by using an N element max/min heap and evicting the max/min when a new element comes in that's less than the max/greater than the min (note this is also a leetcode problem https://leetcode.com/problems/k-closest-points-to-origin/ )

nothing wrong with knowing the answer or where to look it up, I don't get what your point is

the purpose of the interview is to filter out people that do not know the answer or have pre-learned something and don't fully understand its applications. When you are in a dialog it is a very different dynamic,

people that would not ask a question because it is already posted on leetcode are the problem the OP complains about

Re: The dystopian world of software engineering interviews

#102
post #89

Earlier quoted context omitted.

lol but this is literally a leetcode style problem so what's your point? https://leetcode.com/problems/merge-k-sorted-lists/ https://www.geeksforgeeks.org/external-sorting/ and it's literally called "merge sorted files" (page 175 of elements of programming interviews).

the point is to see how people think, it is not so simple to regurgitate pre-learned answers when you alter a problem one small attribute at a time, in each case a different answer becomes optimal, thus you can see if the person understand what needs to be done or not

>the point is to see how people think

i feel very strongly this is a disingenuous claim. clinical psychologists go to school for a long time to learn how to assess people's abilities to think. why should i believe that you a random software engineer have any competency whatsoever. in reality this is exactly the reason standardized exams (or standardized interviews such as leetcode style problems) exist - because average person can't accurately make that call.

Re: The dystopian world of software engineering interviews

#103
post #49

Earlier quoted context omitted.

There are N other separations I could think of besides the ones you pointed out: - someone who gets anxious and blanks out given hardcore requirements these kind of interviews have, smart people can also go bad at tests - someone who's having a tough day and would fare better taking the challenge home with quiet relaxing time like they would expect to have at work if they need to code complex algorithms - no interest…

False negatives waste far less time (dollars) than false positives. It’s unfair but worth it to not force a team to have to work with an unqualified candidate for a year or maybe more.

This right here, I don’t get. Why TF would a manager make you work with unqualified people for a year+? Between evaluation periods and at-will employment, there’s no reason this should happen.

Re: The dystopian world of software engineering interviews

#104

Comedian Daniel Tosh had a bit about people that claimed to be smart, it's just that they were just bad at taking tests. He said, "oh, so you struggle with the part where we find out what you actually know?" I hear a lot of complaints about the "typical" software engineering hiring process, and it usually comes from the people that don't do well within the current system. Could the process be improved? Almost certain…

This assumes "the part where we find out what you actually know" is actually fit for purpose.

Re: The dystopian world of software engineering interviews

#105

Interviews are so bad because there are too many capable programmers. If there really was a market shortage, companies would not interview like this.

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 an insult to your experience... could we do a bit of coding?" His resume indicated nearly twice as many years of C++ experience than me.

I took out my laptop and produced three function signatures - one passing by reference, one passing by pointer, and one passing a pointer by reference. I asked him to explain the difference between the three. With a completely straight face and unshakable confidence he replied "no difference, they are all three ways of doing the same thing". I asked some clarifying questions, trying to probe the difference between pass-by-reference and pass-by-pointer. Again, he answered extremely confidently and coolly (but incorrectly).

"Err, no." I replied. "This ampersand here is a pass by reference, which means c++ handles the referencing and dereferencing of the pointer automatically. It's much safer than the other two, where you are ultimately dealing with a raw pointer and need to check for null pointers before dereferencing". Immediately he broke out into an uncontrollable sweat; it was really remarkable. Before asking the technical questions, I felt really good about him. I wonder how many companies he has fooled.

Re: The dystopian world of software engineering interviews

#106
post #75

Earlier quoted context omitted.

A couple of reasons: - Comp: Total comp for a new hire with 3+ yrs dev experience is probably 300k -> 400k at a FAANG on average (with possibility to be higher). If you want to live and raise a family in your own house in the bay area (2.5 Million for a reasonable house), this matters. - Access: Few places have the kind of scale and resources of these companies, that can make them fun places to work. You also get to…

What kind of house is a reasonable house for $2.5M?

https://www.redfin.com/CA/Palo-Alto/3805-Magnolia-Dr-94306/h...

Re: The dystopian world of software engineering interviews

#107

> "The horrifically dystopian world of software engineering interviews" If you actually read the linked article, there aren't really any interviews. The OP is just getting let down by recruiters.

There are lots of interviews mentioned in the article.

Re: The dystopian world of software engineering interviews

#108

In my admittedly limited experience, there's one way to avoid such nonsensical interviews - run away from bureaucracy. Seek smaller organizations (startups in particular) and if you're lucky enough to have a minimally cross-disciplinary background, you can seek out niche organizations where you'll interview with technical specialists who'll ask reasonable questions that are actually related to your work and your inte…

In my experience, startup interviews are even less personal and more leetcode based than FAANG. aka solve leetcode hard in 40m on a whiteboard

Re: The dystopian world of software engineering interviews

#109

Interviews are so bad because there are too many capable programmers. If there really was a market shortage, companies would not interview like this.

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

This statement applies to software developers of all ages and fortunately it is very easy to identify these kinds of developers.

However, using the write an algorithm test for this can be problematic as it can easily eliminate software developers who are very good at coding and problem solving, but have chosen not to spend their time memorising the inner workings of standard algorithms, in the hope that one day they will be asked about them in an interview situation.

I don't need to know how to write my own hash table to know how, why and when to use a hash table.

I don't need to implement my own sorting algorithm to sort my list of items.

These and many more standard build blocks come pre-built and ready for use as part of the software development kit.

Re: The dystopian world of software engineering interviews

#110

Earlier quoted context omitted.

But the average HR rep doesn't determine the technical questions! The culpability falls squarely on the engineers who devise these tests.

Well our Dev test was developed by the Senior VP and then tested on our developers; only 1 who aced it. Don't blame me and other workin' stiffs for that...

That's fair, but I bet the SVP was head of engineering, and both of people ops.
Post reply on HN