
I've been a software engineer for 10 years and I can't do interview questions - tempw
https://www.reddit.com/r/cscareerquestions/comments/5xrs2n/ive_been_a_software_engineer_for_10_years_and_i/
======
pklausler
If you hate the idea of coding questions as part of interviews, please
consider the other side for a moment.

There are people out there (not you, obviously) who can talk their way into an
interview for programming jobs that they simply can't perform. We're talking
about no skills whatsoever, apart from the ability to sling buzzwords around
enough to impress a recruiter. God only knows how they get their degrees, but
they have them.

Simple, straightforward programming questions that aren't already on the Web
are like an immune system response to these non-programmers who interview for
programming jobs. I'm truly sorry when a real programmer feels insulted when I
ask them something like "given the starting and ending times of two calendar
appointments, write an expression that's true if they conflict", because it's
not their fault that there are people out there who will struggle for 20
minutes thinking about how to solve it before trying something like a doubly-
nested loop over all the milliseconds in both intervals, testing for equality.

I am not making this up. It's a real problem. if you can program a digital
computer, you have nothing to fear from a _good_ coding interview. And if you
have a better way to reliably identify the non-programmers, I'd love to hear
it.

~~~
jcadam
I myself have sat in an interview with my mouth agape as I watched a "senior"
engineer try to figure out how to find the largest element in a one-
dimensional array.

So, anymore I don't have much of a problem with simple coding questions to
filter out total non-programmers (fizzbuzz, your calendar problem, etc.).

But the whole _stand on one foot and implement a red-black tree in bash script
on the whiteboard while I peck at my smartphone and sigh every time you pause
to think_ has got to freaking stop.

~~~
dpark
> _while I peck at my smartphone and sigh every time you pause_

This is a much bigger deal to me than difficult algorithm questions. Shitty
interviewers give shitty interviews, regardless of what kinds of questions
they ask.

The worst interview I ever had was like this. The guy showed up late, told me
he forgot he even had an interview, gave me a strange question with little
detail, and told me to start coding. Then ignored me for an hour while he
typed on his laptop. Even when I directly asked for feedback to make sure I
was solving the problem he asked and not a misunderstanding, he gave me
basically no feedback. I've had interviews that I bombed before, but this was
the first and only time that I felt like I bombed an interview and it was
utterly not my fault. It was also the only time I've had a bad interview that
actually ruined the rest of the day for me because it threw me off so much.

~~~
tonyedgecombe
I think I would just walk out at that, at the end of the day this is someone
you are going to have to work with or for.

~~~
dpark
I wish I had. If something like that ever happens again, I will.

------
misja111
I was in the same situation a couple of years ago. I had over 15 years of
experience, was invited for a technical interview at Amazon, and failed. At
first I was irritated, just like the author. But then I decided to turn this
negative energy into something positive and followed a couple of courses on
Algorithms on Coursera, also I discovered Hackerrank. And I found out that I
actually loved solving algorithmic problems!

Now it is a couple of years later and I actually was able to land a job thanks
to my new skills (not at Amazon though). But what's much more important: I
found a new hobby that will keep me entertained for many more years.

~~~
mavelikara
My story is the same too. I was a promising junior developer when I went to an
interview at Amazon. Got my back handed to me. I was upset, but decided to
work on it. Read a few books on the topic, and I no longer find these
interviews difficult.

~~~
nojvek
Before I interview I mention that I am uncomfortable with whiteboards. I
prefer pen and paper. It's faster to write and feels a bit natural.

Only one company denied me the request and I didn't go ahead for them. Their
loss.

I've also found having a github profile where you've files issues on projects
and made a couple of commits really helps the chances. It gives more data than
a resume.

At one interview, the interviewer read some of my commits and he said "I don't
have any doubts you can code, but I wanna ask you about design". He went on to
ask why I did things in a certain way.

But seriously. "Say no to coding on whiteboards".

~~~
wry_discontent
I'm the opposite way. I prefer the whiteboard to pen and paper.

------
sna1l
I think algo/ds interviews are created to test only one thing, and that is
hard work. The idea that they test problem solving is mostly bullshit.

 _Most_ people are good at algorithm interviews because they've practiced them
a ton. They've seen basically all the different kinds of questions that get
asked on an interview, and are able to use that mental database to answer any
questions.

