[dakiol]

I’m divided. I can do what you ask, but not without googling it. I can produce performant and robust code, but not without double checking on google. I’m unable to deliver code that compiles in any language without checking the documentation. Pseudocode, yeah sure.

So, I wouldn’t pass these kind of interviews. In over a decade I’m never being asked these kind of questions though (I have done take home assignments and leetcode, but always with google opened)

[bondarchuk]

Reality check: if you say on your resume that you know python, then you should be able to make a dictionary with three items and assign it to a variable without googling anything.

[dakiol]

Fair point. I don’t like resumes in which people state that they know X or Y. I prefer the ones focused on what problems were resolved using what technologies.

I have used Python to solve average business problems, yet I cannot produce non trivial code without looking at the documentation. Same for the other dozen programming languages I have used in the past.

[knome]

>yet I cannot produce non trivial code without looking at the documentation

    hello = {1:1, 2:2, 3:3}

is about as trivial an ask as someone can make.

[skydhash]

I know enough python to read Calibre's code and understand it, but I keep forgetting syntax details and the actual name of methods and properties, because I'm influenced by whatever language I've been writing in lately. I know what to do, but it will be pseudo-python-code.

That can usually be solved by a quick read of the reference documentation (2-5 mn?).

[knome]

That's fair. After you know more than a few languages, it's easy to know what you want to express in it and the limitations it has, while the particular name they happened to give those concepts is pretty arbitrary and quickly peeked at if you haven't used it in a while.

For my part, I've written enough python that I doubt the literal syntax will ever be far from my fingers.

[wwweston]

One of the things that can be tricky about this happens when you’ve legit worked in a few languages and the semantics are perfectly clear in your head but the syntax for any language you haven’t used recently is crowded out by those you have.

I needed a small perl script recently (perl 5’s feature set & stability plus availability in the environment made it the right fit) and realized after 15+ years of no perl much of the specific syntax was fuzzy to outright gone from my head even though I’d contributed to large perl projects for years.

Python work is much more recent, but I’d bet I would accidentally mix in some JS or even PHP syntax doing the dictionary assignment, at least w/o a cursory lookup. I’d like to think it’d come through that I know what a dict is and what it means to set one up and operate over it, but who knows, I might be interviewing with someone who is evaluating skill on the basis of immediacy of syntactic recall.

[gverrilla]

dict_variable = {1: 2, 3: None}

[segfaltnh]

And you work full time as a software engineer, or some other role? Honestly blown away if you work as a programmer that this sort of request would require looking at documentation.

[albertP]

I think it gets harder to remember exact syntax details the more experience you have and the more you have worked with different (but very similar) programming languages. I get what OP means: if you have worked with Ruby, JS, Python, Go, PHP, Kotlin, etc., you can easily misremember things like the order of parameters for a given function, whether if conditions require parenthesis, to use {} or [] for maps, etc.

If you have just started your career and are full invested in 1 or 2 programming languages, sure this may sound alien to you.

[segfaltnh]

I get it. I've done a ton of languages too. But, like, that's so ridiculously easy to handle in an interview, right? "I think it's like this [show example], but maybe the hash rocket style is Ruby and it's actually colons. Either way, you get the idea."

If your interviewer finds that problematic, well, that's on them.

[Toutouxc]

Not who you asked, but I work full-time as a Ruby dev. Off the top of my head, I don't remember the order of arguments of the #reduce method block (it's the opposite of what Elixir uses), the exact syntax of the throw/catch mechanism (in Ruby this isn't exception handling), the methods and parameters for writing into a file, bitwise operators, I always ask a LLM about packing/unpacking bytes between arrays and binary strings and many other things. I also mix up #include? and #includes? because these differ between Ruby and Crystal, and there's also #includes in Rails (AR).

So, the equivalent of creating a dictionary, yeah, sure. But there's loads and loads of stuff that I only use maybe once a week (and someone else maybe uses daily) and that I'd have to awkwardly Google (I use Kagi btw) even during an interview.

[segfaltnh]

Same reply as above, you'd easily be able to speak to this in an interview and not hit the "fraud" alarm. "I think it's accumulator, element here on reduce, but I may have them transposed."

Your interviewer is probably also questioning if it's (a, e) or (e, a), but you passed the fraud filter.