Comment by 52-6F-62 | Hacker News Reader

Comment by 52-6F-62 | Hacker News Reader

I'm of the opinion that if there needs to be some objective technical challenge to determine a baseline of competency (and there are very many, very strong arguments for that) then there need to be standards.

I've encountered so many variables (no pun intended) in technical interviews that I've virtually stopped preparing. There's hardly any way to prepare when the field is so large and you never really know what you're going to be tested on.

I've had people challenge me on theoretical system-time timezone conversions (and incorrectly mark my correct answer wrong "because of physics"...), beside reimplementing native JavaScript functions, beside complex algorithmic problems, beside toy problems like building a binary calculator. [That's great if you learn I can rig a web page for adding 100 and 101, but how do you know if I know anything about databases for this back end position]

And those interviews were all for working with web tech, in a couple of the cases just front end positions.

There needs to be a common, limited standard and/or domain-specific standards.

It's really counter-intuitive to me, and I don't understand how it benefits the hiring process, if a company is looking for a web-back-end engineer for what is essentially a complex crud app and wants to propose the candidate solves a problem from a domain they've never worked in—and marking them on the correctness of the answer, rather than the work process.

I'm for objective, technical challenges. But I've seen enough that it seems apparent to me that it's broken.

(addendum: I've had several good interviews as well, and good interviewers. I had a good one recently as well that was fitting for the domain. They're not all bad, but most seem to be in my experience)

I interview a lot of people for frontend positions. I ask one two-sum question to see if they have some knowledge about data structures and simple algorithms. Then I ask them to build something trivial in React, which is what we use. If you can do those things, you're probably fine. The number of people who can't is truly shocking.

I would argue there are many well-qualified frontend engineers who won't correctly solve the two sum problem on their first time encountering it.

This one? https://leetcode.com/problems/two-sum/

>>> Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target. You may assume that each input would have exactly one solution, and you may not use the same element twice.

Seems trivial enough to me... except if the interviewer forgets the hard constraint that there is exactly one solution, then that's a shitstorm of edge cases.

I'd criticize the problem for asking for the positions of the numbers rather than the numbers. That's just super annoying for no reason.

Does the problem actually have that constraint? If so then yeah it's significantly easier. I thought the reason you'd have to use a clever algorithm is because a brute-force solution to find all index pairs would require n^2 operations, where n is the size of the input array, because you can't stop after you find a single pair.

Yes it does, you can open the leetcode and see for yourself. That also explains the "easy" difficulty rating.

I guess you've been giving candidates a more hardcode version of the problem, not having that constraint?

edit: nevermind, it's the other poster who was giving that problem, not you. No idea how they formulate it in their interviews.

I don't ask candidates these kinds of questions in my interviews. For a coding interview, I'd normally ask them to implement something like backend rate limiting logic for an authentication service, and continually ratchet up the complexity on each successful implementation until the end of the interview.

I was asked the two sum problem in an interview once, but I forget if it had this constraint or not. This seems much more reasonable.

Forgive me for my ignorance, but are you looking for anything more complex than a leaky bucket algorithm + gossip protocol solution?

Technically, if all values in the array are the same value X, and the target is 2X, you can't do better than O(n^2), because just writing writing all valid solutions is O(n^2).

If you can create a new array containing indices to the original array, sort the new array, and use two pointers starting at the beginning and the end of the sorted array to find a solution, it takes O(n×log(n)) time. It is not necessary to assume that the solution is unique, assuming it is okay to simply write one of the possible solutions.

If all values are between 1 and k, and you can make a k-sized array, you can find a solution in O(n+k).

No matter what you do, you can't get better than O(n).

The important thing is that there is more than 99% chance you will never have to solve this problem in your job; and even in the case you would, there is 95% chance that the O(n×log(n)) solution would be acceptable regardless of whether it is the best possible or not.

If we're being very charitable I guess the idea of using a HashMap for an optimal solution might slip your mind but even a freshman in CS can just loop twice over an array and solve it.