Most of the time in interviews, interviewers will commend an applicant's
"problem solving" skills if they did well on a difficult algo problem, when in
all likelihood they've seen that exact problem, or an extremely similar
problem before. If the applicant hasn't seen dijkstra's algorithm before and
is able to derive it in a 45 minute interview, you would need to hire them on
the spot, assuming that Dijkstra himself didn't develop this algorithm in 45
minutes. That is a contrived example, but you get my point.

For better or for worse, algo interviews are for testing how much work you've
put into studying (mostly worse).

~~~
praneshp
I've seen that many good interviewers have a problem that has a
straightforward sub-optimal solution, which they expect you figure out
('problem solving') and code. If it can be solved better using Dijkstra, that
comes as a follow-up.

------
baron816
I've had a lot of trouble finding a job since shuttering my start up, which I
constructed on my own. I open sourced my code, but no one seems to care. They
still just look at me as if I have no experience and pass on me before a
technical assessment.

It's troubling to know that engineers with many years of experience still have
difficulties. Every job listing I see asks for someone with 6+ years, and the
only feedback I ever get is "we're looking for someone with more experience,
try again in 4 years."

Tech companies should really just hire for soft skills. Screw tech interviews
completely. A lot of this stuff can be taught. Maybe just give people a
contracted trial period. Companies are spending incredible sums of money just
searching for candidates that meet their exact "needs." In reality, they're
not going to know how well someone performs until they actually work with
them. Stop wasting your employees' time by having them grade pointless coding
quizzes. Use that time instead to train someone who's a good communicator, is
passionate about the product, is creative and eager to learn, and wants build
something your customers will love. Even if that doesn't work out, at least
you didn't waste everyone's time.

~~~
sammydavis
You are arguing that we should just hire anyone regardless of tech skills if
they can carry on a conversation? It takes years to do learn how to do actual
complicated programming. I think we need to screen for both tech skills and
soft/people skills. I always strive to do both in my interviews.

~~~
baron816
I'm not saying that, and I doubt there is a very high number of fraudulent
applicants to companies. If that becomes an issue, then there are less
terrible ways of dealing with it. Wha I am saying is that we should let
people's experiences speak for themselves. If someone's been a developer for
three years (and didn't get fired for incompetence), then they probably know
how to code.

~~~
falsedan
> _I doubt there is a very high number of fraudulent applicants to companies_

The payoff is a $100,000 salary that you can collect for a month or two, of
course there are fraudulent applications.

> _If someone 's been a developer for three years (and didn't get fired for
> incompetence), then they probably know how to code_

I've worked with very capable Ph.Ds with wonderful problem-solving &
analytical skills who would write the worst code, and were the worst at
accepting feedback because of their extremely visible and objective
achievements allowed them to believe they didn't need to improve their coding
skills (which had already gotten them so far)

------
runT1ME
But could all practicing lawyers pass the bar _right now_ in their respective
state? I'd guess no. The problem is not the questions _necessarily_ , it's
that you have to study a bit and do the same goddamn interview questions at
multiple companies, sometimes with very different interviewers. Some are
helpful, some make me nervous, some are asking the hardest possible questions
without warmup easy questions, etc.

Whiteboard or live coding is not the problem. Bad or untrained interviewers
are, along with the fact we can't do one interview that proves to multiple
companies what level we are at.

~~~
shadowcodex
However, should a practicing lawyer have to re-pass the bar in order to land a
new job?

~~~
snerbles
Are we going to make the PE exam a requirement for the title of "Software
Engineer"?

~~~
prions
It really should be considered. I'm a registered (civil) EIT. IT would help
towards the ambiguity in hiring and the ever increasing absurdity in
interviewing.

Especially since the conflicting statements of "software jobs need protection
to ensure good salaries" and "everybody needs to code" are all to prevalent
here.

Being a PE means you have a certain level of experience and skill. It's a
distinguishing feature and sets you apart as a "real" engineer. Additionally,
it holds you to an ethical code.

What continues to astound me is the lack of rigor and ethical backbone coming
from engineers in important places. Yeah you're not building a bridge, but
incidents like Volkswagen and Yahoo could have been prevented if people's jobs
were bound by not being unethical.

