Right now I preface languages with terms like "familiar", "comfortable", "confident" to indicate the amount I've used a particular language. But for most of them I feel like I'm in a pool and never touched the bottom, maybe never even seen it. I don't want to mislead employers by overstating ability because I feel like that's a ticket to working in a bad environment.
> Right now I preface languages with terms like "familiar", "comfortable", "confident" to indicate the amount I've used a particular language.
I would advise against this, it really doesn't help especially for your worse languages. Put down a couple of languages that you've studied and you've done something significant with (even a small project) which you'll also be happy to work with professionally.
My suggestion: Don't use adjectives in a Resume. It doesn't matter much because if I am looking for say a programmer who can code in JS, you saying "expert" vs "comfortable" won't change the fact that I will interview you anyway if I decided to otherwise. Yes, when the interview starts, you can clarify your level of experience further.
In other words, when I interview Entry Level candidates, I don't give the adjectives much weight. People put all kinds of adjectives on their Resume and I don't pay attention to those. You want to be more specific if possible. You can say "I worked on this project where I was responsible for <xyz>". Then explain it in the interview if asked.
> terms like "familiar", "comfortable", "confident" to indicate the amount I've used a particular language
I'd be honest about what you've done
* wrote Hello World in Rust
* built a simple API with NodeJS
* completed TDD kata in C#
or whatever it might be.
Bonus points for linking to git repos so the recruiter can see what the code looks like
If you are entry-level the recruiter should be looking at things like your history of learning to see how you'll grow in the role much more than they're looking at your exact experience.
Personally I would suggest removing that kind of section entirely. The problem is those adjectives will never be consistent from one person to another. Focus on what you've done, the tools you used, and the impact it had.
There may not be a massive impact, outside of yourself, and that's okay especially if you're learning. It's still useful to say what's different after your work.
It reads like you are trying to populate a “skills” section.
As an interviewer/hirer, I ignore skills sections entirely. I want to know two things from a resume “what you did and how well you did it”.
That means “Using $LanguageX, I did $y”. I am then going to dig in to your bullet points and expect you to be able to explain what you did and ask you why you made the choices.
You may ignore skills sections, but a great deal of people utilize them. They're hiring a guy who can write React code, so they look for the word "React" and some measure of experience, and it gets put on the phone interview pile.
I don't necessarily agree with it, but too often the resume has to go through people who don't have tech proficiency and skim the thing. Or a bot. The skills section is like the armor plated casing that doesn't do the real damage, but punches through that layer.
I want to hire people who code in Kotlin. I personally know it cuts down LOC by 40% vs Java. But I don't care that they've measured this process or why they do it, as long as they code in Kotlin.
I want to hire someone who uses Room to access DB vs direct SQLite queries. I know it's used for databases and I know it cuts down mistakes by a lot of %.
Someone who uses Jetpack Compose. Or Kotlin Flow. I know the benefits of these. And in many cases there are no measurable benefits - it makes debugging harder, but also means less bugs as an application scales. Compose cuts necessary code to write/maintain by half in some instances, but cuts down on the cognitive load by a hell lot. I don't need to see the whys in a resume.
They have a high learning curve. They're battlefield tested. I need someone who can use an assault rifle. It's cool if they won a war with a spear, but I'd rather hire a newbie with an assault rifle for the position.
I’m not saying the BS about “Wrote a React app that brought in 50% more revenue”.
I’m saying “Used React to create $YetAnotherSaasCRUDApp”. I want to know you did something with it besides write Yet Another TODO app following a tutorial.
I'd like to note for other commenters that no one has actually answered the question being asked. Not to speak for the OP but the spirit of the question in my mind has more to do with how long before you reach the minimum threshold of proficiency to honestly say you know a given language.
Astute observation! I appreciate the other responses and have found some useful take-aways. But yes, the nature of my question was not how to present what I know, but rather about benchmarks I should aim to achieve.
Read the job ad and mirror back to them the terms and language that they use. If the job uses X_lang, probably make sure to put how good you are at X_lang with the presumption that they're going to call you on it if you say you're an expert.
I normally put years of experience with a language. That leads to some dumb things like saying I have 3 years of xp with Node when most of those years have been beginner tier, but overall it's gives a decent overview.
I would advise against this, it really doesn't help especially for your worse languages. Put down a couple of languages that you've studied and you've done something significant with (even a small project) which you'll also be happy to work with professionally.