Ask HN: Is saying "I don't know during an interview" something negative? | Hacker News Reader

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

21 pointsorangethirty32 comments

Hello,

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.

Did I make a mistake by being honest and should have just googled for the answer?

Please give me your insight because I'm just confused by the whole thing.

View on HN

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.

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.

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.

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.

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

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.

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.

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

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

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 :-)

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.

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.

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.

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.

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.

Companies bluff / lie all the time. It's a problem only if you can't deliver in the end. I once made a development career change pretending to know the new stuff. I figured it out in timely fashion and no one was the wiser.

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.

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.

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.

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)

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.

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.

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.

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

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.

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.

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.

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.

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

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?

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

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.

Reply on news.ycombinator.com