Hacker News Reader

Comment by tester756 | Hacker News Reader

>I’m exaggerating the amount of skill that I have. Everyone is. I use the right buzzwords on my CV. I inflate the scale of my achievements and the depth of my skillset. I even add tasks and responsibilities to historical jobs that fit your requirements. You’re never going to check, are you?

I don't, I'm honest in my CV and during interviews

I'm selling myself 'as-is' e.g despite using git for longer peroid of time, but mostly via GUI, then I'm not going to call myself proficient/experienced git user cuz I'd fail some above basics question

View on HN

> I don't, I'm honest in my CV and during interviews

When I first started interviewing people I assumed everyone wrote their resumes just like me: Honest, accurate, erring on the side of humble, avoiding exaggeration of my abilities.

I learned the hard way that you can’t really trust what people put on their resumes. A lot of people are accurate and honest. Many people are actually too humble or often just bad at selling themselves, so you have to read between the lines and dig for their biggest achievements.

But unfortunately, a large number of people will exaggerate their accomplishments far beyond anything that could be considered reasonable. Claiming proficiency in programming languages they couldn’t begin to even talk about. Writing about projects they didn’t actually work on. Making up unrealistic numbers for how effective or profitable their work was.

The worst was when I receive a resume for a former coworker who hadn’t performed all that well when we worked together. The resume included some of my achievements, which the person hadn’t been involved with nor was even capable of. It was a shock to my naive system to see someone brazenly claim so much in hopes that they could slip past the interviewer and land a well-paid job where they presumably tried to blend in while dodging responsibility and accountability as much as possible.

And that is why we all have to go through onerous tech interviews, despite listing our experience on our resumes.

Not to discount this fact much, but there’s a reason that I optimise my interviews for weeding out liars.

Tech tests on DS&A are fine, I guess, but usually you can sus a person out if you’re technical enough after 30 minutes of talking about previous projects and their level of involvement.

Typically I ask more and more questions about it until they can’t answer, if they try to BS me once they’ve reached their level of incompetence then they're immediately disqualified no matter how good they are in other areas.

I’d rather take a weaker person who doesn’t try to masquerade than a strong person who will.

That’s fair enough, but from a candidate’s perspective most interviewers just want people who can BS effectively. They don’t want to train new hires in their particular stack. They want a ready-made candidate who already has “experience” in X Y Z W A B C.

Call it tragedy of the commons, but being honest is not an optimal way to play the game.

I wouldn't like to work in a place where most people lied to get a job. May be if I would be desperate to find a job, I'd lie as well, but software developer is a hot place now and it shouldn't be too hard to find adequate people IMO.

It’s not good for anybody, but it is some kind of game theoretic equilibrium whereby the hiring machinery is incentivized to find candidates who are good fits for a company’s stack, and candidates are incentivized to present themselves to be such.

The way to solve it is to make the hiring process independent of experience with a particular stack and just hire engineers with good fundamentals, which is what FAANGs do by necessity (because their stack is proprietary), but others don’t want to do because they are afraid it would be too expensive.

I should probably say that I’m in Europe. Things may be different in SV.

>I wouldn't like to work in a place where most people lied to get a job.

"A place where most people lied to get a (tech) job", is the world. And the world is the only place that has jobs.

Software is hot only in the sense that there are “jobs” available. Whether or not those jobs are good or pay well is another factor.

Do you really think everyone has a spot at FAANG-etc? They don’t - I know because I work at them and we reject so many people at the on-site stage.

> reject so many people at the on-site stage.

About how many percent?

What could be ways to find out sooner that they're not the best person for the job? (What about doing half the interviews remotely?)

Reading coworkers resume or promo packet (more awkward) and finding stuff that you worked on is an instant classic I feel everybody goes through at least once

I'm kind of in a middle ground. I'm honest about what's on there, but what is truth one person is a lie from another. For example, I didn't have specific numbers for what my ICs were, but people like to see context, so I mentioned I did x and y for a company that did such and such in revenue that year, and that on the outside, my code seems to still be powering some of those sales. But honestly, if a colleague at that company asked why I lied about x, I'd just say "Really? My bad, what was I mistaking that for?" because quite frankly I don't remember acutely what specific component I wrote JavaScript for in a huge complex system 6 years ago. It's not that important to begin with, and I only keep the high level details archived in memory.

