5 ms·

I've always appreciated interviewing job candidates that would respond with an honest "Hmm, I actually don't know" rather than trying to BS their way through a

I've always appreciated interviewing job candidates that would respond with an honest "Hmm, I actually don't know" rather than trying to BS their way through a question for which they obviously didn't know the answer. Expecting even great developers to know 100% of everything is unrealistic.

fat0wl 13y ago
Oh mannnnnnnn do I wish I met some more interviewers like you. I have mounds of experience with programming but not all of it is web-focused, and when I went through interviews I was constantly shut down because I didn't know a particular js or testing framework (RoR world, where there isn't a prescribed consistent stack that is generally used on all projects). Finally I got to a corporation who looked at my track record & audio master's degree, said "damn you must be smart!" & hired me on the spot. I had finally gotten an offer for an RoR position as well at almost the same time but I can't tell you how many interviewers flat-out turned me down for not knowing some random piece of pseudo-hobbyist tech. Anyone applying for a job in one of those ecosystems should spend ~3 hrs a day Googling these things & coming up with some talking points. I wish I could recommend just saying "I don't know" but I can tell you most interviewers don't get it. Better to just say a couple cursory things you read on the library's wiki page, then "I haven't used it in production though..."
- ctide 13y ago
  'I don't know' is never a good answer. If someone asks you about some specific javascript testing framework, for example, and your answer is simply 'I don't know', that implies that you know nothing about javascript testing. Replying 'I don't know about X, but I've worked with Y in the past, and heard about Z' is an answer that shows that you are familiar with the problem space, which is vastly more important than knowing some random piece of tech.
  - fat0wl 13y ago
    heh I agree with you conceptually but I've been in talks that are like (given X is a concept/library/framework) "I don't know about X, but --" "Oh you don't know about X? We don't want to know or understand anything about people who don't BELIEVE in X. You're disGUSting!" But I never said I personally don't agree with the technique... so the response I go with is "Well, I agree with the philosophy there but my previous employers didn't budget any time for X." which they seem to absolutely hate anyway. The reason I ultimately went corporate was because the hiring practices were more algorithm/concept-based (web services, AJAX practices, software design principles) rather than library or language-specific. I was hired into a Java team without even knowing Java. About 3 months later I found I could program on any part of their stack if they really needed me to. Hiring practices that are not based on assessing a candidate's capabilities strike me as egotistical and pessimistic. I'm going to keep reading theoretical Comp Sci texts to see if I can get to the next phase of my career rather than joining the learn-every-framwork-under-the-sun-OR-ELSE movement.
    - mattmanser 13y ago
      Look at it another way. Would you have wanted to work with people who are so short-sighted anyway? As anyone who conceptually can't understand that it doesn't matter that JS testing framework 1 is going to be similar to testing frameworks 2, 3 & 4 is probably going to be populated by a whole load of crap, probably mono-linguistic, developers. A lot of development jobs & the developers that work in those jobs, suck. And they're going to be pretty painful if you care about code. I was at a talk last night and the speaker was talking about how to help new developers when they first start in a company and he started going on about giving the new developers access to the live servers & FTPing the changes to the live server, etc., etc. All I could think is 'right, that company is now a never work for, avoid people who have worked there'. No automated deployment? Having to give new developers access to live servers? In 2013? Pathetic.
  - mhurron 13y ago
    When people say you shouldn't be afraid to say I don't know they don't mean say 'I don't know' and then stare in silence at the person asking the question. How you phrase the whole response is important, as it is with every response in an interview, but what more people need to realize that the phrase 'I don't know' is not something that should never be uttered or admitted.
  - forrestthewoods 13y ago
    I think "I don't know" can be a perfectly acceptable answer. It's certainly preferable to awkward grasping at straws. I don't expect even a great candidate to answer every question. Sometimes questions are simple probes to find bounds of knowledge and experience. I know a lot about game development. I've shipped quite a few games. I've worked on PC, consoles, iOS, gameplay, engines, clients, game servers, and more. I've never worked on the server backend infrastructure, graphics programmer, nor have I used Unity3D. If you ask me a real question about SQL or database management just about the only answer I can give you is "I don't know". I can't to tell you any differences, pros, or cons related to any javascript library nor any of the now numerous popular databases.
