3 ms·

I've noticed that isn't always true. I've sat on the other side of the interview desk, as it were, and one of the things that was always, ALWAYS a red flag, was

I've noticed that isn't always true. I've sat on the other side of the interview desk, as it were, and one of the things that was always, ALWAYS a red flag, was someone speaking with too much confidence about themselves. Obviously, yes, an interviewer prefers someone who knows the answers to every question asked. But an honest "I don't know/am not sure, but I think..." is a much, MUCH better answer than trying to bluff. If you're right after prefacing it with that, it's nearly as good as having bluffed correctly (the interviewer knows you didn't know or were not sure, but your knowledge of the tech is sufficiently good for you to deduce what unfamiliar constructs do), and if you're wrong, it counts nowhere nearly as badly against you as if you bluffed incorrectly (as you at least are showing you know and admit to what you don't know). Now, obviously this is also partly dependent on the level of knowledge needed to answer the question. If you are, say, applying for a Java job and don't know what private means, you're probably not getting the job. But if you're applying for a Java job, and are asked for the difference between soft, weak, and phantom references, and respond "I'm not sure...I know the first two have to do with keeping references to objects that should not prevent garbage collection, like when adding items to a cache or something, but I don't remember the difference between them, I'd need to look that up. And I've never heard of a phantom reference", and then asking about them if there are no follow up questions, is still pretty damn good. And "I don't know; I'd imagine from the name they have to do with referencing an object in a way opaque to the garbage collector?" is also very good. "I don't know" is okay, it just might mean we'd not be willing to hire you on as a senior dev, but if you nail everything else maybe one level below that.

Swizec 12y ago
> "I don't know/am not sure, but I think..." Coincidentally, this answer takes more confidence than bluffing. Bluffing is actually a signal of low confidence in a person. Too afraid to be wrong.
icambron 12y ago
A bit off-topic, but I've always avoided language-familiarity questions. If a candidate has coded a lot of, say, Java, then I do expect them to know the details and their importance, mostly because I expect people to care about the tools they use. But to begin with, I don't at all mind hiring people who have literally never once coded in the programming language my team uses. They'll learn, and that investment is worth it. Moreover, I suspect that trying to connect "how well do they understand Java's reference system?" directly to "what seniority of engineer should this person be?" is not very wise. The things to optimize for in a senior engineer are problem solving skills, organization, experience and comfort with technical tradeoffs, architectural wisdom, and so on. Over the course of the next, say, two years, you'll get a lot more mileage out of that; having deep familiarity with your language of choice is just a bonus.
- lostcolony 12y ago
  In general I agree. I only ever asked language familiarity questions if either, A. The job is explicitly frontend and we need someone already well informed (Javascript has a lot of gotchas, and HTML and CSS can be complex; backend experience doesn't directly translate), or B. It's about a technology (not just language) on the person's resume. If you put down you know X, you better expect questions about X. The questions were generally prefaced with asking the person how well they felt they knew the tech, too; it was as much a "does this person know what they say they know" as much as it was a "does this person know X". Reference type in Java isn't some esoteric library knowledge, either. It's not "tell me everything that implements the List interface" or something else as equally useless. If you want to build any sort of caching mechanism, you -really- ought to know about it, and if you're claiming great Java knowledge, and want to be in charge of delivering a Java product, it's reasonable to expect you to be familiar at least to when you might need to go read the Javadocs on those classes. If you were a junior programmer who just coded tasks as they were handed to you, and had code reviews, and you don't know it (and you admit that), that's not the kind of question I'd expect you to know. And if you don't claim to have much experience with Java, obviously asking you a Java question is silly; I'd ask you something about what you do use.
  - matchu 12y ago
    I often leave languages off of my resume for exactly that reason. I've used Scala before, and I'd feel comfortable using it again, but I certainly don't know it well enough to handle on-the-spot Scala questions.
    - lostcolony 12y ago
      And that's probably a good thing. That, or indicate it separately. "Some experience with..." or something, to show that "Hey, I've seen this, I've played with it, I've got some concepts down, but if you ask me about this I am totally going to demur". I can't speak to interviewers at large, and certainly, it ends up with recruiters trying to hire for those languages which is irritating, but I'd like to see it just to ask in what context you've used it. "Played with it in my spare time" is a plus in my book; it means you're actively curious.

Swizec 12y ago

> "I don't know/am not sure, but I think..." Coincidentally, this answer takes more confidence than bluffing. Bluffing is actually a signal of low confidence in a person. Too afraid to be wrong.

icambron 12y ago

A bit off-topic, but I've always avoided language-familiarity questions. If a candidate has coded a lot of, say, Java, then I do expect them to know the details and their importance, mostly because I expect people to care about the tools they use. But to begin with, I don't at all mind hiring people who have literally never once coded in the programming language my team uses. They'll learn, and that investment is worth it. Moreover, I suspect that trying to connect "how well do they understand Java's reference system?" directly to "what seniority of engineer should this person be?" is not very wise. The things to optimize for in a senior engineer are problem solving skills, organization, experience and comfort with technical tradeoffs, architectural wisdom, and so on. Over the course of the next, say, two years, you'll get a lot more mileage out of that; having deep familiarity with your language of choice is just a bonus.

lostcolony 12y ago
In general I agree. I only ever asked language familiarity questions if either, A. The job is explicitly frontend and we need someone already well informed (Javascript has a lot of gotchas, and HTML and CSS can be complex; backend experience doesn't directly translate), or B. It's about a technology (not just language) on the person's resume. If you put down you know X, you better expect questions about X. The questions were generally prefaced with asking the person how well they felt they knew the tech, too; it was as much a "does this person know what they say they know" as much as it was a "does this person know X". Reference type in Java isn't some esoteric library knowledge, either. It's not "tell me everything that implements the List interface" or something else as equally useless. If you want to build any sort of caching mechanism, you -really- ought to know about it, and if you're claiming great Java knowledge, and want to be in charge of delivering a Java product, it's reasonable to expect you to be familiar at least to when you might need to go read the Javadocs on those classes. If you were a junior programmer who just coded tasks as they were handed to you, and had code reviews, and you don't know it (and you admit that), that's not the kind of question I'd expect you to know. And if you don't claim to have much experience with Java, obviously asking you a Java question is silly; I'd ask you something about what you do use.
- matchu 12y ago
  I often leave languages off of my resume for exactly that reason. I've used Scala before, and I'd feel comfortable using it again, but I certainly don't know it well enough to handle on-the-spot Scala questions.
  - lostcolony 12y ago
    And that's probably a good thing. That, or indicate it separately. "Some experience with..." or something, to show that "Hey, I've seen this, I've played with it, I've got some concepts down, but if you ask me about this I am totally going to demur". I can't speak to interviewers at large, and certainly, it ends up with recruiters trying to hire for those languages which is irritating, but I'd like to see it just to ask in what context you've used it. "Played with it in my spare time" is a plus in my book; it means you're actively curious.