For example, I might remember working on it, but maybe what I actually did at the time was tested it extensively, or investigated a performance issue, or even collaborated on solving some problem in that specific bit. If I look at the code, I couldn't tell you what my code looked like at that time. There no evidence aside from commits that I did or didn't work on it, and so there's a good chance that either of us are right. Either way, I don't care, it's a trite issue. I got fired from that job anyway and list it on my resume as experience, which it was, but I don't say anything about what I stopped working there. Doesn't make it invalid and it's none of an interviewers business.

>And that is why we all have to go through onerous tech interviews, despite listing our experience on our resumes.

I don’t mean to burst your bubble, but these type of people have no problem studying leetcode for a few weeks. Sorry to say.

In fact, these are the exactly the kind of people that the LC process is designed to filter for.

How is studying programming considered cheating?

Their point is that just because someone can do leetcode does not mean they can program well, and they may too just be faking it to get a job they aren't qualified for.

I don't know how one can study leetcode and fail to learn to program better.

After all, I learned chemistry, physics, math, mechanics, thermodynamics, etc., by working problem sets.

In my opinion "program better" (or actually better at system modeling)

requires way more time, way more examples, way more code written.

I believe that in order to be "somewhat decent" at leetcode (not top level competitor)

you just need to learn theory, techniques, tricks and get some practice.

Meanwhile in order to get better at system modeling you need to model a lot of systems from scratch, change them and see how your initial design supported that refactor part

You need to be aware of various approaches / architectures, yada yada

And generally spend a lot of time thinking about how it'll affect readability or easiness to get into the project for new ppl, scalability, extensibility, etc.

So, in generally I believe that leetcode is just learn theory, practice everything you learned and go ahead and do 50 / 100 tasks

If you fail, then you can check answers and learn from them

meanwhile there are no correct answers for system modeling.

Additionally for leetcode you have sets with tasks to practice, meanwhile the "real" system modeling experience comes from real projects where requirements are being thrown and changed by somebody else whenever he/she wants

____________

>I don't know how one can study leetcode and fail to learn to program better.

I don't see how even hundreds of hours on leetcode would make you better at OOP, system modeling, building abstractions.

> I don't see how even hundreds of hours on leetcode would make you better at OOP, system modeling, building abstractions.

Because you know the foundations.

Knowing how a compiler works all the way down makes me a better programmer. Knowing assembler makes me a better high level language programmer. Knowing in detail how a car works makes me a better driver. Knowing how electricity works at the low level prevented a very costly mistake by the electrician who was wiring it (he had no idea). Knowing chemistry prevented a very costly mistake by the roofer of my house.

More about algorithm questions vs system modeling:

I'm thinking that

1) getting good at algorithms takes less time, than getting good at system modeling. — One will see one's mistakes sooner, within minutes, compared to system modeling, in which case one would need to stay at a workplace for months or years, to see how a system design eventually turned out to be a mistake?

But 2) it's also harder to get good at hard algorithm questions — most people won't get that good at it, also with weeks and months of practice. And they still wouldn't have any real chance in a Google coding interview.

And in that way, algorithm questions make sense?

They give more information about the person's ability to think and learn — good for the company —

and takes less time for the candidate to get good at (weeks or months — compared to working for years?), good for the candidate?

(I'm someone else than GP)

PS. I wonder what the electrician was up to? :- ) and the other one

Out of curiosity, what knowledge about electricity and chemistry did you have that prevented the mistakes?

I don't know how one can study leetcode and fail to learn to program better.

LC can help you program "better" -- but in a narrow, "just tell me what I need to know to pass the friggen' test" sense.

