4 ms·

I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally wr

I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally write concise code on right off the bat when confronted with a new problem? I've always taken the same approach I would with writing: get something that works; refactor for concision. Maybe everyone else is playing 3D chess and I'm still on Chutes and Ladders?

tbrownaw 2y ago
There are degrees of conciseness. I've seen real code that looks like if(bool_var == false) { other_bool_field = true; } else if(bool_var == true) { other_bool_field = false; } Which I suppose could be called anti-concise.
- deleted 2y ago
  [deleted]
- andrewflnr 2y ago
  Yes, even the "unconcise" first draft of anyone who cares enough to be here on HN is much better than some of the code out there. There's a basic level of concision you'll have by default if you actually understand the problem and the tools. You won't go away out of the way to complicate things. Maybe it's still a far cry from optimal, and definitely not code golf, but enough that I'd be worried if I saw even a first draft without it.
- BrandoElFollito 2y ago
  yes, when writing this as other_bool_variable=!bool_var you make it much better because the code speaks for itself ("other_bool_variable is the opposite of bool_variable"). The risk is that you may end with such concise code that nobody understands what it does. I went that dark path with perl 20 years ago, form "oh what a cool language for someone who comes from C" to "let's squeeze that in half a line, and either do no understand what it does, or add three lines of comments to explain". But yes, there is a good middle-groud somewhere
- spacebanana7 2y ago
  When I see code like that, I wonder whether a beginner is trying to fix a bug where they unexpectedly copied by reference rather than value.
- sangpal 2y ago
  I wouldn't consider if (bool) or x = !bool to be concise coding. That's just regular code.
