5 ms·

I've had people interview claiming to know X and then not code in X correctly. So... that's a red flag. We allow interviewees to pick their strongest language.

I've had people interview claiming to know X and then not code in X correctly. So... that's a red flag. We allow interviewees to pick their strongest language. But if you end up picking something that doesn't exist, well, you aren't earning yourself any points.

LoSboccacc 11y ago
I wouldn't pass then since I live in post 2000 and am used to let the IDE handle the nitty gritty details while I focus on the actual meat of creating software
- econnors 11y ago
  I've had this problem as well. I go back and forth between Obj-c, python, javascript, matlab etc. so much without spending a significant amount of time on any one language that I often feel intellectually deficient because I don't know the nitty-gritty details of any of them. Curious to see what others think - is this something I should stop and focus on? Or in today's development environment is it considered acceptable to have to occasionally lookup language nuances in any given situation? For example, I couldn't tell you off the top of my head how to test for null in python. I'd assume it'd be if(obj), but after a quick google search it seems like if(obj is not None) would be the correct answer.
  - projct 11y ago
    http://exercism.io http://exercism.io has helped me to write more idiomatic code (submit a thing, get comments, refactor, also comment on other people's code.) Maybe it'd help you for the languages they have examples for?
    - econnors 11y ago
      Thanks, I'll have to try that out.
  - jkaptur 11y ago
    I used to be in a very similar situation, but I was convinced otherwise by this article [1]. The fact of the matter is that, yes, it's easy to become familiar with a variety of programming languages, but I think you actually learn a lot more when you double down on a language (platform, ecosystem, etc.) for a long period of time. Quoting from the article: > Leaky abstractions mean that we live with a hockey stick learning curve: you can learn 90% of what you use day by day with a week of learning. But the other 10% might take you a couple of years catching up. That's where the really experienced programmers will shine over the people who say "whatever you want me to do, I can just pick up the book and learn how to do it." If you're building a team, it's OK to have a lot of less experienced programmers cranking out big blocks of code using the abstract tools, but the team is not going to work if you don't have some really experienced members to do the really hard stuff. In areas that I'm just learning or dabbling in (for me, Objective-C), I look things up or reach out to experts. But there are areas where I want to be the expert that others reach out to. [1] http://www.joelonsoftware.com/articles/LordPalmerston.html http://www.joelonsoftware.com/articles/LordPalmerston.html
  - ionforce 11y ago
    The bad/goodness of your strategy I would measure by your market success or happiness. Do whatever makes you happy and employable. Personally, I love the idea of being a generalist. But at the end of the day, you gotta code and code good, specialist or not.
- ucho 11y ago
  I don't think it matters. No one want's to see import/includes on blackboard and they don care much if you remember if method on some object was called len(), size(), count() or length.
Fargren 11y ago
I don't get why. When I'm organizing my thoughts in code, I normally write something pythonish, but not really any real language. Stopping to think about the correct syntax does not make me solve the problem any faster or any better, and since I am writting on paper or a board I am going to have to rewrite everything anyhow. Maybe I'll even have an IDE to do most of that meaningless effort for me. It's like lazy syntax evaluation; don't do it until you have to.
- seanp2k2 11y ago
  I've been writing a comment as a placeholder for real code stating the problem in simple English when I'm stuck lately. Usually going through putting it into words really guides the code. It'll usually look something like: # the problem is that our query only matches rows where the ID from foo table equals the ID from bar table, but we want rows from foo table that match the first part of our query regardless This also makes it easy to ask for help, since now you've turned your "it no workie" into a question which you could ask another person on your team or in e.g. IRC for help with. They might then have additional questions, but I've found more often than not that simply getting a few minutes with someone else is enough for them to bring not-your-entrenched-perspective to the problem and hand you the (sometimes super obvious) solution in short order. TL;DR https://en.m.wikipedia.org/wiki/Rubber_duck_debugging https://en.m.wikipedia.org/wiki/Rubber_duck_debugging is great
kafkaesq 11y ago
I've had interviewers look at an unweighted keyword digest from my resume, apparently without reading said resume (which clearly states my current skill focus on the top, which has evolved quite substantially over time). And then start "grilling" me on a language that appeared on a job description from 10+ years ago.
- mech4bg 11y ago
  Take out any of that old stuff. It's not necessary. Your resume should fit on one page, two at absolute most, and only include things that you would expect to be grilled on. If you are annoyed about being tested on something on your resume, take it out.
  - jenscow 11y ago
    There's no need to be "grilled" on something you did 10+ years ago (unless it's a requirement of the job, of course). Perhaps a "have you used Pascal since leaving ...?" would suffice.
    - mech4bg 11y ago
      A resume should reflect your current skills and abilities. You should feel free to leave in old positions, and the interviewer can ask about it if they want, but you should not leave in technical things you don't want to be asked about.
      - deleted 11y ago
        [deleted]
  - kafkaesq 11y ago
    I see what you're getting at. I still think that in general, people who can't be bothered to read important documents, and instead just eyeball them for keywords (and start shooting off questions accordingly) -- aren't my cup of tea to work with, anyway.
