Ask HN: When to claim you know a programming language? | Hacker News Reader

Ask HN: When to claim you know a programming language?

8 pointsbluemooner10 comments

I find it particularly difficult to assess my skills in a specific programming language.

Even if I've done some projects solely in one language, I feel like that's not enough for me to say that I'm comfortable with that language.

Then the question is: when and how should I say I know a language? More precisely, when should I add one to my CV?

View on HN

As an employer, broadly speaking, the languages you know doesn't matter. I'd rather hire a "good programmer" than a "knows X" programmer.

A good programmer will be able to "learn" a new language in a matter of days. [1]. Factor in a few more for new IDE etc. A bad programmer writes bad code in all languages.

All coding starts in the head, with ideas on how to go about solving a problem. Good knowledge of one language at least makes that easier. Being able to express the solution in elegant code is the key skill. Knowing the syntax for comparing strings is meaningless - anyone can figure that out in no time. Understanding what string comparison means is much more important [2]. And so on.

[1] within reason. Imperative languages are all the same. Functional are all the same, but I would not hire an imperative programmer for a functional language or vice versa.

[2] turns out comparing unicode strings for equality is a whole barrel of fun and starts with deciding what "equals" even means...

Add a language to your CV when you are fluent enough in the language to understand all the syntax and you can read anything written in the language and you have written code yourself in it. This doesn't mean you are an all out expert and know every detail, just that you are capable in the language. Most of the time we use 60-80% of a programming language IME, so once you know that common set you are good. That other 20-40 percent of a language is usually specialized to specific things or fringe and not common, so not knowing those fluently is fine IMO.

Put another way, you know a language when you can pick up any project written in it and can read it intelligently without having to look up what common library functions do (not all of course, but the most common of the functions).

When you:

* can read gnarly real-world code with confidence

* know the stdlib and common libraries reasonably well

* have written something significant enough to be a good demonstration of your skills in that language, either at work or as a side project

Everyone with some programming experience knows that needing a refresher on a language you haven't used in a while is normal, so you can safely put languages on your resume that you used a while ago as long as you have brushed up on today's ecosystem.

As a general rule, the more senior you are, the more in-depth knowledge you'll be expected to have about anything you put on your CV. For that reason, splitting technologies up into a few different levels of proficiency is a good idea.

I've tried to distinguish levels of proficiency with a language in my CV. For example, "expert/highly proficient", "proficient", or "familiar". There's only one or two that I'd consider myself "highly proficient" in, and probably a half dozen that fall into the latter categories. Gives you some flexibility to say "hey, I've worked with [language X], but I'm not as strong as I am with [language Y]"

That makes a lot of sense! But how do you deal with people that expect something different from those levels? That is, 'proficient' might mean 'expert' for some people.

I do a similar thing but just use "proficient" and "familiar", leaves much less room for misinterpretation when there are only two levels imo. Over time I've also trimmed down the list significantly to only languages I would be OK working with and be comfortable doing an interview in. For example, I know C++ to a "familiar" level thanks to school, but I personally dislike it and wouldn't want to it to be part of my work at all, so it's not on my resume.

It's not an exact science, so I'd try to provide an honest self-assessment while ultimately not worrying too much about it. The CV should really be a conversation starter more than anything - you can provide more clarity in the interview.

List if you can write code in the language. If it comes up in the interview you can elaborate on your skill level.

From a practical standpoint, when you can write idiomatic code in the paradigm that the language supports.

And inversely, when you can confidently do code reviews and your comments are in the idiomatic zone.

The breakpoint for me is when I stop looking at "how to do x" on the internet. I do it from muscle memory.

Reply on news.ycombinator.com