I might be misunderstanding the question; how many pairs can there be? You can't just loop over the array twice to find all qualifying pairs of indices, if there are multiple. You'd have to loop over the array n times, where n is the size of the array. Isn't that why the question is difficult? There doesn't seem to be much incentive to using a hash table, complexity wise, if you could just solve it in O(n) time and O(1) space by naively iterating over the array.

He meant "write two loops" when he said "loop twice". It seemed obvious to me that he meant that but I can see how if you're used to more unambiguous language it could be confusing.

Yeah, you just do it in O(n²) worst case because the problem is O(n²) to find all pairs that match because there can be O(n²) pairs.

However he meant one pair here too. Pretty easy to solve. Did it in under 30 s in Python on my broken cellphone. If there are multiple pairs, just replace return with yield.

Same here. Absolutely shocking how many people fail at basics, yet they pose as mids or seniors even. I'm not even talking about CS, I'm taking about simple React-based assignments designed to show you know (at least) the basics and takes as little as time as possible to be fair from our side not taking too much of interviewee's time. Take what you want from it, but I've seen it mainly in web dev related positions.

Yes, I see people fail at basics in interviews all the time. But I keep wondering how much of that is people being poorly qualified, and how much of it is interviews being poor indicators of true skill.

I've seen people barely sneak through technical interviews, whose subsequent performance justified the concerns I had at the time. I've seen others hired against my personal recommendation who turned out to be brilliant at their jobs.

Of course. That's the primary reason I'm personally against tasks on the interview itself or whiteboarding. That's usually a shitshow. We first do an interview where we talk a bit about our company and the interviewee, we get to know each other out a bit and try to find out if we're a good match for each other, based on the talk itself. If that's the case, we give a small (really small and basic, unless a senior position) assignment to take home and get back to us in five days. People have schedules, obligations, we understand. During the period we're always available for any questions, doubts, whatever you need. Assignment itself takes a couple of hours at most for someone that knows / has used the tech. At home, you can use google, stackoverflow, friends, books, I don't care. No one cares, as long as you show up with a consistently-looking code that works and that we can comment together on. You know, same as at work. Something to talk about for a bit, if at all. It's the basics. A damn good filter, it turns out.

> ...if there needs to be some objective technical challenge to determine a baseline of competency...then there need to be standards

After having been on both sides of the table, I’ve really come to appreciate the system of licensure used in the trades. I don’t have to quiz an electrician on the electrical code or ask them to wire up a dog house. I also know they have requirements to keep their license active. I’m not sure what that process could be like for software, but it would sure be nice to eliminate the enormous collective waste of time spent (poorly) establishing candidate competency (especially when they have to do it for every single company).

the FAANG interviews are pretty standardized now - but then that only selects candidates who are well prepped for the interview itself.

They're really not. It becomes a cat and mouse game where the interviewers know which pool of questions people are studying so they try to invent new ones to prevent people just memorizing the answers. The questions thus end up becoming more and more obscure.

yeah but they're variations on the same stuff. it just allows gaming of the whole process where if you solve enough of those types of questions, you have a better chance of getting in.

Some are variations but some are just more obscure. They definitely get into very specific greedy algoss or things like prim's/kriskals/tarjans. which can be pretty much hit or miss based on if you've seen it or not

> that I've virtually stopped preparing

Surely this is a good thing, no way for people to game the system and no time wasted.

Oh no. I've wasted plenty of time. And so have they by interviewing me and proposing ludicrous problems well outside of the problem domain of the role I was interviewing for.

I understand some problems are meant to judge your thought process, others are meant to measure your basic literacy. I'm not talking about those, however.

My experience in interviews has been that most of them are engineers pulled into the process who searched the web for "software developer interview questions technical" and cobbled together a few disparate options without a moments concern more.

Then again, those kinds of interviews have certainly cemented my desire not to work there.

Reply on news.ycombinator.com