The last time I interviewed and did a few LC problems, it was my experience that most of them were trivially solvable by some combination of implementing an iterator, doing a fold, and maybe adding memoization. Not every problem obviously, but those 3 steps seem to pretty generically cover most easy/mediums that will come up in a coding skills interview. When I got my first job, I didn't know what any of those things were, so I've also found coding interview problems to have become easier for me over time.
I've never used much Python in my day job, but the `yield` keyword is basically overpowered for LC problems.
You would be surprised (or maybe you wouldn't) at how many applicants get filtered by extremely basic elements of a tech test that's specific to the employer and therefore not something that can just be memorised or drilled. It's a low bar, but it can be a very worthwhile one.
There's a second factor, too, which is that sometimes you want an easy test so that you can judge coding style. You need to be careful not to ding people who don't already use whatever your house style is (which has bitten me in the past) but you generally do want to see something that you can have a style conversation about.
This is true; however, based on my experience the interviewers are usually very dissatisfied to discover such "one simple trick", the implicit expectation being that you are expected to gruel through the problem without abstractions.
This part has been always funny to me, because the same interviewers also simultaneously expect knowledge of abstractions in their "low-level design" phase of the interview, where irrelevant abstractions are added in to satisfy some odd constraint that would never come up in the real world.
Yeah I realized you are at a significant disadvantage by not interviewing in python especially when you get some problem that requires parsing some input. IMO it is worth it to spend a couple of weeks practicing python before doing any technical interview.
I interviewed at Amazon and they told me I could pick any language. I chose C and I managed to get the test competed in time, but after I was done the interviewer started asking me questions about how my code worked and it quickly became evident that they didn’t know C. Should have picked Python..
I'm sorry - at this point in time Python is the only language I expect every single developer to know. You don't have to be an expert, you don't have to like it, but you need to know it.
Why? Firms that don't use it aren't going to use it, and there are a whole lot of firms out there that don't use it.
Plus: grammars that define scope by indentation level can all fucking die in a fire. I don't have nearly enough digits to count the number of times a customer mis-indented a deeply-nested section of a YAML file and caused absolute (very-difficult-to-diagnose) havoc in their environment. [0] IME, Python is not any better than YAML in this regard.
[0] Yes, I'm aware that there is a whitespace-insensitive syntax for YAML. However, it's not the default, and you can't use every YAML construction in it, so it is -IME- rarely used.
I never said every firm has to use Python, I said every developer needs to know Python basics. I'm old enough to remember a time when every developer needed to know Pascal, even though very few firms actually used it. It was simply a universally known language to assess one's skills. So it is today with Python.
WRT your rant against Python's used of indentation, most people I know aren't a fan, but editors take care of it and it's rarely an issue. It's not a problem for a whiteboard exercise.
> It was simply a universally known language to assess one's skills. So it is today with Python.
I've had... several... interviews over the years. Zero of them used Python. Might be that you're just in a corner of the industry that loves Python for some reason.
> ...most people I know aren't a fan, but editors take care of it...
I've had editors totally screw up indentation of copied and pasted Python code many, many times. Editors might get it right much of the time, but they absolutely do not (and provably cannot) get it right all of the time. On top of that, visually finding whitespace errors is far, far harder than visually finding enclosing-scope-signifier errors.
> ... and it's rarely an issue.
All sorts of things are rarely an issue until they're an issue. And then when they're an issue, they're often a big fucking deal. [0]
Don't you agree that we (as an industry) should be working to reduce the number of footguns in the world?
[0] Ferinstance, if everyone used an editor that treated YAML as a tree of nodes and used a strict schema [1] to control what nodes you could add where, then that customer havoc I mentioned wouldn't have happened. But, when Corporate Security only gives you SSH access to the restricted-access system that you're currently repairing, running such a tool is simply out of the question. So, one uses a text editor to make one's changes. In situations like this, removing every footgun possible from the work area is very, very important.
[1] Schemas? For YAML? I wish. I really, really do.
> Don't you agree that we (as an industry) should be working to reduce the number of footguns in the world?
Sure. The problem is everybody and his brother have an idea for what that looks like. There's no universally agreed-upon consensus of what a footgun actually is, which makes it rather difficult to remove them. I've been creating software for over 40 years now and the only constant truism I've discovered in that time is people will find reasons to bitch about something. Some people hate braces. Some people hate wordiness. Some people hate parenthetical statements. Some people hate math and "mathy-looking" languages. It goes on and on. And that's just syntax! We can go down several rabbit holes WRT how to handle errors.
Meanwhile, according to the latest TIOBE index, Python is the #1 language, followed by C++ and then C.
As I keep saying, you don't have to like Python, you don't have to use it, but you should be able to whiteboard it. And whiteboards don't give two fucks about whitespace.
Cool. I'm glad you agree. Given that we're talking about a particular entirely-avoidable footgun, there's nothing more to be said.
> TIOBE
Oh boy, there are assloads of very valid critcism of TIOBE's popcon. You should take a look at their methodology some time:
> Since there are many questions about the way the TIOBE index is assembled, a special page is devoted to its definition. Basically the calculation comes down to counting hits for the search query +"<language> programming"
See [0] for more embarrassing details.
> And whiteboards don't give two fucks about whitespace.
Given that you're late-career, you may be unaware that very many interviews are done remotely these days. So, no, whiteboards absolutely do give many fucks about whitespace these days.
web programming is probably on the 3rd or 4th rank of what python is used for nowadays
Also, you don't really need to "learn" python. I mean, if you have been in this industry for long enough, it's the kind of languages that you can pick up in 1 afternoon. That's just how basic and easy it is. That's why it's so popular despite all its flaws. Like I'm sure you somehow already know python, even if you never used it.
There's a distance from knowing Python enough to find your way around in projects to knowing it enough to solve coding riddles. The latter requires the level of familiarity attained only with regular use. Plenty developers go by their daily jobs without having to write a single line of Python.
I'd actually say it's the former that requires familiarity with the language. The latter only requires you to know some basic looping/control constructs. You don't need to know anything about classes or modules, for example. No need to understand async vs threads vs multiprocessing.
Honestly if you write psuedocode for an algorithm, there's a decent chance it'll be correct Python even if you've never seen Python.
> it's the kind of languages that you can pick up in 1 afternoon
Yeah nah. Especially not for current Python, which is quite a bit more complex and involved than it was 20 years ago.
Of course you can get some stuff done in Python on your first afternoon, but that's true for most mainstream languages. And that's nowhere near the same as actually knowing what you're doing.
I agree, but the context is to pick it up well enough to do coding interviews. Which I think is fair. People can pick up enough python for coding interviews pretty easily.
For what it's worth, I've mainly used it for utility and test scripts, including tests when I worked in firmware development. I think it's a poor fit for web development or large projects.
I've never used much Python in my day job, but the `yield` keyword is basically overpowered for LC problems.