8 ms·

But to get hired in the first place you have to show overconfidence in your knowledge and abilities. Slightly annoying how that works.

by warcode 12y ago

davis 12y ago
I disagree. I could concede and agree that a bit of confidence is needed, but certainly not overconfidence.
dspillett 12y ago
Aye: good experience breads opportunities to gain good experience. 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.
- deleted 12y ago
  [deleted]
opendais 12y ago
> But to get hired in the first place you have to show overconfidence in your knowledge and abilities. 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.
- lostcolony 12y ago
  I've asked that. "On a scale of 1 to 10, how fluent do you feel in X?" And the questions asked get partially tailored to that. Anyone answering 9 or 10 is in for it.
  - opendais 12y ago
    I'm sure it is different between interviewers. I was just providing an anecdote where it could be a bad idea. 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.
  - icambron 12y ago
    I'm genuinely curious what you're testing with that. Is the idea to see how their scale of fluency matches up with yours, or to see if--assuming they use a reasonably similar scale as you--their self-evaluation if is accurate? If it's the latter, I agree overconfidence is a shortcoming, but it seems odd to structure the interview around sussing that out, especially given that the candidate may be only artificially overconfident because they think that's good for interviews. It feels more like a "gotcha!" than a genuine attempt to determine the candidate's quality. If it's the former (finding out what the candidate thinks "really good at X" means), that sounds interesting, but I don't quite get it.
    - lostcolony 12y ago
      It actually doesn't matter what the goalposts are very much. I've seen it asked with explicit goalposts, but it didn't seem to change anything except readjusting the goalposts; you could still infer the intent. "1 is a complete newbie, 10 means you helped write or at least have memorized the specification" just means the real scale is now 3-8, and they'll pick from there, scale accordingly. That said, someone who asks gains a point right off, as it were. 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.
lostcolony 12y ago
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.
josephschmoe 12y ago
The two are not mutually exclusive. You can be overconfident and ask for help. I mean - I'm an expert on what I know, not what I don't know, ya know?

But to get hired in the first place you have to show overconfidence in your knowledge and abilities. Slightly annoying how that works.

by warcode 12y ago

But to get hired in the first place you have to show overconfidence in your knowledge and abilities. Slightly annoying how that works.

davis 12y ago

I disagree. I could concede and agree that a bit of confidence is needed, but certainly not overconfidence.

dspillett 12y ago

Aye: good experience breads opportunities to gain good experience. 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.

deleted 12y ago
[deleted]

opendais 12y ago

> But to get hired in the first place you have to show overconfidence in your knowledge and abilities. 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.

lostcolony 12y ago
I've asked that. "On a scale of 1 to 10, how fluent do you feel in X?" And the questions asked get partially tailored to that. Anyone answering 9 or 10 is in for it.
- opendais 12y ago
  I'm sure it is different between interviewers. I was just providing an anecdote where it could be a bad idea. 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.
- icambron 12y ago
  I'm genuinely curious what you're testing with that. Is the idea to see how their scale of fluency matches up with yours, or to see if--assuming they use a reasonably similar scale as you--their self-evaluation if is accurate? If it's the latter, I agree overconfidence is a shortcoming, but it seems odd to structure the interview around sussing that out, especially given that the candidate may be only artificially overconfident because they think that's good for interviews. It feels more like a "gotcha!" than a genuine attempt to determine the candidate's quality. If it's the former (finding out what the candidate thinks "really good at X" means), that sounds interesting, but I don't quite get it.
  - lostcolony 12y ago
    It actually doesn't matter what the goalposts are very much. I've seen it asked with explicit goalposts, but it didn't seem to change anything except readjusting the goalposts; you could still infer the intent. "1 is a complete newbie, 10 means you helped write or at least have memorized the specification" just means the real scale is now 3-8, and they'll pick from there, scale accordingly. That said, someone who asks gains a point right off, as it were. 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.

lostcolony 12y ago

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.

josephschmoe 12y ago

The two are not mutually exclusive. You can be overconfident and ask for help. I mean - I'm an expert on what I know, not what I don't know, ya know?