But to get hired in the first place you have to show overconfidence in your knowledge and abilities.
Slightly annoying how that works.
Slightly annoying how that works.
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.
Coincidentally, this answer takes more confidence than bluffing. Bluffing is actually a signal of low confidence in a person. Too afraid to be wrong.
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.
I've had interviewers literally tell me that "Ya, that was a trick question to see if you thought you were god's gift to programming. The fact you didn't rate yourself a 9 or 10 proves that you are sensible."
So I'm not sure that is true.
I think it is a question of being confident enough that you don't second guess yourself yet humble enough that people don't think you have an ego that will cause workplace drama.
Anyone answering 9 or 10 is in for it.
I'm pretty sure the reason I elicited that reaction was I have a statement on my resume about a project I work on at my current job that handles as many transactions [in terms of $$] as that entire company does.
That is just a guess on my part tho.
It's intended to view their confidence. As someone else posted, the older they've gotten, the lower they'd score. That's because as they've gotten more experience, they've had more of those "...wow, this code someone else wrote is so much better than mine" and "Oh man, this code I wrote 6 months ago is -terrible-", etc.
Someone who says "I'm a ten!", it doesn't matter what they think the goalpost is, the are the best they can imagine, which either means they are great (hence seeing how they answer on the followup questions), or it means they aren't, but they've never seen better...which means they aren't out learning, be it from other devs they work with, open source code, whatever. Throw them some hard questions, see how they answer. If they do well, snap them up, as they're good and they know it; if they do poorly, you may want to pass (a lot of the worst performing candidates I've seen ranked themselves 8-10 in a technology).
Someone who says "I'm a 3 maybe" probably means they are passably fluent, but they haven't done much with it, and they recognize it. Feel them out some easy questions first, and expect that if you need them to use this language there will be some mentoring and/or time needed to get them up to speed, but they'll probably be willing to learn given that they applied, and recognize they don't know it well.
Someone who says "I'd like to think I'm an 8, but most days I probably code more at a 6" means they're probably quite good with that language, but also quite realistic, and have had experience with requirements changing, making hard decisions due to delivery dates, have worked with a lot of libraries and people and seen some who are better, some who are worse. Start with intermediate questions and go from there.
It has no direct bearing on passing/failing the interview, it's just used to set the tone and expectations of the interview. If we have multiple positions open, it might be taken in conjunction with how you do to determine what position is offered, as well.
He rated himself 10/10 for Javascript, so I asked what he'd done with the language.
He replied "I've validated forms."
I was expecting more to say the least.
Put another way, someone who rates himself a 10 because he's the best in his CS class is someone who doesn't know what he doesn't know, and is also likely to be a primadonna. Someone who shows some thoughtfulness, skepticism, and humility when answering this question is more mature and self-aware, and is much more likely to be an effective part of the team. The rest of the interview is supposed to establish how much they actually know.
Project the question into another domain - "I passed my intro Spanish class", "Oh yeah, on a scale of 1 to 10 how fluent are you in Spanish?", "I'm a 10". Nope.
It's like the difference between being fluent in Spanish and being able to use the language to write moving poetry or having a very extensive vocabulary.
I think it is much better to be as specific as possible about what skills you expect the candidate to have going in and what you expect them to be able to learn on the job.
I'm pointing out it does happen and its specifically intended to locate potentially overconfident people and needle them.
Though depending where you are starting from and trying to head to, there are ways that you can try to short-circuit this. If trying to move sideways into a technical role from another (or something else entirely) for instance then taking professional certifications in your own time can be useful for proving to a potential new employer that you really know+understand the skill that you believe you might have. The trick is finding something that actually means something to your target, which can be a black art (in the Microsoft ecosystem for instance the MCSA and MCSE qualifications can mean a lot to some, but little to others, and sometimes nothing without some commercial experience to back it up).
> overconfidence
I don't think this is about promoting overconfidence, more avoiding the underconfidence that comes from misjudging how capable other people are relative to yourself.