
Job interviews go both ways (2011) - wslh
http://diegobasch.com/job-interviews-go-both-ways-my-story-with-netscape-in-98
======
incision
The author advocates questioning the interviewer directly, but he doesn't
mention questioning anyone in his Netscape interview, only making mental notes
of various red flags.

In practice, I think that's the way 'both way' interviews generally have to go
- you don't interview your interviewer, but you do evaluate and judge your
potential employer critically.

Personally, my attempts at interviewing an interviewer have served to inform
my decision, but not at all due to the face-value of the responses as they're
generally going to be hard if not impossible to validate.

 _> 'Very rarely someone probes me to see if they would like to have me as
their boss.'_

I'd like to try that someday...

Who's the weakest person on your team? What do you mean to do about that?
When's the last time you lied to someone here? How did you rationalize it? Are
you on any medications? Do you cheat on your spouse? What are you most
insecure about?

The type of questions I'd _really_ like to know the answers to - the sort that
you learn the answers to within the first few months of any new job aren't the
sort that I'm likely to get answers to much less completely honest ones.

~~~
Iftheshoefits
Here are some that I've asked:

1\. "During your most recent budget period, what influence did politics rather
than the merits of budget requests have in distributing resources, and in what
ways?"

2\. "How heavily influenced by politics (or upper management) is the
performance review process?"

3\. "Has anybody recently been let go as the result of being ranked lowest on
a performance review?"

4\. "Are managers subject to performance improvement plans?"

5\. "When was the last time your HR department found in favor of an employee
over management or upper management when a dispute arose?"