- danielweber 13y ago
  Employers generally suck. They want someone who already knows, or lies about knowing, their pet 12 technologies, but then they aren't using 6 of them at all. And there is very little brand new stuff out there. If you've been around the block a few times, you recognize the patterns of what something does quickly enough.
  - fat0wl 13y ago
    My sentiments exactly. If they have a well-built internal library that is heavy on specific design patterns I'd expect them to give me a hard time over it because I could break some serious stuff or waste a ton of money writing ineffective code. Or maybe if they use heavy black-box builder tools that require some delicate coding to leverage the power of the internals. (In this case again, though, it's still dangerous to hire based on experience with a specific tool because you may get spaghetti code that happens to work within the confines of that tool -- trust me I've seen it.) But open source frameworks & js libraries are much closer to the realm of pet tech. The internals aren't too heavy & conceptually difficult, and most of the classes I see being written by developers are pretty run-of-the-mill regardless of the language/framework. The strange thing is that often the fact that companies are so up-to-date with current trends gives away the fact that they are writing tons of throwaway code. Nobody is maintaining a really mature library that depends on a framework that has been stable for 4 months. Employers would never admit that though, lol.
mkramlich 13y ago
I hear you. But the flip side to that is that probably comes from a hiring/recruiting/interviewing culture that features this anti-pattern: "Let's see here, you've done C programming, C++, Java, Python, Javascript, shipped lots of great working software, fixed all kinds of bugs, worked in all these domains, various platforms, clearly shown mastery/application of concepts that are core and universal to software development such as A, B, C, D, E, F, G, H, I, J, K, L and M... Yet. Do you have any ActionScript 3.0 experience?" "I'm aware of it. I know what it is. But never written a line of code in it, no. It is almost exactly like Javascript, however, which I've been writing and working with since 1997." "No ActionScript? Sorry. You're not qualified then for this position. Best of luck with your search." repeat ad nauseum
- eru 13y ago
  Fortunately, the market for expertise with computers is hot enough, that we don't have to work at these clueless companies.
  - mkramlich 13y ago
    kind of agree... but in the most abstract general case and in the longer term but in specific cases and events and encounters, and in the near term, in that pesky fractal nature of reality: no, I disagree. sometimes some people DO have to deal with such clueless companies. there are certain economic-related imperatives at play for lots of people, and information and opportunity is NOT perfectly and evenly distributed in the real world, as it is in theoryland.

fat0wl 13y ago

Oh mannnnnnnn do I wish I met some more interviewers like you. I have mounds of experience with programming but not all of it is web-focused, and when I went through interviews I was constantly shut down because I didn't know a particular js or testing framework (RoR world, where there isn't a prescribed consistent stack that is generally used on all projects). Finally I got to a corporation who looked at my track record & audio master's degree, said "damn you must be smart!" & hired me on the spot. I had finally gotten an offer for an RoR position as well at almost the same time but I can't tell you how many interviewers flat-out turned me down for not knowing some random piece of pseudo-hobbyist tech. Anyone applying for a job in one of those ecosystems should spend ~3 hrs a day Googling these things & coming up with some talking points. I wish I could recommend just saying "I don't know" but I can tell you most interviewers don't get it. Better to just say a couple cursory things you read on the library's wiki page, then "I haven't used it in production though..."

ctide 13y ago
'I don't know' is never a good answer. If someone asks you about some specific javascript testing framework, for example, and your answer is simply 'I don't know', that implies that you know nothing about javascript testing. Replying 'I don't know about X, but I've worked with Y in the past, and heard about Z' is an answer that shows that you are familiar with the problem space, which is vastly more important than knowing some random piece of tech.
- fat0wl 13y ago
  heh I agree with you conceptually but I've been in talks that are like (given X is a concept/library/framework) "I don't know about X, but --" "Oh you don't know about X? We don't want to know or understand anything about people who don't BELIEVE in X. You're disGUSting!" But I never said I personally don't agree with the technique... so the response I go with is "Well, I agree with the philosophy there but my previous employers didn't budget any time for X." which they seem to absolutely hate anyway. The reason I ultimately went corporate was because the hiring practices were more algorithm/concept-based (web services, AJAX practices, software design principles) rather than library or language-specific. I was hired into a Java team without even knowing Java. About 3 months later I found I could program on any part of their stack if they really needed me to. Hiring practices that are not based on assessing a candidate's capabilities strike me as egotistical and pessimistic. I'm going to keep reading theoretical Comp Sci texts to see if I can get to the next phase of my career rather than joining the learn-every-framwork-under-the-sun-OR-ELSE movement.
  - mattmanser 13y ago
    Look at it another way. Would you have wanted to work with people who are so short-sighted anyway? As anyone who conceptually can't understand that it doesn't matter that JS testing framework 1 is going to be similar to testing frameworks 2, 3 & 4 is probably going to be populated by a whole load of crap, probably mono-linguistic, developers. A lot of development jobs & the developers that work in those jobs, suck. And they're going to be pretty painful if you care about code. I was at a talk last night and the speaker was talking about how to help new developers when they first start in a company and he started going on about giving the new developers access to the live servers & FTPing the changes to the live server, etc., etc. All I could think is 'right, that company is now a never work for, avoid people who have worked there'. No automated deployment? Having to give new developers access to live servers? In 2013? Pathetic.