awesome_dude 2y ago
Yeah - when I went through University the mantra I was taught was 1. Get it working 2. Get it working well If you're faced with an unfamiliar domain, you don't rock up to it and throw all the super optimised fastest code at it. in fact I would view someone who did as having done the test before (making it worthless).
nerdponx 2y ago
Everyone thinks differently. "thing1 == thing2 == thing3" is a pretty natural expression of the idea here IMO.
jbverschoor 2y ago
But the code doesn’t work. That should be problem nr 1 for such a simple problem. Syntactical sugar doesn’t matter anymore at that stage
- encomiast 2y ago
  Maybe I misunderstood the piece, but it seems the last sentence, "Well the code is indeed correct" suggests it _did_ work (although I'm also a little confused about what it means when all values are '-' which I interpreted as 'no piece played').
  - jbverschoor 2y ago
    The code might compile, but it does not functionally with in an empty game state. Resulting in an always win for the first player if he does not play on any diagonal
userbinator 2y ago
Do people generally write concise code on right off the bat when confronted with a new problem? As someone who has been on the interviewer side: this is an indicator of how much the interviewee "thinks first"; the ones who immediately start spewing tons of code are usually those who don't really have a good understanding of what they're trying to do.
- bowsamic 2y ago
  Thinking first is a very Cartesian approach to development and not necessarily the best way. Many people think through a more engaged approach of doing
- davedx 2y ago
  As someone who's done a lot of interviews on both sides: I get where you're coming from but don't really think it's as universal as you think. Some people gain understanding through doing; and there's nothing wrong with that?
- huhtenberg 2y ago
  Exactly, amen to that. Think first, code second.
- dkdbejwi383 2y ago
  Thinking by doing is also valid. I code similarly to how I write, which is similar to how I draw etc. I start with very rough ideas and sketches, then I gradually iterate over those, refining ideas and throwing bits away. And eventually I have a working version/first draft/etc I just can't get things done if I were to try and think of the entire solution first before getting anything down on paper. Maybe that's an ADHD thing, needing to let the idea take form lest it runs away and I get lost in the weeds It's less "spewing tons of code" though and more starting with an outline, stub functions and comments to break up the steps before filling those out.
atoav 2y ago
There are problems I have encountered a billion times and of course I have an elegant concise solution for it, if I am an experienced programmer. if any([a in ["-h", "--help"] for a in args]): display_help() Would be one of those. Generally I learned that it can be beneficial to treat things as lists early on, e.g. if you have a program that takes one input file it costs you next to nothing to allow the input to be mutiple files as well.
- ckastner 2y ago
  That still looks like something that a novice might trip over when reading this. Just describing what it does is already a bit convoluted: it tests whether any value of a list of booleans, produced by a generator expression by testing membership of a value in some other list, is True. I would have gone with the following, as it requires less mental unpacking: if set(args) & set(["-h", "--help"]): display_help() Also, note that any() works with any iterable, the outer brackets are not needed given the list expression. if any(a in ["-h", "--help"] for a in args): display_help()
  - dijksterhuis 2y ago
    on my phone and a bit discombobulated today, so we’ll see how i go with this > That still looks like something that a novice might trip over when reading this. my experience with “juniors” who start with python is that they think in lists and dictionaries. they don’t think in terms of set theory. that’s just the way python is taught. i would definitely set interview questions where a “decent” solution involves using sets and see who gets it without iterating over lists (ha, setting an interview question on sets… geddit? i’ll see myself out). > Just describing what it does is already a bit convoluted yeah, but python only/main “juniors” primarily think in terms of lists, see above. so, between making sure all juniors can read the code versus doing it succinctly, but juniors all need to learn about sets — practicality wins out quite often. > I would have gone with the following, as it requires less mental unpacking: > if set(args) & set(["-h", "--help"]): > display_help() if i were reviewing this code i’d ask you to switch it to if set(args).intersection(set(["-h", "--help"])): it is more verbose and more brackets, but it is more explicit and obvious what is happening to some junior who has never dealt with sets before (hmm what’s an intersection? should probably google it) & is also used for the bitwise AND operator. plus some other stuff in various frameworks like django. so could lead to some confusion. > Also, note that any() works with any iterable, the outer brackets are not needed given the list expression. i generally HATE the overuse of generator expressions in python. everyone writes absolutely everything as an inline generator expression, making it hard to test. but, rant aside, yes, this is probably the one i would pick during a review (likely after a discussion about how using the intersection method makes things less legible and then this gets suggested somewhere). people don’t realise not every genexp needs to be a list. easy mistake to make with the “everything is a list or a dict” mental model.
kdhusakdjhsadkj 2y ago
[dead]
blitzar 2y ago
if you know the domain for the task at hand (+a few very basic soft skills) you can learn a lot from watching and discussing with a candidate while they are doing the task. In reality - tasks like these are garbage leet-code samples; candidated who have been grinding examples rapidly regurgitate the best solution from the forums and impress the interviewer, but would fail if asked a basic question on what they produced. Those that solve it reasonably from first principles fail the task.
eterevsky 2y ago
I also judge code quality at the interviews that I perform. I just give the candidates time to improve their code after they come up with something working.

tbrownaw 2y ago

There are degrees of conciseness. I've seen real code that looks like if(bool_var == false) { other_bool_field = true; } else if(bool_var == true) { other_bool_field = false; } Which I suppose could be called anti-concise.

deleted 2y ago
[deleted]
andrewflnr 2y ago
Yes, even the "unconcise" first draft of anyone who cares enough to be here on HN is much better than some of the code out there. There's a basic level of concision you'll have by default if you actually understand the problem and the tools. You won't go away out of the way to complicate things. Maybe it's still a far cry from optimal, and definitely not code golf, but enough that I'd be worried if I saw even a first draft without it.
BrandoElFollito 2y ago
yes, when writing this as other_bool_variable=!bool_var you make it much better because the code speaks for itself ("other_bool_variable is the opposite of bool_variable"). The risk is that you may end with such concise code that nobody understands what it does. I went that dark path with perl 20 years ago, form "oh what a cool language for someone who comes from C" to "let's squeeze that in half a line, and either do no understand what it does, or add three lines of comments to explain". But yes, there is a good middle-groud somewhere
spacebanana7 2y ago
When I see code like that, I wonder whether a beginner is trying to fix a bug where they unexpectedly copied by reference rather than value.
sangpal 2y ago
I wouldn't consider if (bool) or x = !bool to be concise coding. That's just regular code.

awesome_dude 2y ago

Yeah - when I went through University the mantra I was taught was 1. Get it working 2. Get it working well If you're faced with an unfamiliar domain, you don't rock up to it and throw all the super optimised fastest code at it. in fact I would view someone who did as having done the test before (making it worthless).

nerdponx 2y ago

Everyone thinks differently. "thing1 == thing2 == thing3" is a pretty natural expression of the idea here IMO.

jbverschoor 2y ago

But the code doesn’t work. That should be problem nr 1 for such a simple problem. Syntactical sugar doesn’t matter anymore at that stage

encomiast 2y ago
Maybe I misunderstood the piece, but it seems the last sentence, "Well the code is indeed correct" suggests it _did_ work (although I'm also a little confused about what it means when all values are '-' which I interpreted as 'no piece played').
- jbverschoor 2y ago
  The code might compile, but it does not functionally with in an empty game state. Resulting in an always win for the first player if he does not play on any diagonal

userbinator 2y ago

Do people generally write concise code on right off the bat when confronted with a new problem? As someone who has been on the interviewer side: this is an indicator of how much the interviewee "thinks first"; the ones who immediately start spewing tons of code are usually those who don't really have a good understanding of what they're trying to do.

bowsamic 2y ago
Thinking first is a very Cartesian approach to development and not necessarily the best way. Many people think through a more engaged approach of doing
davedx 2y ago
As someone who's done a lot of interviews on both sides: I get where you're coming from but don't really think it's as universal as you think. Some people gain understanding through doing; and there's nothing wrong with that?
huhtenberg 2y ago
Exactly, amen to that. Think first, code second.
dkdbejwi383 2y ago
Thinking by doing is also valid. I code similarly to how I write, which is similar to how I draw etc. I start with very rough ideas and sketches, then I gradually iterate over those, refining ideas and throwing bits away. And eventually I have a working version/first draft/etc I just can't get things done if I were to try and think of the entire solution first before getting anything down on paper. Maybe that's an ADHD thing, needing to let the idea take form lest it runs away and I get lost in the weeds It's less "spewing tons of code" though and more starting with an outline, stub functions and comments to break up the steps before filling those out.

atoav 2y ago

There are problems I have encountered a billion times and of course I have an elegant concise solution for it, if I am an experienced programmer. if any([a in ["-h", "--help"] for a in args]): display_help() Would be one of those. Generally I learned that it can be beneficial to treat things as lists early on, e.g. if you have a program that takes one input file it costs you next to nothing to allow the input to be mutiple files as well.

ckastner 2y ago
That still looks like something that a novice might trip over when reading this. Just describing what it does is already a bit convoluted: it tests whether any value of a list of booleans, produced by a generator expression by testing membership of a value in some other list, is True. I would have gone with the following, as it requires less mental unpacking: if set(args) & set(["-h", "--help"]): display_help() Also, note that any() works with any iterable, the outer brackets are not needed given the list expression. if any(a in ["-h", "--help"] for a in args): display_help()
- dijksterhuis 2y ago
  on my phone and a bit discombobulated today, so we’ll see how i go with this > That still looks like something that a novice might trip over when reading this. my experience with “juniors” who start with python is that they think in lists and dictionaries. they don’t think in terms of set theory. that’s just the way python is taught. i would definitely set interview questions where a “decent” solution involves using sets and see who gets it without iterating over lists (ha, setting an interview question on sets… geddit? i’ll see myself out). > Just describing what it does is already a bit convoluted yeah, but python only/main “juniors” primarily think in terms of lists, see above. so, between making sure all juniors can read the code versus doing it succinctly, but juniors all need to learn about sets — practicality wins out quite often. > I would have gone with the following, as it requires less mental unpacking: > if set(args) & set(["-h", "--help"]): > display_help() if i were reviewing this code i’d ask you to switch it to if set(args).intersection(set(["-h", "--help"])): it is more verbose and more brackets, but it is more explicit and obvious what is happening to some junior who has never dealt with sets before (hmm what’s an intersection? should probably google it) & is also used for the bitwise AND operator. plus some other stuff in various frameworks like django. so could lead to some confusion. > Also, note that any() works with any iterable, the outer brackets are not needed given the list expression. i generally HATE the overuse of generator expressions in python. everyone writes absolutely everything as an inline generator expression, making it hard to test. but, rant aside, yes, this is probably the one i would pick during a review (likely after a discussion about how using the intersection method makes things less legible and then this gets suggested somewhere). people don’t realise not every genexp needs to be a list. easy mistake to make with the “everything is a list or a dict” mental model.

kdhusakdjhsadkj 2y ago

[dead]

blitzar 2y ago

if you know the domain for the task at hand (+a few very basic soft skills) you can learn a lot from watching and discussing with a candidate while they are doing the task. In reality - tasks like these are garbage leet-code samples; candidated who have been grinding examples rapidly regurgitate the best solution from the forums and impress the interviewer, but would fail if asked a basic question on what they produced. Those that solve it reasonably from first principles fail the task.

eterevsky 2y ago

I also judge code quality at the interviews that I perform. I just give the candidates time to improve their code after they come up with something working.