[ionforce]

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.

[nilkn]

> 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.

[flurgl123]

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.

[xsmasher]

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.

[LoSboccacc]

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]

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.

[jkaptur]

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

[projct]

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]

Thanks, I'll have to try that out.

[ionforce]

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]

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]

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]

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 is great

[kafkaesq]

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]

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.

[seanp2k2]

It's interesting that different companies will want different things on a resume. This is why no two jobs I've applied for get the same resume. If they want lots of experience in a lot of different things, sometimes they DO want the laundry list of acronyms (make sure you know what they all stand for). You might not even get through the first selection if they use XSLT heavily and you didn't think it was relevant that you had worked with it before on a project.

I've also had interviewers rip the other pages out of my resume in front of me, but everyone is different. At the end of the day, don't feel too bad about not getting an offer. A lot of it is luck.

[kafkaesq]

I've also had interviewers rip the other pages out of my resume in front of me,

Really? That's incredibly rude.

[kafkaesq]

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.

[mech4bg]

I understand your point, it drives me crazy in interviews as well. But by the same token when I'm interviewing, I want to be able to grok someone's resume as quickly as possible - I don't want to see stuff that they themselves don't think is relevant.

[jenscow]

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]

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.

[SilasX]

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]

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]

Right, the point is that such an answer would reveal a more superficial understanding of the language than they might have earlier implied.

[alistairSH]

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.