

Ask HN: Is saying "I don't know during an interview" something negative?  - orangethirty

Hello,<p>I just interviewed for a position doing PHP/codeigniter. One of the technical questions I was asked had me working with multi-dimensional arrays. This is an area where I have not had much need to work with in the past.
I could not complete the whole exercise. I was honest and did not cheat by asking for a solution at some web forum. I did not get the job due to not being able to do this.<p>Did I make a mistake by being honest and should have just googled for the answer?<p>Please give me your insight because I'm just confused by the whole thing.
======
debacle
1\. It's always best to be honest.

2\. If you don't know how to work with multidimensional arrays, you really
need to learn. It's something I would consider a core skill for a programmer.

3\. If you're competent at all, it would have only taken a few minutes of
googling to figure out the right solution. Multidimensional arrays are very
easy to work with in PHP.

------
brandoncordell
It's not a bad thing to say "I don't know" to some things. In this case though
(and please don't take any offense) any intermediate PHP developer should know
how to work with multi-dimensional arrays. That should be part of any PHP
developers immediate skill set (the set of skills you can reach into your
brain and pull out at any time).

It's such a common element of PHP development. This probably came off to your
interviewer as "he hasn't worked with PHP much" because of how common they
are.

~~~
redspark
Agreed, when I read that you didn't have much experience with multi-
dimensional arrays, the first thing that came to my mind was "He is pretty new
to PHP".

I don't see how you could have built any substantial project in CI/PHP without
coming across them.

That being said, I think saying I don't know is fine, but be aware of how you
say it. If it is a shrugging "I don't know", that would be bad. A positive "I
don't know yet", would show you are being honest and willing to educate
yourself.

~~~
orangethirty
I said I don't lnow but I kept hacking at it. Its not like I quit. Maybe it
wasn't the right job for me. I see the whole experience as positive.

~~~
redspark
Same as landing a plane. Any experience you can learn from is a good one!

------
whichdan
You should absolutely spend a day or two working with multi-dimensional
arrays. It really is a core skill, like debacle said.

A few simple things you can try:

\- Design a database for a forum. Use PHP to pull a list of Users. For each
User, pull the top 5 Posts, and for each Post, pull the Topic they posted in,
and for each topic, pull the most recent Post and User who replied. That's 3
levels deep.

\- Create a list of 10 major Cities in your country, and for each City, list
the Average, High, and Low temperatures for two different Dates. That's 2
levels deep.

\- Create a database for a store. For each Product, pull a list of the 10 most
recent Purchases. For each Purchase, pull the User, and for each User, pull a
list of their 10 most recent Purchases, and for each of these Purchases, pull
the Products that were Purchased. That's 4 levels deep.

These are all very real-world scenarios, and if you can design and code them
all, you'll have no problems working with any other multi-dimensional arrays.

I would also highly recommend writing the code to display the data from each
array in a hierarchical table, and make sure you know how to access a single
value directly, such as the Lowest temperature for a given Date in a City.

~~~
orangethirty
I can do that with no problem. That is why it is frustrating. Nerves got the
best of me. That is why I said I don't know. I was nervous. And under the
circumstances I did not know the answer. But later on I went and did the
exercise by myself with not much hassle.

~~~
whichdan
So the moral of the story is: keep interviewing until you start feeling
confident :)

~~~
orangethirty
Well, you have opened up my eyes. Thank you.

------
yShrike
FWIW, when I interview technical candidates, I ask technical questions until I
get to the point where the candidate says "I'm not sure" or "I don't know".
That helps me understand where the are in their career. If a candidate knows
everything then they're not being honest with me :-)

~~~
zwieback
That's what I do and then pay close attention what they do when we hit that
point. Ideally, the candidate will explain what they would do. If we have
enough time then I want them to ask me to explain the answer to them, that
tells me they are actually curious enough to fill in their gaps.