- mhurron 13y ago
  When people say you shouldn't be afraid to say I don't know they don't mean say 'I don't know' and then stare in silence at the person asking the question. How you phrase the whole response is important, as it is with every response in an interview, but what more people need to realize that the phrase 'I don't know' is not something that should never be uttered or admitted.
- forrestthewoods 13y ago
  I think "I don't know" can be a perfectly acceptable answer. It's certainly preferable to awkward grasping at straws. I don't expect even a great candidate to answer every question. Sometimes questions are simple probes to find bounds of knowledge and experience. I know a lot about game development. I've shipped quite a few games. I've worked on PC, consoles, iOS, gameplay, engines, clients, game servers, and more. I've never worked on the server backend infrastructure, graphics programmer, nor have I used Unity3D. If you ask me a real question about SQL or database management just about the only answer I can give you is "I don't know". I can't to tell you any differences, pros, or cons related to any javascript library nor any of the now numerous popular databases.
danielweber 13y ago
Employers generally suck. They want someone who already knows, or lies about knowing, their pet 12 technologies, but then they aren't using 6 of them at all. And there is very little brand new stuff out there. If you've been around the block a few times, you recognize the patterns of what something does quickly enough.
- fat0wl 13y ago
  My sentiments exactly. If they have a well-built internal library that is heavy on specific design patterns I'd expect them to give me a hard time over it because I could break some serious stuff or waste a ton of money writing ineffective code. Or maybe if they use heavy black-box builder tools that require some delicate coding to leverage the power of the internals. (In this case again, though, it's still dangerous to hire based on experience with a specific tool because you may get spaghetti code that happens to work within the confines of that tool -- trust me I've seen it.) But open source frameworks & js libraries are much closer to the realm of pet tech. The internals aren't too heavy & conceptually difficult, and most of the classes I see being written by developers are pretty run-of-the-mill regardless of the language/framework. The strange thing is that often the fact that companies are so up-to-date with current trends gives away the fact that they are writing tons of throwaway code. Nobody is maintaining a really mature library that depends on a framework that has been stable for 4 months. Employers would never admit that though, lol.

mkramlich 13y ago

I hear you. But the flip side to that is that probably comes from a hiring/recruiting/interviewing culture that features this anti-pattern: "Let's see here, you've done C programming, C++, Java, Python, Javascript, shipped lots of great working software, fixed all kinds of bugs, worked in all these domains, various platforms, clearly shown mastery/application of concepts that are core and universal to software development such as A, B, C, D, E, F, G, H, I, J, K, L and M... Yet. Do you have any ActionScript 3.0 experience?" "I'm aware of it. I know what it is. But never written a line of code in it, no. It is almost exactly like Javascript, however, which I've been writing and working with since 1997." "No ActionScript? Sorry. You're not qualified then for this position. Best of luck with your search." repeat ad nauseum

eru 13y ago
Fortunately, the market for expertise with computers is hot enough, that we don't have to work at these clueless companies.
- mkramlich 13y ago
  kind of agree... but in the most abstract general case and in the longer term but in specific cases and events and encounters, and in the near term, in that pesky fractal nature of reality: no, I disagree. sometimes some people DO have to deal with such clueless companies. there are certain economic-related imperatives at play for lots of people, and information and opportunity is NOT perfectly and evenly distributed in the real world, as it is in theoryland.