To learn how to really program better - you'll have to start building things. And reading books. Meaning, you know, "hard" books. Not books about how to get past the LC barrier. And these things known as "papers", and man pages, and specifications, and the raw source code as written by people much, much better than you (even though 99.99 percent of it has nothing to do with LC problems). And by getting down there, in the trenches, and working with people who are plainly better than you are, and who you can almost barely keep up with.

That's how you get to be better. Not by ... studying to pass the test.

> I learned the hard way that you can’t really trust what people put on their resumes. A lot of people are accurate and honest. Many people are actually too humble or often just bad at selling themselves, so you have to read between the lines and dig for their biggest achievements.

What exactly separates accurate/honest from humble/bad at selling oneself according to you?

We don’t have to do it, companies are just gun shy about bad hires. They could easily accept everyone resume unread and remove people only if they failed to live up to expectations for an example of an alternative

When a company is going to invest half a million bucks in a new hire, they're going to do what they can to determine in advance if the hire is going to work out.

Most likely, but we still shouldn't assume its a property of the universe. Its a choice they are making and so the consequences good or bad should be attributed to them

When you are investing $500,000 of your own money, are you going to check it out thoroughly first?

When they invest $500,000 of their own money and it makes millions, do they decline the profit? Their behavior is perfectly rational, but still ultimately a choice they make, and both the good and bad are a result of that.

Unless you are going to argue that they aren't rational adults with agency of their own, in which case I would question letting them decide anything at all

I don't see what that has to do with what I wrote.

Tbh I don’t know what your comments have to do with mine either?

I was responding to the phrase “have to”, and pointing out that they don’t “have to” do this. Then you brought up things like people investing a lot of their money? It still doesn’t change that it’s a choice. They could be investing the gdp of Canada and making rational decisions around the money, but it is still ultimately a choice

I didn't write "have to". Perhaps you are replying to someone else?

https://news.ycombinator.com/item?id=31902260

This is the original comment I replied to, I thought you were asking a clarifying question and tried to reiterate my main point. My apologies if there was a confusion

That comment,

> we still shouldn't assume its a property of the universe

is actually a bit funny I think. One could post that comment as a reply to almost anything :-)

And then see how they interpret it and how they react

Yea, in my critique, it’s probably not a sentence that triggers people towards good conversation, but I’m not really sure how to broach the concept that everyone has free will when people are legitimating discussing how the people in charge of businesses have no choice and have to do something bad.

Tbh the defense of most business leaders sounds like someone defending a rabid dog or a killer robot’s action’s.

I really can’t understand how some people can simultaneously believe that execs and founders deserve the outsized compensation for making all the decisions critical to the business, while simultaneously believing in this neo-Calvinist philosophy where the elite _have_ to fuck over everyone for their own benefit and it’s ridiculous to think that they could chose ethics over money

Like, do they have free will and so you can make the argument that their choices led to greater profit and they deserve a big cut, or are they simple tiny dancers on the wind of fate who can’t do anything of their own accord which (if you were being consistent) means that they brought nothing of benefit to the business and therefore should get none of the profit?

I have trouble with this argument because on the other hand, once they’ve got good people that are consistently producing valuable output, they penny pinch and give tiny below inflation raises (if at al)… and promptly lose these people to competitors and have to hire all over again.

Companies that do a poor job of hiring and retention tend to fail. It's a self-correcting process.

Government, on the other hand, just increases the budget.

Companies could buy crappy software, could spend millions in unnecessary offices, expenses for unnecessary dinners, offsites, whatever, on crappy salesmen who can probably cost them more in the long run, etc It’s a single person, if you identify that he can’t make it within the first 3 months, he will never cost you 500k.

> if you identify that he can’t make it within the first 3 months, he will never cost you 500k.

It'll take longer than that just for the new employee to get up to speed, let alone contribute much and prove his worth.

Also consider that the benefits package is often worth 50% of the salary or more. Then there are the taxes the employer pays on employment, the cost of the facility and equipment for the person, etc.

Then there are all the expensive and costly problems if the person is in a protected class. The employer has to prove they can't do the job, which can take a year or more.

no, you go through them so they can pay you less, and you are the tool used to accomplish this.