------
evilmoo
Whilst interviewing SysAdmin candidates, I prefer an answer along the lines
of: "I don't know, but I'd do x,y and z to find out"

Instead of guessing and potentially being very wrong and breaking things.

Be honest, but prove you're smart by showing how you'd get to the answer.

~~~
jrussbowman
This is exactly what I look for when interviewing sysadmin candidates as well.
I'm not sure how well this transfers over to programming though. The actual
question was't posted, but in general working with multi-dimensional arrays is
a standard part of PHP programming in my opinion.

Therefore the interviewer could have decided that the applicant didn't have
enough base experience for the position they were applying for because of
that.

Translating this to a sysadmin candidate. If I were interviewing someone for a
Systems Administrator III position focusing on Linux and they couldn't answer
basic DNS questions, such as A vs CNAME record I'd be inclined to believe they
haven't done enough server and application builds to qualify for a III. IF
they were applying for a devops position and couldn't cover the basics of
named based virtualhosts in apache, that might be another indicator.

I don't know is the right answer always. It's a lot worse for a company to
hire you because you are able to fluff the answers in an interview and then
not be able to perform once you have the job. It creates stress on you and on
the team you join. It's especially more negative when you have to once again
go looking for a job and explain why your most recent position experience was
so short.

To the original poster, as others have said, you got a leg up here. You know
specifically what you missed during the interview so now you have an
opportunity to go focus on an are you've identified yourself as weak on so you
can pass the next interview honestly.

------
tagawa
No, you did not make a mistake by being honest. If you'd have fluffed it or
lied you would have either made yourself look stupid or found yourself in a
position that doesn't suit you at present.

Be honest and in the long term it will be the right decision. And learn about
multi-dimensional arrays - they're super useful.

~~~
nsxwolf
Sometimes a good candidate has surprising gaps in their knowledge that can be
filled in with some quick remediation. Ethics of lying aside, a sink-or-swim
type may be able to succeed in the job in this case.

------
ritchiea
When I interviewed for junior dev roles I answered "I don't know" to questions
during multiple job interviews and still got offers after those interviews.
Usually after answering that I don't know something I would ask the
interviewer how he would handle the proposed problem. My best advice would be
if you don't know don't be afraid but have poise and show that you're eager to
learn and willing to ask questions.

------
josephturnip
Most of the interviews I've given are broken down into two sections: does the
candidate have an effective baseline understanding of the technologies
involved in the proposed job, and can they apply that understanding to complex
problems?

If a candidate says "I don't know" during the first part, it's a sign that
they will flounder during the second part. However, I usually guide the
questions to try and actively FIND the "I don't know" point for the second
part, as it helps me establish the boundary of their abilities.

------
tokenizer
Part of your job as a developer is to find the right answer. It's not cheating
if you can do it on the job. Just because you don't have the knowledge on hand
doesn't mean you can't wade through and disseminate the correct solution via
Google quickly.

Now if this was a phone interview and not some take home style assignment, I
would've done the same as you and said, "I don't know that right now", and
then give your best educated guess. Best of luck next time.

------
tonyfortunato
I'm an engineer, not a programmer so take this with a grain of salt. Flat out
saying "I don't know might" be seen as a negative, but saying "I don't know,
but here is what I'm thinking..." or "I don't know, but I would try this, this
and that" to find out would be something I wouldn't necessarily penalize, and
would more likely be happy to hear.

In most technical jobs (the good ones anyways), you aren't expected to know
everything off the top of your head. You are however, being paid to solve
problems, and that means knowing how to talk about them with others, and how
to go about looking for answers. Like many others have said, keep honest, but
also show that you can talk with others, and reason about problems, even if
you don't know an answer offhand.

All that being said, from what I gather, it sounds like multidimensional
arrays in PHP may be something you want to look into. It sounds like this
might be one of the easier things to work with in PHP. (I hope you don't take
offense. I'm not a PHP dev., but it's just the impression I get from the other
comments)