nilkn 11y ago
> But if you end up picking something that doesn't exist, well, you aren't earning yourself any points. I don't know about your personal interviews, but I'd find this reasoning slightly strange if I were being asked to write computer code on a whiteboard. I'd find it much less strange if I were actually handed a laptop to write a functioning program on. Expecting perfectly correct code on a whiteboard seems to me to be a slight abuse of the medium. Whiteboards and chalkboards specifically exist to sketch things out in an adhoc fashion, often in a collaborative and easy-to-edit way.
- xsmasher 11y ago
  To "not code in X correctly" is ambiguous, but I assume/hope the parent poster means that someone makes fundamental, non-syntax errors in their code - in C++ this would be something like returning a pointer to an object that's on the local stack. If you're trying to filter for people can be productive in a particular language from anyone else, that's what you need to look for. If you let the candidate pick their strongest language and they still make fundamental errors, you know they're not going to be immediately productive in any language.
- flurgl123 11y ago
  I don't think he meant perfect code. But I've had candidates claim their main language is Java, but were unable to write a proper for loop or know basic data types like arrays or ArrayLists. I've met such people with PhDs and impressive CVs. Interview enough people and you'll encounter some that are very convincing until you dig down into details. So you have to dig into details.
alistairSH 11y ago
I ask questions about the language to determine if they know the language. Correct syntax isn't going to show me you understand prototypal inheritance.
SilasX 11y ago
It depends on what "not code in X correctly" means. If they missed a few syntactical things, it's fine. If they're obviously still "thinking in a different language", then no. For example, if you ask them to loop over a list of items in Python, they shouldn't write: for i in range(len(items)): do_stuff_to(items[i]))
- vlasev 11y ago
  Well, even though it's not idiomatic, it still works. A good question to follow up with is if the candidate is familiar with iterators.
  - SilasX 11y ago
    Right, the point is that such an answer would reveal a more superficial understanding of the language than they might have earlier implied.

LoSboccacc 11y ago

I wouldn't pass then since I live in post 2000 and am used to let the IDE handle the nitty gritty details while I focus on the actual meat of creating software

econnors 11y ago
I've had this problem as well. I go back and forth between Obj-c, python, javascript, matlab etc. so much without spending a significant amount of time on any one language that I often feel intellectually deficient because I don't know the nitty-gritty details of any of them. Curious to see what others think - is this something I should stop and focus on? Or in today's development environment is it considered acceptable to have to occasionally lookup language nuances in any given situation? For example, I couldn't tell you off the top of my head how to test for null in python. I'd assume it'd be if(obj), but after a quick google search it seems like if(obj is not None) would be the correct answer.
- projct 11y ago
  http://exercism.io http://exercism.io has helped me to write more idiomatic code (submit a thing, get comments, refactor, also comment on other people's code.) Maybe it'd help you for the languages they have examples for?
  - econnors 11y ago
    Thanks, I'll have to try that out.
- jkaptur 11y ago
  I used to be in a very similar situation, but I was convinced otherwise by this article [1]. The fact of the matter is that, yes, it's easy to become familiar with a variety of programming languages, but I think you actually learn a lot more when you double down on a language (platform, ecosystem, etc.) for a long period of time. Quoting from the article: > Leaky abstractions mean that we live with a hockey stick learning curve: you can learn 90% of what you use day by day with a week of learning. But the other 10% might take you a couple of years catching up. That's where the really experienced programmers will shine over the people who say "whatever you want me to do, I can just pick up the book and learn how to do it." If you're building a team, it's OK to have a lot of less experienced programmers cranking out big blocks of code using the abstract tools, but the team is not going to work if you don't have some really experienced members to do the really hard stuff. In areas that I'm just learning or dabbling in (for me, Objective-C), I look things up or reach out to experts. But there are areas where I want to be the expert that others reach out to. [1] http://www.joelonsoftware.com/articles/LordPalmerston.html http://www.joelonsoftware.com/articles/LordPalmerston.html
