
Ask HN: How to handle interview when you do not think like other programmers? - hnthrowsep2014
Throwaway account for obvious reasons. I&#x27;ve had a lifelong passion for coding. If I hit the lottery, I would be coding. Since about 4th grade, it&#x27;s all I&#x27;ve known.<p>I&#x27;ve never felt that I had the same &quot;goals&quot; as other programmers. I like to make stuff that solves a real, concrete problem. I like it when my code runs for a long time and doesn&#x27;t make any logic errors. I&#x27;m great at docs, debugging and code maintenance.  I love to learn, but I love to make stuff work.<p>I&#x27;m really good at reverse-engineering. I&#x27;ll use netstat to see who is talking to what, and on what ports, and at what times. I like to create documentation when it doesn&#x27;t exist or it is wrong. I like to share what I&#x27;ve learned. I&#x27;ll go to great lengths to get factual information.<p>I feel that I can do almost anything. If I don&#x27;t know something, I&#x27;ll go to great lengths to learn. If I need resources, I&#x27;ll find them. But I struggle to get my knowledge, talents, and passion across to other programmers.<p>For example:<p>Interviewer: Tell me about a project you did.<p>Me:	I saw a need in our business. There was valuable data in a system that no one could get to. The data was of great use to the business if the right people could see it. I wrote a Java program that connects to &lt;foo&gt; API and loads the data into &lt;bar&gt; database. I wrote some PHP pages to display charts and graphs based on my knowledge of the business problem domain. I profiled my code for memory leaks. I made it very fault-tolerant. The code I wrote stayed up for months at a time. I wrote several layers of monitors for the application. I get paged immediately on my phone if anything goes wrong. Everyone was thrilled.<p>Interviewer: What version of Java did you use?<p>Me:  1.7<p>Interviewer:	Why didn&#x27;t you use Java 1.8? It has lambda expressions. Why PHP? Why didn&#x27;t you use AngularJS? Clearly you don&#x27;t know how to code and are useless.<p>-----<p>I don&#x27;t know how to &quot;defend&quot; myself when the interview goes this way. What should I do?
======
patio11
There exist many companies which quietly make an awful lot of money and which
employ people much closer to you than to the stereotypical Silicon Valley
Mobifotosocialgame Hipster Programmer. Get a job at one of them.

~~~
mechanical_fish
Absolutely. There is nothing wrong with the interview that you describe. You
are learning exactly what you need to learn. Better to learn it today than six
weeks into the job.

It _is_ important to be polite, though, so to make it out of the room the
usual talking points are:

1\. "Our lousy platform was [mandated by management/chosen before I arrived],
but I cheerfully got the job done with the inferior tools at hand."

2\. "Our mission-critical legacy codebase made change difficult, but at least
it was stable and made the company millions of dollars."

3\. "I've heard of [interviewer's favorite magical tool] but I was so busy
holding the widget factory together that I never had the time to research it
and be sure it would solve my problem. Tell me more about [magic]! I've always
wanted to work with the sort of brilliant yet sensitive person who uses
[magic]."

Then shake hands, smile, leave the room, turn them down the next day, and get
a job with a company that values you.

(You may find, however, that talking point #3, a tactic that comes straight
from Dale Carnegie, makes your interviewers fall over themselves to hire you.
Everyone loves to be invited to explain their favorite things.)

~~~
jaf656s
This is great.

A lot of people forget that interviews are two-way streets.

If the company culture indicates that you won't be valued, look somewhere
else.

In this case specifically, I'd rather learn how to provide value than use some
shiny new tool. It's much easier to learn the new tool.. that can be done when
you need it.