------
joubert
Lots of good advice below. I'll add something that you might find useful for
your interview process. If you really really want to work at company A, get
some practice interviewing at 2 or so other companies, for similar positions,
first. It will help you hone your technical and social interviewing skills and
by the time you get to the desired interview, should fare better than if you
went in cold.

------
grumps
My only suggestion would be to not say I don't know. It would be "I'm not so
familiar with XYZ, but here's how I'd solve that." Of course, if you can
follow that up with an example of a similar situation mitigates some of the
risk. This would assume that it's not considered to be a core skill set. If it
's fringe skill you should still be in the running.

------
EvilTerran
If the technical question was in a "take-home exam", as it were, or you
otherwise had access to the internet, I'd figure you could look things up at
will; to be on the safe side, perhaps ask "mind if I use php.net?". It's only
reasonable -- you'd have access to the documentation when working in the
field, after all.

Being a good programmer isn't about knowing absolutely everything about the
tools you're using, that'd be impossible -- being able to look up things you
don't know is a very important skill.

If, in a face-to-face interview, I were faced with something I didn't know,
I'd say something like "I can't remember quite how this bit works, but I'd
look it up on php.net/developer.mozilla.org/api.jquery.com/[appropriate
reference]. Do you mind if I use pseudocode for the sake of getting on with
the rest of the problem?" -- thus showing honesty, humility, the ability to
use the resources available to you, _and_ expedience.

~~~
orangethirty
I did do the process you described. It has been a great learning experience,
and has made me a better person overall.

------
alainc
I recently posted a job opening. When I reached out to one of the applicants,
he said he was worried that his knowledge wasn't as deep in some of the areas
I wanted.

That honesty got him an on-site interview.

That interview, reference checks, etc., got him the job. He starts on Monday.

------
dspeyer
If I were interviewing you and you said "I don't know" I would say "try to
work it out". Jumping ahead and saying "I don't know but I think I can
probably..." will earn you a few extra points.

I recall one interview where I asked what sort of responses an HTTP GET might
result in. The candidate knew 200 and 404 but that was about it. Then I asked,
"If you were writing the HTTP standard, what other responses might you
include" and he told me about HTTP 304 Not Modified and the related cache-*
headers, which he was clearly re-inventing on the spot. I scored him very
highly for that.

------
PaulHoule
I've interviewed a few times for "data scientist" positions lately and I found
the two answers that get you out of most trouble are:

#1 look it up in a hashtable, and #2 look it up in the literature

"look it up in the literature" is the answer you're really going to use on the
job, so be proudof it.

------
WalterBright
An educated man is not one who knows a lot of things, but one who knows how to
find out what he needs to know.

I think Henry Ford said that.

------
edwingustafson
Answer with pseudocode if you have to, it will show your mastery of the
concepts.

------
aw4y
if they give you a connection during the test...maybe they want to check also
if you can search and find a solution when you don't know how to do something.
is it possible?

------
lightblade
Best to say you don't know, than trying to BS your way through.

------
zupreme
When I interview technical candidates I follow the following process:

1) Ask them to rate their own skills based on the areas of focus found in
their resume

2) Completely skip the areas they have self-identified themselves as beginners
in

3) Drill them on the areas they self-identified as experts/advanced to
validate the claims

4) Spend the bulk of the technical interview discussing the areas they
identified themselves as "intermediate" in to identify where they want to go
with their career and training as well as to assess their potential for
getting there.

After all that I compare their perceived strength, weaknesses, and interests
against the needs of the position and make a determination based on that.

The formula I use to assess skills can be expressed as: S = (SA * 5) + (SI *
2) - (FA * 10) - (FI * 4)

SA represents skills validated as advanced, SI represents skills validated as
intermediate, FA represents skills claimed as advanced, but not proven to be
valid, FA represents skills claimed as intermediate, but not proven to be
valid.