- ionforce 11y ago
  The bad/goodness of your strategy I would measure by your market success or happiness. Do whatever makes you happy and employable. Personally, I love the idea of being a generalist. But at the end of the day, you gotta code and code good, specialist or not.
ucho 11y ago
I don't think it matters. No one want's to see import/includes on blackboard and they don care much if you remember if method on some object was called len(), size(), count() or length.

Fargren 11y ago

I don't get why. When I'm organizing my thoughts in code, I normally write something pythonish, but not really any real language. Stopping to think about the correct syntax does not make me solve the problem any faster or any better, and since I am writting on paper or a board I am going to have to rewrite everything anyhow. Maybe I'll even have an IDE to do most of that meaningless effort for me. It's like lazy syntax evaluation; don't do it until you have to.

seanp2k2 11y ago
I've been writing a comment as a placeholder for real code stating the problem in simple English when I'm stuck lately. Usually going through putting it into words really guides the code. It'll usually look something like: # the problem is that our query only matches rows where the ID from foo table equals the ID from bar table, but we want rows from foo table that match the first part of our query regardless This also makes it easy to ask for help, since now you've turned your "it no workie" into a question which you could ask another person on your team or in e.g. IRC for help with. They might then have additional questions, but I've found more often than not that simply getting a few minutes with someone else is enough for them to bring not-your-entrenched-perspective to the problem and hand you the (sometimes super obvious) solution in short order. TL;DR https://en.m.wikipedia.org/wiki/Rubber_duck_debugging https://en.m.wikipedia.org/wiki/Rubber_duck_debugging is great

kafkaesq 11y ago

I've had interviewers look at an unweighted keyword digest from my resume, apparently without reading said resume (which clearly states my current skill focus on the top, which has evolved quite substantially over time). And then start "grilling" me on a language that appeared on a job description from 10+ years ago.

mech4bg 11y ago
Take out any of that old stuff. It's not necessary. Your resume should fit on one page, two at absolute most, and only include things that you would expect to be grilled on. If you are annoyed about being tested on something on your resume, take it out.
- jenscow 11y ago
  There's no need to be "grilled" on something you did 10+ years ago (unless it's a requirement of the job, of course). Perhaps a "have you used Pascal since leaving ...?" would suffice.
  - mech4bg 11y ago
    A resume should reflect your current skills and abilities. You should feel free to leave in old positions, and the interviewer can ask about it if they want, but you should not leave in technical things you don't want to be asked about.
    - deleted 11y ago
      [deleted]
- kafkaesq 11y ago
  I see what you're getting at. I still think that in general, people who can't be bothered to read important documents, and instead just eyeball them for keywords (and start shooting off questions accordingly) -- aren't my cup of tea to work with, anyway.

nilkn 11y ago

> But if you end up picking something that doesn't exist, well, you aren't earning yourself any points. I don't know about your personal interviews, but I'd find this reasoning slightly strange if I were being asked to write computer code on a whiteboard. I'd find it much less strange if I were actually handed a laptop to write a functioning program on. Expecting perfectly correct code on a whiteboard seems to me to be a slight abuse of the medium. Whiteboards and chalkboards specifically exist to sketch things out in an adhoc fashion, often in a collaborative and easy-to-edit way.

xsmasher 11y ago
To "not code in X correctly" is ambiguous, but I assume/hope the parent poster means that someone makes fundamental, non-syntax errors in their code - in C++ this would be something like returning a pointer to an object that's on the local stack. If you're trying to filter for people can be productive in a particular language from anyone else, that's what you need to look for. If you let the candidate pick their strongest language and they still make fundamental errors, you know they're not going to be immediately productive in any language.
flurgl123 11y ago
I don't think he meant perfect code. But I've had candidates claim their main language is Java, but were unable to write a proper for loop or know basic data types like arrays or ArrayLists. I've met such people with PhDs and impressive CVs. Interview enough people and you'll encounter some that are very convincing until you dig down into details. So you have to dig into details.

alistairSH 11y ago

I ask questions about the language to determine if they know the language. Correct syntax isn't going to show me you understand prototypal inheritance.

SilasX 11y ago

It depends on what "not code in X correctly" means. If they missed a few syntactical things, it's fine. If they're obviously still "thinking in a different language", then no. For example, if you ask them to loop over a list of items in Python, they shouldn't write: for i in range(len(items)): do_stuff_to(items[i]))

vlasev 11y ago
Well, even though it's not idiomatic, it still works. A good question to follow up with is if the candidate is familiar with iterators.
- SilasX 11y ago
  Right, the point is that such an answer would reveal a more superficial understanding of the language than they might have earlier implied.