also, you should never assume people lie on their resume. before you know it you will carry that bias into every interview. if i was your manager and i knew what you just wrote, i would find someone else to interview people.

> When I first started interviewing people I assumed everyone > wrote their resumes just like me: Honest, accurate, erring > on the side of humble, avoiding exaggeration of my abilities.

You may be missing the point of a resume.

There are really two goals: 1. Get you through the door, so you can get an Informational with the Hiring Manager. This means passing the Recruiter and (usually) the Hiring Manager's 30-60 second screen while looking at 50 candidates. Often an email or a Linked In Message is more effective than a CV at this.

2. Sufficiently and credibly explain your background to the interviewers who will be reading it 5 minutes before the interview.

The CV needs to present well and be credible.

I think you are missing the point of the GP post. Yes, a resume/CV is a marketing document designed to get you past an initial screen, and to tell an interviewer what you are about. But, ideally (and it's certainly not too much to ask), such a document should also be accurate. "Marketing" and "lies" should theoretically be disjoint sets.

Unfortunately, the fact that so many people outright lie on their resumes means that people who don't are at a disadvantage.

Resume truth isn't the same as spoken truth.

I worked at FedEx ground for two weeks in college, but one week was in June and the next was in July, so while that was relevant experience, it went on my resume with June-July and it may have looked like I worked there for two months.

It's common to only list the final position one held, so someone who was in the mailroom for 5 years, somehow got into a deskjob for two weeks and then left is going to show 5 years at the company, deskjob (unless they're looking for a new mailroom gig). It's true, but misleading. Of course, some people go beyond that and claim things they didn't actually do, etc.

After a certain point of interviewing candidates, I stopped reading their resumes. All of the interesting stuff I would ask about never had details behind it, because it was fluffed up, but never enough to disqualify a candidate either.

I am on the humble side in my resume and I have landed a job that pays well, but for which I am completely overqualified for.

I will often pick something "expert" on their resume to dig into, if nothing else than to gauge what "expert" means to them.

Recently I interviewed someone who emphasized databases on their resume, and later mentioned they were very highly skilled in that area, so we started talking about indexes. I think I asked something like "Why wouldn't we just put an index on every field?" and the best I could get from them was "it might speed up, it might slow down" but they couldn't articulate why.

Another one I will sometimes ask: You're an expert in language / framework x and have been using it for 10+ years? Cool. What recent additions have you most excited about it? What things about it do you hate/disagree with the most?

Not being able to answer these things don't mean you 'fail' the interview of course, but to me it's a strong signal that our definitions of "expert" are different, and so I'll make that assumption about everything else on your resume.

I put as little as humanly possible on my CV to reduce the chance of getting asked about stuff I have pretty much completely forgotten about.

I hate preparing for interviews and don't want to brush on my past. For example, I spent a year writing an LLVM backend for a DSP but I'm pretty sure I couldn't write more than a fizzbuzz in C++ now. Nor do I remember much about LLVM. I don't want to come across an LLVM enthusiast and have him start grilling me on details I have long forgotten.

I try to write just enough to get an interview, anymore information makes you more likely to fail your interview in my book. Plus writing less makes you mysterious ;p.

Would they think you’re inexperienced though?

Most resumes I see have both a skills section and some sort of work history section. You can keep advertised skills focused while still listing past projects and work if you use a format that makes a similar distinction.

My problem is the skills section isn't going to match up with the experience section, most of my technical knowledge came from just screwing around and trying to hack/fix stuff. Most of my professional career could be described more as "code-monkey if that".

