
Ask HN: Alternatives to algorithms/data structures for software interviews? - thekhatribharat
Most candidates mention spending months on LeetCode&#x2F;HackerRank&#x2F;Spoj before interviews. If you need to spend months brushing up a set of skills, it&#x27;s a clear sign your previous job(s) didn’t use those skills.<p>Algorithms&#x2F;Data structures knowledge is useful to software engineers, but using it as the most important proxy for candidates’ software skills is debatable.<p>Some arguments for this approach include:<p>1) It’s an objective approach, with little to no interviewer bias especially when interviewers use a common question bank.<p>2) New interviewers need little training, so practically anyone on the team&#x2F;org is ready to take interviews after shadowing a couple.<p>3) Algo&#x2F;Data Structures rounds can be easily automated with online judges.<p>What are some alternatives to algorithms&#x2F;data structures approach that don’t lose some&#x2F;all of the benefits mentioned above?
======
haditab
In general it's very difficult to interview in a way that would give insight
into previous work experiences at a practical level. Every interviewee will
have their own unique experiences and even though they may all have similar
backgrounds, designing an interview question that would be general enough to
gain insight into all of their experiences is nearly impossible. I've
interviewed at places that attempt this and I've never felt that it worked out
the way they were intending it too. They usually become too specific to the
ideas/experiences of the person who designs the question.

I think algorithm and data structure problems can be useful if used correctly.
I think the main issue is that most companies tend to use leetcode style
problems which are a bit more on the brain-teaser side and are often usually
harder to solve if you haven't spent a significant amount of time solving such
problems. These questions might make sense for super competitive positions at
places like Google where they can afford to reject good candidates, but at
most companies it doesn't make sense. I think simple problems that involve
working with the same data types required at the job would suffice. The
purpose of the question should be to screen out candidates who can't solve
them, not to judge how good they are.

------
username90
The problem is scaling a process, the number of people who can catch
bullshitters during an interview are not enough to scale up a conversational
interview. Most tries to solve "How would I interview someone?", instead they
should ask themselves "How would an engineer with mediocre social skills
interview someone?", because that is what you'll get when you scale up.

So, conversational interviews are out, no way someone with mediocre social
skills will catch a bullshitter.

Take-home problems work as a screening tool, but has the problem that you
don't know if they wrote it or if they spent an extraordinary amount of time
on it. You need to evaluate this on-site somehow. Many here say "Just have a
conversational interview about it and we'll catch the bullshitters!", would
you expect a mediocre interviewer to catch those? So no, doesn't work.

That leaves on-sites. We have 3 on-site interview styles which are known to
work, each with their own problems:

1\. Technical coding interviews where you solve an algorithm problem. Even the
most junior interviewer can use this style and requires basically no training.
Lots of experienced engineers feels this is unfair since it experience doesn't
help candidates much.

2\. Technical design interviews where you are given a high level problem and
discuss how you would architect the solution. Note that this requires
significant technical skills and experience from the interviewer so only
senior engineers can administer it, so you can't be too liberal with them.

3\. Structured behavioral interviews, ask a series of "Tell me about a time
when you disagreed with a coworker, how did you resolve the issue?". This
style is extremely popular in non-tech fields, so there is pressure that we
get more of them in tech as well. Popular in Amazon, "Leadership principles".

Now, it is not like Google could substitute more coding interviews for design
interviews, they don't have enough people who are qualified to administer
design interviews. Also I am not sure if people would be happy if Google did
mostly structured behavioral interviews. I know they recently changed 1
technical interview to a behavioral interview, but I am not sure this makes
anyone happy since you still have 3-4 coding interviews.

------
AnimalMuppet
Our process is, first, a phone conversation, maybe a half hour. Then the
interview is two hours.

The first half hour is just talking to them about their background and stuff.
Then we give them some code to read, to see if they can figure out what it
does. Then we have them write a bit of code (nothing leetcode-style, just a
simple function). Then we have them do a bit of design.

Since we do the same to everyone, we are by now fairly calibrated as to what a
good candidate looks like.

------
potta_coffee
This my problem...spend months working on these kinds of problems, finally get
a job, get rusty because I'm doing totally different stuff at work. Find
myself needing a job again...study and grind for months just to have a chance
at passing interviews. It's all so tiresome.

------
dopinder97
I had a particularly interesting on site interview where part of it involved
fixing a bug in a previous version of a well known open source framework. They
gave us the relevant tests to run which showed us what was failing on which
inputs. We were welcome to use our personal laptops/coding environment to
debug and fix the bug. I personally thought it was a good way to demonstrate
the ability to actually navigate a larger codebase, understand what tests were
doing, and to follow program logic through a large project and ask pertinent
questions. Granted this was for new grad interviews, but it did seem a lot
more relevant to day to day work than leetcode problem #X.

------
tdxgx
Hire people with masters degrees

~~~
sciencewolf
I have a master's degree in CS... I'll have you know having that degree does
NOT tell you more than a whiteboard interview