~~~
yourapostasy
I suspect your advocacy of a PE designation for software and the discussion in
this thread are slightly orthogonal. Not that is a bad characteristic, but I
want to point out that the question under discussion would be similar to
asking if civil engineers should prepare as if they are sitting for their PE
exam every single time they start the interviewing process? Should practicing
doctors, no matter how accomplished, prepare as if sitting for their boards
every single time they start the interviewing process to say, move to a new
hospital?

I also suspect that everyone is asking the wrong questions. From the anti
algorithm questions for interviews crowd, there is scant acknowledgement that
it can't be a blanket policy, as undoubtedly some positions are strongly
algorithm-heavy roles. From the pro- crowd, there is scant acknowledgement
that by the time you are trying to find new high tech hires through a process
that bases an evaluation upon actual interactions that are measured in hours
or at best days, _you may have already failed_. The industry is fitting an
interviewing process last majorly overhauled during the industrial age that
screens for basic three-R's and attendance skills onto a post-industrial
landscape where those skills are barely above cosmic background radiation
noise, and demonstrated achievers are as often groomed into hirings through
networking over years and decades. Perhaps part of the response to better
outcomes to "this high tech interviewing process that takes place in hours or
days" isn't "find better questions" or "find a better procedure that still
fits in hours or days", but "re-think our premises"? Some kind of PE might fit
into that re-think, but the brokenness is so bad that Google has quantified
the inability of our conventional processes to yield significantly-better-
than-random outcomes, so it might be time to start questioning the entire
premise that we can even hire based upon tech interviews in the first place.

~~~
dpark
> _but I want to point out that the question under discussion would be similar
> to asking if civil engineers should prepare as if they are sitting for their
> PE exam every single time they start the interviewing process?_

I suspect the typical PE exam is quite a bit more rigorous than the typical
technical interview. Technical software engineer interviewees are asked to do
thinks like reverse linked lists and provide the most basic runtime and space
complexity analysis. The structural engineering PE covers everything from load
analysis and building codes to runoff analysis an slope stability[1]. There
are 9 different "breadth" exam areas and 3 different "depth" areas, and
they're all covered.

I think it's slightly ridiculous to compare understanding basic datastructures
and algorithms to sitting for a PE.

[1] [http://ncees.org/wp-content/uploads/Civ-Str-
April-2015_with-...](http://ncees.org/wp-content/uploads/Civ-Str-
April-2015_with-design-standards.rev3_.pdf)

~~~
yourapostasy
I think what they are trying to point out is PE holders don't revisit taking
even part of the PE when they interview. Is that true, though?

~~~
dpark
I have no idea what a typical (civil/structural/etc) engineer goes through
when interviewing. I suspect that the PE isn't actually very relevant, though,
since most practicing engineers are not PEs. Something like 20% of engineers
get their PE. I'm guessing the interview process for PEs and non-PEs is pretty
similar.

------
NTDF9
You know the process is fucked up when experienced professionals (with a track
record of delivering projects) start complaining about how companies don't
look for the ability of delivering projects.

~~~
peter422
Every engineer says they delivered projects on time with great maintainable
code. Unless the project is open source, they often have no way of giving any
evidence.

I'm not saying whiteboard interviews are the right way to interview, but in my
experience you can't trust people's judgment about themselves and their
skills. You need an interview that is equally fair to the person that will
exaggerate their past successes to the people that are more reserved or the
people that don't have much experience yet.

~~~
mtberatwork
> you can't trust people's judgment about themselves and their skills.

Unless the candidate is fresh out of uni, any qualified candidate with
experience should be able to provide at least several solid contacts at
previous employers from which to obtain this information.

~~~
dpark
References from co-workers aren't really that valuable. Many people have no
qualms about giving glowing reviews for friends, even if those friends don't
really deserve glowing reviews.

------
throwaway26960
The interview process is great for employers...

1\. Make qualified job interview candidate feel stupid by asking difficult
questions unrelated to the job

2\. Offer candidate low salary and argue that they barely passed the job
interview

3\. Profit

Best solution I can offer is to not play their game. You'll lose no matter how
hard you try. You're better off studying marketing and psychology for job
interviews.

~~~
Vekz
Great points about marketing and psychology. once you've won the lottery and
got a whiteboard question, that you've prepared for. You additionally have to
win unconscious biases of the interviewers and exhibit behavior that makes
them judge you as a trusted "cultural fit" tribe member