Last job search was depressing. I wanted to actually stick with it, and find me a job I actually wanted (as opposed to the same thing I've been doing for years + some more money). However nearly every job I applied to I got ATS screened out of, meanwhile the recruiters kept coming to me with more money for similar crappy jobs and I folded. Well either that or recruiters that never even read my resume spam me. I've been getting spam for RoR positions, I haven't touched ruby since 1.9 ad have never had professional experience with it.

What is ATS? ... Aha, applicant tracking software? So you got rejected automatically by a machine? How annoying.

I could slightly understand if some people write whatever in their CVs if they're trying to get past the machines

What about: "LLVM (year 1970, mostly forgotten now)" -- a good judgement impression and showing the recruiter that you can (re)learn such things should you want to?

I've also gotten positive feedback for clearly stating what I know and what I don't know. I'm using a „skill meter” to distinguish between „I'm an expert in this language“ and „I've used this a couple of years ago“.

I got a job offer from a company whose main language is Go and I didn't even know the basics. A good software engineer can pick up any reasonable language in a reasonable amount of time [1].

I usually ignore recruiters who don't contact me via InMail. If they convey that they actually took a look at my profile, I'll reply.

I've had a very good experience with the three EU companies that I've been interviewing with this year. One had a take-home assignment that was reasonably scoped for 2-4h and well thought. The others asked some basics and some architechture / design / business understanding related questions. No leetcode or whiteboard coding. Open communication + quick feedback.

Was I just lucky in that regard or are there a lot of companies with a sane interview process out there, but some HN readers prefer to apply at those who don't?

[1] https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

Most of us probably don't interview at a statistically significant sample of companies, so I guess it's hard to say. For the record, I recently did three tech interviews for tech lead level roles.

* Company A: Small startup in a non-profit space. Technical part was an informal chat with a current tech lead, which led to them sending me a list of high level general questions around architecture and design to be discussed on a follow up call, then it moved on to a third non-technical round. Good approach overall, I appreciated being able to prepare in advance instead of being given a pop quiz, and I think it unpacked my skills pretty well. Total time maybe 3 hours? It led to an offer.

* Company B: Medium sized ecommerce company. Technical part was a live coding challenge via screen share, with a tech lead and an engineering manager watching. Think "given this list of categories and items, how would you loop over it to find the item with the highest cost? How about all the items in a specific category? How about all green items in any category?"; a very simple problem, used purely as a jumping off place to discuss thought processes, trade offs, approaches, tools, algorithms, etc. I dislike live coding challenges, but this was about as good as could be expected, and led to two more follow up round of high level architecture and design questions. Three total rounds, each 1 hour. Again led to an offer.

* Company C: Medium sized developer tooling company. Started with an take-home assignment that was very poorly defined. I was verbally told it should take "an evening" and "don't take it too seriously", but as I later found out they were expecting more like 18+ hours, finished to the standard you'd expect in production, ie, thorough unit tests, good code coverage, carefully chosen variable and method names, completely documented, all edge cases handled, etc. I didn't make it to round two, which would apparently have been a rigorous code review exercise on the code from the first step, which at the point I'm counting as a win.

I honestly disliked the coding challenge from company B, and semi-enjoyed the one from company C (or what I thought they were asking for). But I'd have been reluctant to spend the incredible amount of time they expected on an unpaid coding challenge even if they'd managed to convey they wanted that, which they didn't.

So based on my experience, about 1/3 of companies out there have terrible interview processes.

Still sounds like a good ratio, I'd say.

Live coding isn't very, but I found live code review + occasional adjustments quite effective when interviewing candidates.

And to add the other side of things: as an interviewer, I do check.

Inflating your skillset is going to get you into the wrong interviews, and you'll do poorly in them (and consequently will have these kinds of negative experiences). Either accurately represent or slightly undersell yourself; it comes off much better and will save you time and money.

I hate embellishing on resumes. Unfortunately when the game went from humans filtering resumes to automation/keyword filtering, it's and unfortunate requirement. Sanitation Engineer and all that.

Required keywords "Agile/Scrum" does not appear on this resume, rejected.

That's a fair point. We do very little algorithmic/automated filtering, so I'm biased in my predilection.

If you use a headhunting firm, they certainly do.

We don't, at least to my knowledge.

Required keywords "Agile/Scrum" does not appear on this resume, rejected.

Is it really that bad now? If I were applying for employee roles today it would probably never have occurred to me that including "Agile" as a buzzword could be important to avoid getting filtered immediately. I can understand filtering someone for having no apparent experience in the main programming language you use if you have many other applicants who do. Filtering for something that basically every employer has claimed to do for about 200 years but no two of them would agree on what it means seems silly though.

This is not universally good advice. An interview is an obstacle that takes a limited amount of time. It can only approximate someone's true skill set.

One can oversell themselves based on their potential to learn and grow.

For example, if someone is a junior and they designed a micro-service with a senior but have a solid grasp of the process, then it's fair that they claim that they designed a micro-service. They can read up on the relevant concepts, answer a few questions in the interview and get a very nice opportunity in a cool startup. If they can learn to do it fast enough to be productive, then both they and the company are happy.

On the contrary, by underselling themselves or being accurate, they are more likely get a job at their current level of knowledge, which can limit their growth potential. Still, this can be a good idea if someone is already very experienced and doesn't want to spend a lot of energy to grow.

Same... and I got scolded by an recruiter after she asked me more questions about my experience.

She basically told me I am underselling some of the experience, and I should put some of it more, and perk it up a bit. It was very helpful.

Engineers have that. You have to take example a bit from real estate agents, on how they describe a place. Always highlight the positives.

I don't exaggerate or list things I don't have significant experience with, but a relative who's in recruiting keeps telling me I'm doing it wrong. But I think they mostly do recruiting for big companies with bad automatic filters or people who don't understand the job doing the first weed-out pass on the résumé pile, so maybe that's why.

The recruiter's interest and yours are not aligned. Recruiters would like everyone to list every skill on their resume. They have nothing to lose from you being interviewed for a position you're not suited for. And they get paid if you get hired into something that isn't right. Both these outcomes are less good, for you, than being interviewed less and only hired into jobs which are right for you.

Recruiters get paid per interview? Or directly when someone got hired?

I thought it was more common that they'd get paid per person hired and still at the job 3 months later? But I'm a bit clueless

no, they get paid when you are hired. but the more people they send to interview, the more likely they are to get a hire, whether a good one or an indifferent one.

Aha, they're happy with mediocre hires, just good enough -- although it could have been (much) better for the company with another person

A bit misaligned incentives in the same way as agencies have, I'm thinking

Please continue doing it. I have read too many CVs in my life. I can smell liars from just looking at their CVs. True, you might easier pass the HR/recruiter but latest when someone with a little bit of knowledge screens it, a liar is gone.

You might argue, that not every pipeline works like that! Right. But now imagine the consequences if you are hired. Independent whether you fail, think how toxic a workplace must be, if liars are regularly employed. The hiding. The avoidance of responsibility. The amount of bad solutions. The success stealing. The meeting slideshows. The horrible code. So many consequences.

Stay with the truth!

When directly asked about my git skills, I say something to the effect of "I've probably gotten myself into and out of most of the obvious sticky situations one can get themselves into. My main skills for getting out of them are 1. don't panic, and 2. look things up on google."

When I see a new grad say they're an advanced Java developer, I take it was a grain of salt. Then they don't remember what the associative array implementation is called in Java (HashMap). If you don't know your language's standard library implementation of common collections, you're not advanced.

But I make sure to not judge them on that. They're often over zealous and looking for a job, so I don't blame them. The content of the interview is the real meat and potatoes in my experience.

> But I make sure to not judge them on that. [...] The content of the interview is the real meat and potatoes

Which is to say, the difference between a genuinely good candidate and one that merely claims to be is clearly visible in exactly the kind of interview the linked article is arguing against.

I think there's lots of room for criticism of the Big Tech Coding Interview. But "it doesn't work" is just not reasonable. It does work, it objectively works very well, probably better than other techniques (the existence proof being that there aren't any other hiring organizations out there beating the FAANGs at their own HR game).

If you want to criticize, point out that it doesn't necessarily work fairly. It rejects specific qualified candidates more often than it should, and it fails to reliably measure other areas of qualification than mere technical skill.

But don't say it doesn't work, or that it's a waste of time. Show, don't tell. If you know how to hire better people, then do so and beat the world.

I have one and it’s quite difficult because it requires the interviewer to know their shit: drill down on a feature or technology listed in the resume in the interview with the developer. Get into the technical scope, the tradeoffs, pinch points and cruxes of problem set. Understand what the definition of success was in that feature and the individual contribution involved. A dev who only passably did the work or did so heavily relying on others expertise won’t be able to answer precise trade off questions in this way. Ultimately though if they did the work they did the work, and that’s more important than any leetcode/trivia nonsense.

People have been re-discovering this technique for over a decade now at least. It's actually used at quite a few big tech companies, but only for strategic hires.

You touch on one of the reasons this technique isn't used in general:

> it’s quite difficult because it requires the interviewer to know their shit

Having an interviewing team in an engineering org n > 100 with the following properties is nearly impossible:

1. Everyone knows their shit

2. Everyone cares enough to give the interview well

3. Has enough throughput to meet the company's hiring needs

4. The interviews are given in such a way that legal isn't worried we'll get slapped with a discrimination lawsuit

> If you don't know your language's standard library implementation of common collections, you're not advanced.

Heh. I've written production code—and lots of it—in... god, eleven or twelve languages? Not counting transpile-to-JS languages—add another two for that. Also not counting markup languages or CSS or anything like that. Oh, and I forgot bash, if that counts (not sure I'd count it).