------
keyneus
If the interviewer is truly confrontational (as in, you're being asked
something like "why did you do stupid thing A when thing B is clearly
better"), then you're better off not working there.

However, I'll often ask questions similar to those you posed (without
thinking/telling the candidate he's useless, of course).

Let's take the "why not Java 1.8" example. If I asked you that, and you were
prone to being defensive, you might think I'm attacking you. In reality,
though, I'm just probing for more information. Are you familiar with Java 1.8?
What would be the benefits/drawbacks of using it? If you can explain why Java
1.7 is fine for your project (I don't know Java, but I assume there are good
reasons not to use the latest version), then I'm satisfied.

Basically, my goal is to learn as much as I can about you. This often involves
direct questions. When I'm asking direct questions, I'm not attacking, and I
suspect it's the same for many interviewers.

------
blooberr
Wrong company / interviewer for you. Just move on.

That said, here's how I would answer: 1.7 because of legacy and potential
stability reasons, and I will evaluate 1.8. I need to make a case for upper
management and demonstrate there's a significant performance increase to
justify the time required.

Ask the interviewer what he's refactored recently with lambda expressions.

For PHP/AngularJS, you can always joke about PHP and how much you want to
switch to the next hip language. Unfortunately the mysterious previous
developer picked it and you have to stabilize it. You will switch..
(eventually.)

For Angular, just say there's 30 other frameworks and you will get to it in
due time. You can mess around and point the interviewer to that Todo list
examples ([http://todomvc.com/](http://todomvc.com/)) and ask him why not the
other 29?

You can always turn it around and ask them why they went with AngularJS
instead of some other framework.

When I interview engineers, I do ask why AngularJS? I do this because I'm
curious about their choices. Was it driven by hype or did they have a
legitimate problem that was solved by the framework? I'm trying to have a
technical discussion here and I'd rather do this than ask some random coding
question. Given the limited context of your experience, I can't tell if the
interviewer was being malicious or genuinely curious.

Hope this helps.

------
Someone1234
They just want you to explain your reasonings. They aren't really interested
in if you're "right" so much as how you got to your conclusion (e.g. "I
decided to use Java 1.7 because of XYZ.").

Random aside: You should look into Aerospace Engineering/programming. You
sound like you'd enjoy that type of development (functional programming, huge
amount of docs, huge amount of testing, entirely fault tolerant end to end,
etc).

~~~
x0x0
As an interviewer, if I heard

* someone picked java 1.7 because 1.8 is new and she or he wants to let some other suckers find all the crappy bugs in it (remember when 1.7 made lucene crap itself? I'm sure someone got to have some fun times with that, and I'm glad it wasn't me.)

* or she or he chose php because it was fast, easy, and had easy access to charting tools (I dunno if this is true or not) and for an internal dashboard what does it matter...

* I already know how to use it and can get the work done very quickly (always a _great_ reason); there's no such thing as software finished too soon

* the company already has a large codebase in X and I wanted to say in the same language, libs, and deployment tools

I love people who say I like to lag versions a year, because it means they've
been burned, learned the lesson, and want to let someone else do the
debugging. You'll more likely than not get a strong hire vote from me. As
parent said, it's about explaining why you picked something.

------
nostrademons
Don't bother. Target your applications toward the companies and roles that
value the same things you do. If an interviewer harps on Java 1.8 vs. Java 1.7
while you want to talk about reliability, netstat, and performance problems,
that's a sign that it's probably not a good fit for you.

"Not thinking like other programmers" is very often a good thing, but remember
that the world is very broad, and there are probably programmers out there who
think like you do. And even if you can't find them, there are also
organizations out there that respect and need different talents, and you
should find _those_.

------
CyberFonic
Seems to me that you were being interviewed by a technocrat not a business
person. My reading of the interview suggests to me that you are a person who
can see an opportunity for business improvement and implement a valuable and
reliable solution.

If this project is representative of how you look at the world, then maybe you
should be focusing on how you can solve business problems. That is you are
valuable for that level of insight and execution. Arguing over Java 1.7 vs 1.8
and PHP vs AngularJS doesn't increase business profits and doesn't recognise
your true skills.

------
bjourne
You should say "I used PHP because I wanted to use something I knew
completely, rather than learning something new with unknown properties wrt
fault tolerance." "I used Java 1.7 because Java 1.8 wasn't around at the time
for the platform we're targetting."

If you can't come up with answers like that on the fly, you have bad "people
skills" and are fucked. Interviewers doesn't care what technology choices you
made, they just want to see that you'll fit into whatever little herd of
programmers they are managing.

------
anonymoustwerp2
Ask the interviewer if he wants you to use your employment at his company to
learn the latest technology while working there so that you can leave for
higher-paying work, or does the interviewer have actual business-related
problems that need solving? Does the interviewer want to turn his company into
"programmer university", or does he actually want to get shit done? Does the
interviewer realize that the same problem can be solved in multiple other
technologies and techniques? Is the interviewer using HIS time there to turn
it into "personal programmer university" for himself so that he can bail soon,
and is looking for a co-dependent rationalization? Does the interviewer have
ACTUAL DATA showing that using the newer technology is: 1. faster to code, 2.
less risky to code with, 3. less expensive to find developers who know it?

Does the interviewer want to make the answer to the question that nobody
asked, or does he want to contribute to a company that has revenues?

------
hga
Actually, you sound very much like me, and I had a successful programming
career before becoming disabled. As noted by others, you perhaps could improve
your verbal interviewing skills, but interviews like this one are useful for
filtering out companies you'd be unhappy at (and I'd add a good fraction of
the technically doomed ones).

However I'll note that's one caveat to your "can do almost anything" concept:
learning new _paradigms_ , like functional programming if you only know
imperative and OO (for me, learning OO when I only knew the other two), can
take longer than most reasonable companies will be willing to give you.

Since you do know imperative and OO, if you don't know functional programming
it could be worth your while to learn it on your own. Try something like SICP
and you'll probably learn a few other worthwhile things.

------
1123581321
"1.7 met the needs of the project. We considered 1.8 but decided that it
wasn't necessary and that taking on the training costs during development, and
fracturing our platform, would not be a good trade-off to make."

------
bsg75
> I don't know how to "defend" myself when the interview goes this way.

Don't.

In the example above, I would not want to work with coders who think like
that, and it sounds like you would not want to either. So if you don't pass
their interview process, consider it a win!

Keep looking, and if you are capable, you will eventually find an environment
that fits.

------
reelgirl
I would listen to my inside voice. The statements made by the interviewer were
condescending and disrespectful. I would hold out for a company that respects
and values; and realizes the great qualities I hold.

------
read
Redirect the conversation to what's important.

Like (a) asking what problems the company has that need to be solved, (b) how
much more productive than the average software engineer you are, and (c) that
you are _determined_ : that you'll solve any problem, learning what you need
as you go.

When someone asks a silly question, like why Java 1.8 instead of 1.7, your
attitude shouldn't be to defend yourself as having made an Oscar-winning
choice. Your answer should be the most comical, borderline embarrassing
answer, because it will fulfill the possibly momentary psychological desire of
the interviewer to feel they are right. But it should also be an answer that
indirectly embarrasses the interviewer too for having asked it. You could say
Java 1.7 would have caused the least trouble, and then point out that e.g. if
you missed next week's release the company would have lost it's number one
customer and shut down.

Plus, if what the interviewer wants is to show off superiority, let them. If
you do that, you get the job. The interviewer isn't necessarily a bad person,
and they might realize how stupidly they acted and shapen up. (Of course don't
work there if they don't.) The more general advice is don't oppose forces, for
the same reason trees let themselves bend when it's windy.

If you are unsure or feel cornered over silly stuff, say "I'm not sure that's
the biggest problem to solve, or the one that will generate the most value for
the company." If you have ideas of what that is, then go on to describe them.

In short, push back.

But _don 't_ push back the way a suit pushes back with some general, phony
sounding, evasive statement like "well, I don't know how that affects some of
the stakeholders." Be _specific_.

(Don't think of pushing back as doing something bad. Think of it as being more
open-minded than the other person. You are considering data they are
neglecting. It's part of being a good designer. Corollary: make an effort to
consider other people's ideas, else you'll be the one who is narrow-minded.)

If I had only one piece of advice it would be: focus on the root of the
problem. Hint: more often than not it's not what it appears to be, but it's
some other problem hidden five layers deep.

For example, if an aggressive interviewer says "Clearly you don't know how to
code and are useless", then clearly the problem is the interviewer, and the
way you can pass the interview is to tell the truth. That he is the problem.
But -- to do it indirectly, with humor as a lubricant. Start from the very
first word: "clearly". Don't give them an inch.

You say something along the lines of: "Well, it's dangerous to make absolute
statements, you know, to say "clearly", or "always" or "never". Not just
because there's always a chance one could be wrong, but mostly because I
noticed with myself that when I do that it's often to counteract something I
subconsciously know is true. Else I wouldn't be finding the need to try hard
to qualify what I say. I'd just say it. And you know what, I regret it
eventually. It's strange how the subconscious works. I keep being surprised at
how things aren't always as they seem. But I'm willing to learn."

In this way you address the root of the problem: the interviewer is aggressive
without even realizing it. You identify how one can tell they are acting in
ways they haven't realized: by making absolute statements. You show humility:
you explain this is something that happened to you before. You allow for the
interviewer to feel superior: because you just explained a mistake you made.
You didn't budge; you stopped the conversation right on the first incorrect
word: "clearly". And indirectly you push back: by making the interviewer look
like a fool (because everything you just said about yourself could also be
said about the interviewer). The problem isn't the Java version. Don't talk at
all about any tech there.

Be humble. Be empathetic with people's faults. But the way out is following
the truth, even if that means that you made a mistake or you need to learn
something new. _ALWAYS_ look for the root of the problem. If it feels hard to
do, that's precisely your cue that you should do it.

And if the interviewer or company still don't get the hint, then forget about
them. They can't tell what's important.

------
_random_
"I like to make stuff that solves a real, concrete problem."

How does the idea of spending 30% of time on refactoring sound to you?

------
namelezz
Why are you trying to think like other programmers? Why aren't you trying to
find programmers that think like you?

------
pchristensen
FWIW every company I've worked at would be glad to hire someone that gave an
answer like the one you gave.

------
collyw
Your answer sounds pretty good to me. The interviewer sounds a bit of an
idiot.

------
isfd3oi43
I had interview similar to this last year. I was interviewing for back end
engineer. I know SQL, Java, Python and Data warehouse fairly well. Guy
interviewing was some Indian who always lives in his head. He started asking
me deep Administration questions when role was clearly for engineering. I know
some superficial DBA stuff but I am not DBA. Than rude stupid asshole was
clearly not paying attention when I was answering questions. This is not
something against Indian people but here is general piece of advice. \--> be
polite

\--> don't copy and ask questions posted on internet.

\--> don't live in your head and assume you know everything.

