The cost of DRY (Don't Repeat Yourself)-ing up your code can be high, in that it increases the coupling of your code, and potentially lowers its cohesion.
Consider function def foo(a: int), called from call sites C1 and C2. Eventually C1 wants something out of foo() that it doesn't offer, but, critically, something that C2 _doesn't care about or need_. The author of foo() adds a new default argument: def foo(a: int, b:int = 0), and then there is a conditional block in foo() that deals just with this new b argument.
You've now potentially broken callsite C2, by exposing it to changes that it doesn't care about it. Put another way: you should only deduplicate the code of _all_ the call sites will _always_ change for the same reason. Otherwise, you're lowering code quality of the code by increasing coupling and lowering cohesion. Copy and pasting the code in this case makes sense, because C1 and C2 both have entirely different needs out of foo(). Overtime, foo() will accumulate more and more default arguments as the author stridently attempts to keep everything DRY, and the overall code base becomes more and more fragile.
This interview question is good for kids recently out of school, but for everyone else I think it doesn’t really show if the candidate is a good developer.
Good taste — writing cohesive, loosely coupled code with a sensible bank of unit tests an a strong dose of product sensibility — is largely orthogonal to being good at solving algorithmic or ds questions. One of the best developers I know, who makes seven figures a year a year (trading software), would likely bomb the second part of this question. Contrawise, a young researcher I know who has won multiple scholastic programming competitions and crushes leet code, would destroy this problem in seconds … and yet, I pity his coworkers who have to live with his atrocious code.
More accurately, he would first look at the interviewer like he was a dolt, and then bomb the question :)
Exactly right, thank you for saying this. I will never forget back in the 00s, when electronic market makers were squeezing out floor traders and the pits were closing down, an outraged floor trader exclaimed to me: “They’re using .. COMPUTERS! To trade!”, in a tone that suggested how grossly unfair and (in the spirit of many a hacker news comment) how insider-trader-y it was.
This is correct — very common practice in trading (I am currently sitting out one now!).
Generally they are 3-12 months in duration, although recently we are seeing much longer ones (24 months) from firms such as Citadel.
You generally draw full base salary, and healthcare comes from COBRA.
US-wide ban of non competes is good for hiring firms (they get the talent immediately), bad (allegedly) for firms from whom the talent is leaving, and mixed for the workers themselves (for whom the garden leave can be sometimes received as a paid sabbatical). It will be a really big change.
The most played game in Vassal right now is the very popular Xwing miniature combat (http://xwvassal.info/).
Sadly the Vassal devs seem to have lost the flame for the project. A big client side rewrite to get off of Java was planned for many years but never executed.
The cost of DRY (Don't Repeat Yourself)-ing up your code can be high, in that it increases the coupling of your code, and potentially lowers its cohesion.
Consider function def foo(a: int), called from call sites C1 and C2. Eventually C1 wants something out of foo() that it doesn't offer, but, critically, something that C2 _doesn't care about or need_. The author of foo() adds a new default argument: def foo(a: int, b:int = 0), and then there is a conditional block in foo() that deals just with this new b argument.
You've now potentially broken callsite C2, by exposing it to changes that it doesn't care about it. Put another way: you should only deduplicate the code of _all_ the call sites will _always_ change for the same reason. Otherwise, you're lowering code quality of the code by increasing coupling and lowering cohesion. Copy and pasting the code in this case makes sense, because C1 and C2 both have entirely different needs out of foo(). Overtime, foo() will accumulate more and more default arguments as the author stridently attempts to keep everything DRY, and the overall code base becomes more and more fragile.