~~~
deegles
Sigh. I completely crashed and burned at a phone screen once with a question
that was easy but required knowing a bit shifting trick. I knew that the trick
existed because I had glanced at it while studying and thought, "no way
they'll ask that."

------
pgtruesdell
Form over substance, as usual with large bureaucracies. Unfortunately, tech
seems to view the biggest and most "successful" company as the model way to
move forward, instead of throwing up the middle finger like they used to. It's
sad to see the transformation of Silicon Valley to a pseudo-government style
group of mega-conglomerates. The next batch of real innovators will not be
from the Valley or be from Valley culture.

~~~
jstewartmobile
Yep. Used to be, the dream was to beat Bill Gates. Now the dream is to get
bought by Facebook.

~~~
omouse
The dream was to make your own rules (which includes a ferrari, a private
office and all sorts of perks). Getting bought by Google, Facebook, etc. is
the new way of getting "fuck you" money.

------
calvinbhai
I have spoken about this to many SEs who are senior enough to conduct
interviews in their companies. I ask them, what do you intend to get out of
such interview process. Their response: 1) Evaluate how to think about a
problem 2) Evaluate their approach to a problem 3) Evaluate how to solve by
asking questions

So, most of these interviews, an experienced Software Engineer dons the hat of
a psychologist (without having any qualification/experience of a psychologist)
and evaluates an interviewee.

How sad is that?

Whats worse? I know a few who prepare to interview a candidate by going
through "how to crack the coding interview"!

I'm only glad that there are quite a few in my circle who believe in giving a
problem they have faced at work, to a candidate, and ask the candidate to
solve, using the same tools they use, with the laptop hooked to a projector.
Interviews where I have done this as a candidate, I feel are more respectful
of the candidate.

Many of those who love the "let me be an unqualified psychologist today"
interviewing style disagree with my opinion. So do I, with their's.

------
framebit
Application performance matters, that's why these data structures and
algorithm questions still matter. The issue is dogma surrounding the
technicalities of data structures and algorithms.

We make sure in our group to focus on application of those concepts, not
memorization or detailed knowledge of the concepts themselves. But yeah, fast
algorithms matter. Memory usage matters. Proper data structures matter. I
don't really care if you can spit out a syntactically correct implementation
of a red-black tree on the spot, but you should know what a tree is and why
you might pick or tree over a hash table.

I'd rather hire a writer who can really get a concept across but relies on
autocorrect for spelling than a writer who can spell the hell out of stuff but
can't actually write. Dogmatic interviews weed out the software engineers with
the big picture skills and performance thinking who might be fuzzy on the
details, like experienced folks who are decades out from school.

~~~
LordKano
_Application performance matters, that 's why these data structures and
algorithm questions still matter._

THIS! It's one of my go to stories but back when I was working as a co-op
during my undergrad days, in my department there was a .NET programmer who was
skilled but had no understanding of the underlying data structures.

He would be mystified at how I could write Perl programs that would outperform
his .NET programs, even on less robust hardware.

------
shadowcodex
It's all become a game now. If you spend enough time on sites like codefights
and hackerrank and know all the algorithms you can land a job. However, if you
aren't prepared for these whiteboard interviews you are screwed.

------
nix0n
This is by design, they're looking for students.

~~~
istorical
Students, super high achievers / superstars, and people who are willing to
"play the game" and re-study everything for 2 weeks or a month.

~~~
hackerblack1
LMAO.2 weeks?

HA!

Currently a graduating student that goes to one of those top schools. Do you
really wanna know how long many of my peers are studying for these interviews?
Months!!!!! I have a few friends that spent all of last summer after their
daily internships doing interview prep for fall recruiting season. I also have
a cousin that spent 5-6 months unemployed(given he did a masters/bs in ee and
not in cs but wanted to move into the field) doing interview prep and just
landed offers from Google and Dropbox. The competition is absolutely ruthless.

------
issa
I worked at an unnamed big company where the interview process involved being
interviewed by a PHP expert, a java expert, and a javascript expert. They were
surprised when NO ONE ever passed the interviews. Most actual hiring at the
company involved getting contractors from a recruiter and then hiring them if
we liked them--no technical interviews, just how much we liked them personally
and if they could perform at the most basic level. I would imagine this is
pretty common.