There's a bias to these (if it isn't obvious). But experience informs me that
answers to these questions offer a good insight into how the company really
operates. If they are honest answers (they won't be, most of the time, if
they're answered at all).

~~~
MadMoogle
Existential question of the day: If the answers are almost all lies or
omissions, what's the point of asking the questions? To get good at spotting
the rare honest answer among the PR? And how do you know what's a lie and what
isn't? There's no way to verify anything they're telling you unless you know
somebody working there.

~~~
Iftheshoefits
That's a good summary of my view of the entire interview process, actually,
from both sides. The exception would be technical questions, of course--but
even those are only marginally more useful at determining anything more than
whether the candidate can answer specific questions under specific
circumstances, neither of which may actually ever arise during the course of
employment.

------
ranman
Sometimes. The potential employee is not always in a privileged position. I
think with most new grads this is the case (some with significant relevant
experience are excepted).

If I were interviewing a new grad or someone that didn't have a recommendation
(basically someone I didn't have any context for) and they asked me to solve a
technical problem, I don't think I would do it. I would not want to waste what
little time we had allotted trying to solve that.

If we did want to make a good technical match I think it would be great to sit
down and work on a low hanging fruit bug together.

------
Zelphyr
This is why I hate those services that have an automated pre-screen process.
The ones where you visit a specific URL and after reading the questions you
record a 30 second video with your answer.

The massive hole there is that I don't get to interview anyone the company to
see if I feel like its a good fit. I'm sure its saves them time but it wastes
mine.

~~~
rlu
Well to be fair, they likely get many more applicants than you have interviews
scheduled.

And it's just a pre-screen, right? It's not like you have to make your
decision right there and then if you do well in it.

~~~
Zelphyr
I don't disagree but it seems impersonal at best, rude at worst.

~~~
r00fus
Even worse (for the hiring team) - it's probably not that effective a filter.
You might as well use the "I only hire lucky people" filter [1].

Interviewing needs to be interactive because any decent job requires
interaction.

[1] [http://cream.hr/blog/why-the-hiring-system-is-
failing/](http://cream.hr/blog/why-the-hiring-system-is-failing/)

------
HarryHirsch
Did I ever mention that interview with a whizzo East Coast startup where the
interviewer couldn't answer where the company was planning to be in five years
time? It's one of those questions where they will squirm like eels, but you
have to know, because you are committing your time and future earnings to
them. Squirming is fine, but being struck dumb is not acceptable. The
experience was epic, it ended with a greybeard apologizing for the HR lady.

~~~
nevster
I always ask "Do you enjoy working here?" Their instant response is usually
telling.

~~~
typingduck
I always ask this. Doesn't even require an honest answer, the length of pause
is sufficient.

(although now it's been on HN interviewers will probably be better prepared)

~~~
nevster
At a guess, I'd put the chance that the person interviewing you has seen this
at about 0.1%

------
ChuckMcM
This is a really relevant piece, if I'm interviewing you I'm going to wonder
if you're not asking any questions about the company. I get that its hard to
ask challenging questions in a situation where you want to get hired, but you
will need to ask challenging questions when you don't want to get fired too,
and if you can do that you are more valuable than someone who can't.

That bit about everyone focused on the stock price also really resonated. Back
in the late 90's "everyone" was a millionaire, at least after all their stock
vested be that in 1, 4, and sometimes 5 years. Way more people than I expected
couldn't really handle that. The most common failure mode I saw was that
suddenly the person would do no productive work at all, and instead start
shopping airplane or yacht catalogs, or talking about where the best islands
to buy were with their co-workers. I once pointed out to a person that if they
did no more work, then the company's value would go to zero and knowing the
best islands would be a useless fact to know. But I had grown up in Las Vegas
(well spent my teen years there) and that was a town that taught people that
money is fleeting in a very brutal and efficient way.

~~~
rlu
I've never interviewed anyone, but also, if they don't ask me any questions
about the company then I'm gonna think they simply don't care and they applied
for the role "just for a job".

I don't want to work with people who don't care.

~~~
potatolicious
Eh, I have two rebuttals against that:

\- Is your job worth caring about? Let's be honest, not everyone is working on
putting people on Mars or pushing the boundaries of machine learning, etc. A
lot of programming jobs are just spitting out code for a paycheck.

When I was a tad younger, with less experience under my belt, and fewer
choices in employers, I interviewed at many a job where I was expected to act
like I'm deeply enthusiastic about jobs of little import to anyone and
technically amounted to not much more than flailing my arms at a keyboard for
8 hours a day. That expectation is ridiculous.

The mudane, boring jobs need to be done. Hire people who are capable and
willing.

This is a job, not a church.

\- One thing I've experienced are the grueling full-day interview process that
certain companies are a fan of (one such company rhymes with Blamazon).
Literally 7-8 hours straight of interviewing, even your lunch hour is yet
another interview. I don't think I've ever had intelligent questions by the
end of those. The questions I did have were answered by interviewers before
you, and at this point I've been thinking about manhole cover sizes, jelly
bean estimations, families crossing bridges, and regurgitating CLRS algorithms
solutions for so long I can't possibly come up with anything more.

Full-day cycles are grueling, and to expect candidates to be chipper and
operating at 100% (or even 80%) is unrealistic.

~~~
bcbrown
What I do is write down ahead of time 10ish questions, then ask each one of
2-3 interviewers. That will usually lead to one or two follow up questions,
and that's about enough. Yes, all-day interviews are grueling, but with
preparation I view the question-asking phase as a break.

------
asuffield
I always do this, but I play it subtle. My primary test of your ability as a
manager is your hiring process, because if you get hiring right then all other
problems are solvable. The question I am always asking myself is: do I want to
work with the worst person who can pass this interview?

------
herghost
I interviewed for a dev job a good many years ago. I hadn't heard of the
company at the time (they were pretty small so there was no reason that I
should have) so I did a lot of research. I remember that their financials were
looking decidedly bumpy, but almost always in the black.

I asked about this at the interview. The lady interviewing me looked offended
that I would ask about their financial situation as it was "not really
something [I] should be worrying about".

I didn't get the job, and their feedback was that they wanted a dev, not an
accountant.

~~~
nmcfarl
Bullet dodged.

Not assessing the financial situation of small employers pretty much has
always lead to them going bankrupt in my limited experience. And employers
unwilling to give any indications are the ones that leave paychecks un-funded
when they do (that was an SOs employer).

------
Hamatti
I think one reason for this (not asking enough questions) is that usually
early on your career, you don't really have that many options or you are in a
situation where you need to get your bills paid with any means necessary.

I have really never (yet) been in a situation where I would have really had
enough options to say no to any company offering a job after an interview. In
those cases, your full focus is getting them interested - not really about
knowing what kind of extra activities they do or what they are planning to be
in say 5 or 10 years.

------
7Figures2Commas
> It turns out, the majority of the people don’t do this. They simply put on
> their best face, answer every question and try to sell themselves. Some ask
> questions everyone should ask, such as the financial situation of the
> company. Very rarely someone probes me to see if they would like to have me
> as their boss.

It's funny. Lots of companies are going to increasingly great lengths to
filter candidates based on inane tests that _supposedly_ measure technical
competence, but many if not most of them do little to filter candidates based
on their apparent interest in the job opportunity as a whole.

Obviously, there are reasons candidates shy away from asking "tough" questions
other than "I don't really care", but startups in particular should be wary of
candidates who don't demonstrate a certain level of curiosity beyond the day-
to-day technical rigmarole.

Put simply, look to hire people who understand that interviews go both ways.

------
dmitri1981
One question I always ask my interviewers is "What is the best thing about
working here?". You can tell a lot by their immediate response and whether
their face lights up with excitement. One answer I will never forget is a
developer responding with "We have a Dyson hand dryer".

~~~
_mulder_
An equally interesting, and perhaps more useful, question I always follow that
with is "What's the worst thing about workign here"... The cop out answer is
usually 'it's a big company so you get some politics and inefficiencies'.. I
suppose a good follow up would be; "how does the company intend to change this
going forward?" or even "how does it compare to other places you've worked"

~~~
underwater
As an interviewer I loath that question.

Why would I invest my time interviewing you only to turn around and tell you
something that might make you decide not to work here.

~~~
fredophile
It depends on your priorities. Do you just need someone to come and fill a
spot or would you prefer someone that's actually a good mutual fit for the
role?

------
pawelkomarnicki
Huh I remember 2 interviews that I was sure I am never ever going to work at
the company :-) At one well-known-company interviewer literally treated me
like garbage from the very first minute (including waiting for the scheduled
meeting in the building corridor), I didn't even try to do say anything then.
Another one started pretty well, but then I saw the team (super demotivated)
and they asked me to do some shady test-stuff (HTTP referer header spoofing),
but the nail to the coffin was the manager telling me that I have to disregard
notice time and instantly jump ships for them, because they won't wait for me
;-) So yeah, the interview works both ways, there were jobs (like my current
one) that I felt that the fit is strong and the final negotiation effects are
not so important.

------
spopejoy
One aspect of "selling the candidates" that can be overlooked is the tech
interview. There's a big opportunity to demonstrate your own/your team's
technical excellence as a selling point.

What this is _not_ , is skewering someone on "j=j++ in a loop" trick
questions, or dryly sacrificing them on the algorithmic altar. Programming is
supposed to be interesting, so it should be interesting to dive into
fundamentals, language issues, library specifics or whatever, and keep
drilling to the edge of the candidate's knowledge, and beyond.

The hope is, the good candidates get grilled a little, and walk out thinking
"I could learn something here."

~~~
dllthomas
Yeah, 'cause language issues and library specifics are far more interesting
than dry algorithms.

This seems bass-ackwards. Library specifics, and to a certain degree language
issues, are exceedingly amenable to recourse to documentation. An
understanding of algorithms, less so.

~~~
spopejoy
I don't mean to knock algo questions, especially not complexity and data
structures.

I do think language and library fundamentals get overlooked, for the very
reasons you mention: yes you can google pass-by-value and consult docs about a
TreeSet ... but the good programmers don't, they already know when/how/why and
don't forget it after a year of doing something else.

~~~
dllthomas
For sufficiently fundamental fundamentals, I'd agree. I'd certainly include
pass-by-value vs. -reference vs. -name in that. I strongly dispute the notion
that good programmers don't consult library docs. Library surface area is
_huge_ , particularly in batteries-included languages. One should know well
the areas they use, but there will be plenty outside that, especially if
they're moving between many languages.

------
js2
I guess I've interviewed over a hundred candidates over the years. I always
end with: is there anything you'd like to ask me? I can't recall a single
meaningful conversation that ensued as a result.

~~~
carrotleads
During my noob days my questions were always about 1\. Work times 2\. Dress
code 3\. Questions of growth in company

As I got exposure it moved on to 1\. Specific question on potential growth 2\.
Companies market position risks/challenges and their actions/plans

But I have not asked hard questions that a few have outlined here. Hopefully I
don't have to :)

------
pyfish
I always interview the company interviewing me. The closer I've mimicked Peter
Gibbons from Office Space the quicker the job offer arrived, provided I passed
their tech tests.

------
mycodebreaks
The way interviews are conducted, mostly, you are left with a little time at
the end. Interviewer will ask you to solve a problem, write code for it.
Either the time is just enough for you to solve it, or if you finish too fast,
there will be a next question thrown at you.In either case, not enough to have
a meaningful short conversation followed by a question, which is sad.

------
braydenjw
It's funny that this article states that it originally came from the IndexTank
blog, and the creator of IndexTank just responded to an AskHN questions a few
hours ago.

[https://news.ycombinator.com/item?id=7977188](https://news.ycombinator.com/item?id=7977188)

------
sgwizdak
Huh, I was asked that very same tree traversal question at an interview
recently.

~~~
brianwillis
Can anyone outline a solution? The only ones I can come up with off the top of
my head involve using a stack.

~~~
Yen
In my opinion, it's a somewhat misleading question (or the answer is creative
to the point of stretching definitions).

In-order traversal is pretty easy without a stack, if every node keeps track
of its parent. 1\. go down left branches until you get to a leaf. 2\. visit
leaf, and go up. 3a. if, in going up, you were at a left child, visit this
node, then go right. loop to 1. 3b. if, in going up, you were at a right
child, go up again. loop to 3. 3c. if you can't go up, you're done.

The trick comes from not really storing the parent pointer at each node, but
instead doing trickery with xor-ing various addresses together so that you can
store 3 pointers in the space of 2 (plus possibly an extra bit).

Of course, if you do so, you've constructed something that's not exactly a
binary tree, and can only be traversed in certain fashions where you'll always
have the necessary information to xor.

------
par
I like this idea but usually interviewers leave me with such little time that
it would be unreasonable or impossible to do such a dive with the interviewer.

------
adrianb
So why is EOF in C defined as -1 (when it is)?

~~~
berdario
If I had to guess:

prematurely ending a stream is a problem for the current stream, and for the
next stream as well, and thus is more desiderable to avoid corruption in bytes
signaling an EOF than other bytes.

corrupting an EOF in something else is probably not as bad, and/or maybe a
corruption 1->0 is more likely than a bit flip 0->1 (maybe when
stored/transmitted as 1==higher voltage) and thus

01111111 10111111 11011111 11101111 11110111 11111011 11111101 11111110

are less likely to be corrupted into a EOF, if 11111111 is the least likely
state for a byte to be in.

Also, not one of these bytes is a printable ASCII character, which might thus
possibly be/have been much less frequent in data streams, and thus further
reducing the likelihood the probability of such a corruption happening.

~~~
jerf
While a nifty idea, corruption of this sort is so rare and so unbounded (that
is, there's no reason to believe it'll strike in your incoming data, it could
well strike at the CPU instructions itself or whoknows) that there's not much
you can do about it from inside the code. It's all but impossible to deal with
corruption rates on the order of 1 in 10^18 (or better! properly functioning
hardware is obscenely reliable at doing what it was designed to do [1])
instructions on properly functioning hardware, and all but impossible to deal
with failing instructions at a much higher rate on nonfunctioning hardware,
except to replace it with functioning hardware.

[1]: If anyone wants to pop up with complaints about that statement, remember
that properly functioning hardware is also doing a lot of things very quickly,
so it has a lot of chances to fail. ECC RAM is important, for instance,
because something that only happens every few billion accesses may still
happen several times a day. But this is still an absolutely obscene degree of
reliability. Most disciplines would laugh at worrying about something at that
rate of occurrence... they wouldn't even be able to detect it.