I'd probably get stuff like "how do you declare & populate an associative array?" wrong in at least half of them, and the others I'd basically be guessing but luckily several accept syntax so similar that if I used it on all of them I'd be correct in enough cases to get me up to about half-right. I'd have about as much trouble with this task in languages I last wrote fifteen years ago, as ones I wrote code in today.

Stuff that's common to most or all languages, I tend not to keep in my head. Any given language probably has this kind of feature, so I just expect it to be there, and not confined to any particular language. I crib off nearby code, let my tools tell me the correct invocation, or look it up. If it's anything even somewhat common, there's usually an example nearby to use as reference, so it hardly even slows me down. If it's uncommon enough in the codebase that I have to look it up or spend 10 seconds finding an example in some other file, that probably means I'm not having to do that often, so that's OK too.

That's fine if you're talking about languages you use infrequently, but if you can't declare and populate an associative array in the main language you're interviewing in you shouldn't be surprised if your interviewer fails you.

I usually try to drill syntax for about 30 minutes before an interview, for this reason—I'll forget it a few hours later, but that's fine, since it doesn't actually matter—but it's hardly ever been turned out to be a factor in a 20+ year career and 7 or 8 job switches, anyway. I mostly do it for my own peace of mind.

But to GPS point, if this is going to be the new production language for this person for the next period, they’re going to lookup how to do this in seconds and then be an asset to you. Would you really rather have the junior developer who knows the answer to this question off the top of their head, but has so many other lessons to yet learn that GP can bring to the table?