~~~
lj3
That's called 'contract to hire' and it was fairly common about 5-10 years
ago. I don't see it as much these days. I'm not sure why, but it seems to have
fallen out of fashion.

~~~
flukus
You don't see it because it gives the candidates a chance to see what a
companies code base is like and look elsewhere when they discover how bad it
is.

~~~
lj3
And that's exactly why I like work to hire. The biggest factors that
contributes to whether you like your job or hate your life are your boss, the
people you work with and the state of the code base. You don't get a good
impression of any of them until after you've been hired.

------
segmondy
For some folks 10 yrs experience is truly 10 yrs experience, for a lot of
folks, 10 yrs experience is 1 yr experience repeated 10x. Or worse a few
months experience repeated more. Unless you are truly learning each week and
working with new tech often. Number of years doesn't tell me much. I've seen 2
yrs experience crush 20 yrs experience all around, in design, programming, OS
knowledge, database, etc.

------
NikolaeVarius
I don't quite understand this point of view and the whining. Why is it that
Software Engineers feel the need to whine about these technical interview
questions? I don't think many of these are THAT technical either, just
requires some practice. I dislike brain teasers, but I don't think Algorithms
questions are out of line, even if you might not use them.

I graduated with an Aerospace Engineering degree. While I don't exactly
remember how to derive the Normal Mode of a wing, I wouldn't have any issue
relearning it for an interview. For my first job, I was asked questions that
had very little to do with my day to day but I still answered them and didn't
complain.

~~~
falsedan
> _Why is it that Software Engineers feel the need to whine about these
> technical interview questions?_

Because they're pointless for the vast majority of positions: why make me
learn something for the interview that I'll never use again? This offends many
engineers' sense of laziness.

Because it's a pithy indication about what's wrong with tech interviews: we
can't ask 'are you good at delivering with weird requirements' (because the
candidate says 'sure I'm the best'), and we can't check their ability to do
that in 45-60 minutes. Instead, we use these shibboleth questions to see if
they are like other engineers (who can deliver etc.)

Because it's gatekeeping: if you didn't study algorithms or have the
time/energy to keep it fresh, you can't get past these interviews and get
these jobs. It doesn't matter if you'd excel if you don't have the same
opportunities as the normal privileged young white male engineer.

Because it's inefficient: plenty of engineers could perform well in the
position but get screened out by these imprecise questions. Sure, for a
startup of 4 employees, you can't settle for great and have to keep rejecting
until you get the best, but for a mature stable company, you want people with
solid skills and abilities who can learn (how to do algorithms) on the job.

~~~
NikolaeVarius
None of that is specific to software engineers.

My non software-engineering Interviews contained tons of questions that aren't
completely relevant. For example, describe in detail how pressure and velocity
are correlated in each turbofan stage and how they affect efficiency. Describe
what isentropic flow is and how it relates to lift.

I also hate getting random whiteboarding questions, but I'm not going to
complain about it. If I really want a job I'm going to study for it.

~~~
falsedan
> _If I really want a job I 'm going to study for it._

Congratulations on having the resources and stability that these interviews
select for! Unfortunately, these are not requirements for doing well at the
job.

------
ep103
I call bullshit on this train of thought.

I've been reading about this on HN and reddit for years now. This last
December, I was promoted high enough, that I could design the entire interview
process (with executive help) for my teams. Which was important, I very much
need to hire some people.

So, keeping posts like this in mind, I designed as follows:

Phone Interview - We talk about you, the company, etc. Then a few technical
questions. Do you know certain things about js that make me think you are
genuinely familiar with the language (as opposed to just jQuery)? Do you know
certain things about sql that make me think you are genuinely familiar with
the technology (as opposed to just using a table designer)?

Assessment Test - Do a quick crud app, that will require some thought behind
how to query the data. Make a point when talking to the prospective applicant
that the code will be read by the team members they'll be working with, so
while you can do the test quickly, please spend enough time on it that we can
talk about the code, your choices, etc going into the technical interview. Ie)
don't just link together 3rd party plugins.

Actual Interview - Interview with leads, interview with actual team members.
Offer both use of Visual Studio / SSMS / IDE of choice or whiteboard. Ask
questions about technology in general. Ask the applicant to explain how he'd
design out a new feature. Change the feature spec, so that there's a little
bit of a hard problem. Have to populate a tree from flat sql data, or
aggregate data from a service, or some other not-quite-an-algorithm question.

The RESULTS?

Recruiters figure out what questions you are most likely to ask during the
phone interview, and school the candidates.

The assessment test? No one bothers, everyone just hands in the simplest 3rd
party libraries plumbed together with shitty code. Was the question select top
per group? How about top 1 *? The really good devs shine through here, but a
huge percentage don't even bother.

Actual Interview? No one uses IDE / SSMS. All of them choose whiteboard. The
ones who genuinely know how to code, have no problem answering, and would be
fine answering algorithm questions straight out. The ones who can't, get
confused somewhere or other. They try to implement hacks around the problem
(I'd have the dba do it), then fail to actually solve the question.

So In Short? I completely understand where this guy is coming from. But I also
think, that at this point, I'm so tired of interviewing people who clearly
don't care about their craft, that I want to start asking nothing other than
algorithm questions... because the guy or gal that actually answers them will
actually care about their craft. And at least with algo questions, I can
change the question easily, and frequently. Coming up with real code problems,
and good probing questions is much harder, particularly if they're going to
have a short shelf-life before recruiters start training their candidates with
answers.

~~~
eternalban
Algorithm questions come in two flavors:

sensible: given the problem statement discuss your initial choice of
algorithms and datastructures. This probably covers 80% of tech jobs out
there. And you easily dig deeper with big-O and related here. You should have
a very good idea if the candidate is clueless or not after this.

other: given a datastructure and algorithm, implement it. This makes sense for
a minority subset of jobs/devs.

~~~
dpark
> _given a datastructure and algorithm, implement it_

This can be entirely appropriate for most jobs/devs, depending on the
datastructure/algorithm. One of the guys I work with sometimes asks people to
implement mergesort. I was suspicious of this question at first but it's been
quite good at weeding out mediocre candidates. Mediocre candidates will write
broken code all over the board, and more telling, they won't understand why
it's broken even when you point it out. Good candidates will generally make
mistakes (because no one has mergesort code memorized and coding on a
whiteboard is frankly tough), but they'll recognize them, typically on their
own and always with pointers, and they'll be able to explain the issue and how
to fix it once they see it.

There's no trick to this question. There's no riddle, no "gotcha", and it's
not a hard algorithm to understand or code. Just show that you can write
minimally complex code and walk through it. It's like fizzbuzz but you can't
memorize it.

------
peterjones2
I am just beginning my studies in computer science. I find discrete
mathematics, data structures, theory of computation and algorithms to be the
most interesting aspects of computer science. If I took an undergraduate
algorithms course (Chapters 1-3, 7-9, 11-13, 15-16, 22-24 from CLRS) would I
be prepared for most interviews?

I noticed the graduate course overlaps with many of those chapters and also
cover: chapters 18,21,25,26, 29-32, 35.

Ideally, I would like to take both courses out of pure self-interest.

~~~
GrumpyYoungMan
As others have suggested, get a copy of "Cracking the Coding Interview" and
review the questions therein. If you can answer those questions easily, you'll
have an easy time at the average interview.

If you want to prepare to interview at one of the top companies, then
afterwards procure a copy of my secret weapon: Aziz, Lee, & Prakash's
"Elements of Programming Interviews". The questions there are an order of
magnitude more difficult. If you are able to apply the CS concepts you are
learning to questions of that difficulty, all doors will be open to you.

~~~
peterjones2
Thanks for taking the time to answer my question. This is my first time
commenting on HN and am being downvoted for my legitimate question.

~~~
GrumpyYoungMan
Just a helpful tip: mentioning being downvoted is against the HN guidelines
and usually attracts more downvotes.

pkahler's sibling post also brings up an important side point: beyond the
basic core, what you study really needs to be focused on what aspect of the
software industry you want to be in or are likely to find yourself in. While
I, too, encourage you to take C/asm courses or whatever your preferred focus
is, the bulk of the jobs in the industry are in creating web sites and
business systems (much of which are so-called CRUD apps; see
[https://en.wikipedia.org/wiki/Create,_read,_update_and_delet...](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)).
Even if you plan to do something else, a course in databases and concurrent
programming will stand you in good stead as a fallback if your career doesn't
quite go as planned.

------
dbg31415
Hiring at most companies is fundamentally broken.

We have no way of knowing if someone will work out, so finding ways to rule
people out makes it seem like we did our job in the hiring process. Some
Wonderlic-type questions, the person asking them gets to say, "Well, look we
have some quantifiable way of measuring applicants." Total BS.

No cure for it, other than to not turn around and be that asshole once you are
hired. We should be more open about what the criteria is; hiring comes down to
a few gut checks... do you like the person and think they will fit in, do you
feel confident that they can do the work you will ask them to do, and are they
in your budget?

Unless you work with a person over time, there's not going to be any way of
knowing how they are as an employee. If they are smart, if they keep up on
current trends, if they are a good communicator (and any good at communicating
inside of your organization), if they care, if they show up on time, if they
are conscientious or just pass the buck, if they are a hard worker, if they
are opportunistic / selfish with praise...

Anyway HR needs to justify itself so we can't just throw darts at resumes...
but essentially that's all hiring is. Trying to get a sense of someone
quickly, cheaply, and correctly? Nah, just pick 2... at most.

------
pascalxus
Well, you have to understand, the whole point of an interview to construct
questions you or at least a subset of the candidates can NOT answer. When
there's too many qualified candidates, you've got to weed them out somehow.

------
facepalm
I must admit I can not really relate. What about somebody who can not
FizzBuzz, but claims they can code? Most whiteboard interviews I had were not
much harder than FizzBuzz. I was asked to implement Quicksort once, but they
gave me the specification, some time and a sheet of paper.

Why would somebody for whom it is easy consider to hire somebody who can not
do a seemingly simple thing?

I can understand if somebody has anxiety issues. Then maybe you can negotiate
something else, homework project or coding on site for 30 minutes. But odds
are you'll discuss stuff with your colleagues on a whiteboard, too.

------
zwetan
I reject all that too, the recruitment process is broken, it's not even the
riddles it is the stupidity of some tests for the "less bright" companies.

But every problem is an opportunity :), now most of my freelance work are
companies who "had a problem and couldn't find anyone willing to solve it" and
me who asked "can I give it a shot?"

Showing you want to solve problem so far "works for me" much better than doing
the guinea pig with riddles

------
mixmastamyk
Same here, I've stopped doing tech interviews, they are a waste of time.
Hopefully my freelancing network will continue to grow and I can avoid them
forever.

~~~
JCDenton2052
Freelancers do no tech interviews?

~~~
protomyth
When I did freelance work, it was all about connections and reputation. "Hey
we got some problems with our overnight processing, you've done that before"
type stuff.

------
justinzollars
I think tech interviews are broken. I've been on both ends of the equation and
the process usually seems both unfair and random.

I work hard, get good reviews, have nice looking work that doesn't crash and
scales - and I can't interview either.

I've also interviewed great candidates that get shot for no reason at all.

That said, it is a numbers game, if you need a job keep at it - you have not
other choice.

But in the long term I think our community needs to chill out a little bit.

------
JCDenton2052
The prevalent thinking is that algorithmic skills transfer very well to other
problem-solving skills. This is especially the case in Google, Microsoft,
Facebook and Amazon who ask a lot of these questions. I do not necessarily
agree with it, but it is the way things are.

It's just another skill that can be acquired with proper effort and
concentration. I can recommend "Cracking the Code Interview", it is chock full
of these problems.

------
User23
"I oppose hiring practices that would exclude me." Really? How profound.

------
sigsergv
Modern interviews are metrics and every smart system (human/AI) will exploit
them. Metrics are always exploited. Job Interview is just another profession
that requires a lot of training and preparation.

------
watwut
I have read these threads for a while now and concluded that people are going
to complain no matter what companies do.

I think that while whiteboard nor algorithms nor random questions about
technology are perfect, they are still better then vague talking about how
passionate one is or variants of beer test. The issue with talking about good
code is similar - it matters whether you know the principles, but it is too
easy to fake by people who have more talking bluffing skills then anything
else.

Personally, I like the best when they tell me what they will ask for, so I can
prepare myself - whatever that is. That seems the most fair to me - good
programmer does not know everything fresh, but should be able to refresh or
learn something new reasonably fast.

------
brandon272
I have never, and would never subject myself to the types of sadistic games
masquerading as "hiring" that you see at a lot of software companies.

~~~
lj3
How do you find work?

~~~
brandon272
Most jobs in this world do not require a laborious interview process with
timed puzzles and riddles.

Bear in mind that the companies that do put people through that kind of thing
do it _because they can_. When you have people lined up down the street to
work for you, you can be very selective in who you hire and put them through
all kinds of skill tests before hiring, to triple check that they have the
requisite skills. Many (most?) companies do not have that luxury.

~~~
lj3
> Most jobs in this world

You're not US based then? Because I can say with some certainly that most
advertised jobs in the US absolutely do. Granted, most open jobs in the US
aren't advertised, but I haven't found a way to reliably find jobs that are
both open and unadvertised.

~~~
brandon272
Sorry, I was referring to literally most jobs, not just the ones in our
industry. Electricians, plumbers, writers, accountants, etc. are not typically
solving timed riddles and jumping through silly hoops to get their jobs. There
will be technical questions, yes, but for the most part their experience is
presumed and the employer assumes some risk by hiring them and having them go
through a probationary period.

------
segmondy
I'm truly sick of this rubbish that has been brewing lately. If you can't do
interview questions, your ability is questionable. The bar has been lowered
enough with the push of "everyone can code and should code" mentality. If we
want quality, we must raise the bar. Everyone can code, everyone should be
able to code if they want to. But everyone can't qualify for as a professional
software programmer. If the company has a standardized interview process and
everyone else gets asked the same set of questions, then it's fair. If you
can't answer or whiteboard it and other candidates could, Don't cry! Those
candidates obviously know more than you in regards to what the company is
looking for. Take the case of Google or Amazon, most of us can agree that they
have very smart folks working for them. If the filter these smart folks had to
go through was puzzles, math problems, algorithms, white boarding, then why
should anyone get an exception to join them?

Interviews are broken in most environment, and that doesn't mean we should do
away with them or make them easier. Rather, we should fix them, make them
better, and have them test what the candidate will be doing on the job. I see
people say, "you don't need to understand algorithm complexity to build a
website, or to know C or assembly" Sure! But you don't know what you don't
know! If you know and understand algorithm complexity, you will use it even
when building websites! You will think about scale. If you understand lower
level languages and you are using PHP, you might understand how your code
turns to C and how choices at a higher level turns to lower level. If you
never studied computer architecture, you wouldn't understand the magnitude
involved in fetching something from a register, processor cache, ram, drive,
over the network. Yet such things do rear their ugly heads when developing
these so called simple CRUD apps.

So if you are interviewing for a PHP programming position, and you get asked
about algorithm complexity or C or TCP/IP or other questions. Don't frown,
those are important questions, if you don't know it, you don't know it. It
doesn't mean you are a "bad programmer" but it does reveal that you are a
programmer without a wide breadth of knowledge. A one trick pony for the most
part. Get over it and widen your knowledge.

The other day I was using an external API that was crapping out. After hitting
a dead end, I informed the vendor and they said nothing was wrong. I did a
system call trace and noticed a lot of error was being returned on poll(), I
fired up tcpdump and noticed an abrupt and random FIN ending the connection.
With this I was able to convince the vendor to test their API from outside
their network, and once they did, they agreed that the issue was on their end
and they fixed it. This was a basic PHP app. Without a wide breath of
knowledge, I would have been stuck, no google or stackoverflow would have
solved this.

Great developers have knowledge that are wide and deep. If you fail an
interview, Don't get mad, get glad that you found your weakness and brush up
your skills.

------
jstewartmobile
I'm kind-of on the fence about this topic.

On the one hand, algorithms is a broad subject, so there's a large hole for
false-positives and false-negatives to slip through. Sometimes it's like
they'd pass on Gerry Spence as a trial attorney because he flubbed their
question on tax law.

On the other hand, can't totally drop the brain-teasers because you'll need
all the IQ points you can get before the corporate retardation sets in.

~~~
hughes
Does ability to solve brain-teasers correlate with a drop in "corporate
retardation"?

~~~
jstewartmobile
Everyone gets hit by the CR, so it probably doesn't hurt to start with a
higher baseline.