Honestly, once a person has demonstrated some proficiency in a cross section of languages, you should just skip the language proficiency section and instead talk about how learning new languages has gone in the past. Look for any red flags or biases that are going to be a hindrance in the new languages particular paradigm, but otherwise the “can you X” is already a done deal.

> but if you can't declare and populate an associative array in the main language you're interviewing in you shouldn't be surprised if your interviewer fails you.

What if I can google how to do that in all of the languages I've used (and many I haven't) faster than most can write it out from memory? How do I convey that to you and what is it worth to you?

Wrote memorization like that is one of my weaknesses but I can compensate for it. I heard an interesting theory that one aspect of intelligence is how efficiently you can forget information that you don't benefit from retaining. If our brains have finite storage capacity that seems pretty logical.

> how efficiently you can forget information that

I'm smarter than what I thought :-)

& frequently forget how to iterate through arrays and objects in Typescript although been using it for years

> if I can google

Sounds fine with me, or via an IDE, or pseudocode

I think I'm the same, I try not to list too much to stop spam. Professionally I do JavaScript/TypeScript and work with React so I write that.

I do like having a 'Familiar' section where I list languages I like to dabble with outside of work, generally where I can create a personal project but don't know the ins and outs. I find these useful to talk over in an interview as I don't want to come across as a very one-dimensional JS developer.

Reply on news.ycombinator.com