4 ms·

I'd add to this list some simple binary logic questions. I've noticed that some programmers struggle with De Morgan's laws. Also many prefer to write hardcore o

by jakub_g 11y ago

I'd add to this list some simple binary logic questions. I've noticed that some programmers struggle with De Morgan's laws. Also many prefer to write hardcore one-line boolean expressions, often with multiple negations, instead of splitting it into smaller subexpressions assigned to properly named variables. An interesting question would be hence to show a candidate some complex, buggy logical one-liner, with the comment above the code stating something different than the code actually does, and ask him to fix it. A good candidate should extract booleans out of it and then see the flaw in reasoning, fix a bug, and perhaps write code so self-explanatory, so that the comments can be removed.

jonsen 11y ago
Do they do that when hiring mechanical engineers? Make them fix a Rube Goldberg design?
- jakub_g 11y ago
  IMO fixing bugs and refactoring complex code is a part of daily job in any long-lasting project (especially when there's big rotation), hence it makes sense to check for that in an interview - contrary to asking some stuff that a developer won't ever likely do in a project.
chrisbennet 11y ago
I froze up a bit in an interview over a DeMorgan's law equivalency question. All I could think of were Karnough maps. On the way home I palm slapped myself when I remember DeMorgan's... "not (A or B)" is the same as "(not A) and (not B)".
onion2k 11y ago
What you should be looking for in a candidate is the ability to do what a good developer would do in a real world situation. In your test a good candidate would just bin the opaque, broken code and write it from scratch in a better, more readable way. If something is quicker to rewrite something than it is to work out what the previous developer did wrong the right answer is always going to be a rewrite, and that's always going to be the case for a one-liner. If you want to test someone's ability to fix broken code then you need to give them a test that reflects that, not a test where you tell them not to work properly.
- Sir_Substance 11y ago
  Also, in the real world a candidate would probably google De Morgans laws. Coding is not bomb disposal, if anything it's bomb construction. I would argue it's desirable for a developer to look these complex-and-not-frequently-used concepts up when they need them, to ensure they are not misremembering. It would be better to test a candidates ability go search for good reference material than whether they can remember your specific question off the top of their head. Wouldn't you want your nitration chemist to be regularly looking at his textbook?
  - copsarebastards 11y ago
    De Morgan's laws are complex-and-not-frequently-used? What are you even programming? I don't want to hire programmers who have to constantly be looking up how to program--that's an enormous waste of time. It makes sense to be looking up APIs, because interfaces change and have caveats. But DeMorgan's laws, divide and conquer algorithms, basic data structures, should all be in your brain. These are the building blocks of software and if you don't have them you can't build software. > Also, in the real world a candidate would probably google De Morgans laws. So I hand you a function to optimize: def is_taxed(transaction): return (not transaction.buyer.is_nonprofit()) and (not transaction.location.is_duty_free()) What about this problem would indicate to the candidate that they should Google "De Morgan's Laws" if they didn't already know it?
    - onion2k 11y ago
      Most developers would be able to work out that the answer to the test is "return not (X or Y)" (unless Python has a nor operator.. I don't know because I rarely use it) without even realising they're using De Morgan's laws, but... 1. If the app is anything bigger than a trivial case there will be bigger things to optimize. Individual code optimizations give you so little in return they're rarely worthwhile. 2. Unless you're doing it millions of times a second you won't actually see the time saving. If you are then you're probably better off generating is_taxed when the transaction object is generated (eg generating and caching the result). 3. If you're still at the point where this change will actually make a difference you probably should be using something that isn't Python. I wonder if something like Nuitka would be able to optimize it automagically.

by jakub_g 11y ago

jonsen 11y ago

Do they do that when hiring mechanical engineers? Make them fix a Rube Goldberg design?

jakub_g 11y ago
IMO fixing bugs and refactoring complex code is a part of daily job in any long-lasting project (especially when there's big rotation), hence it makes sense to check for that in an interview - contrary to asking some stuff that a developer won't ever likely do in a project.

chrisbennet 11y ago

I froze up a bit in an interview over a DeMorgan's law equivalency question. All I could think of were Karnough maps. On the way home I palm slapped myself when I remember DeMorgan's... "not (A or B)" is the same as "(not A) and (not B)".

onion2k 11y ago

What you should be looking for in a candidate is the ability to do what a good developer would do in a real world situation. In your test a good candidate would just bin the opaque, broken code and write it from scratch in a better, more readable way. If something is quicker to rewrite something than it is to work out what the previous developer did wrong the right answer is always going to be a rewrite, and that's always going to be the case for a one-liner. If you want to test someone's ability to fix broken code then you need to give them a test that reflects that, not a test where you tell them not to work properly.

Sir_Substance 11y ago
Also, in the real world a candidate would probably google De Morgans laws. Coding is not bomb disposal, if anything it's bomb construction. I would argue it's desirable for a developer to look these complex-and-not-frequently-used concepts up when they need them, to ensure they are not misremembering. It would be better to test a candidates ability go search for good reference material than whether they can remember your specific question off the top of their head. Wouldn't you want your nitration chemist to be regularly looking at his textbook?
- copsarebastards 11y ago
  De Morgan's laws are complex-and-not-frequently-used? What are you even programming? I don't want to hire programmers who have to constantly be looking up how to program--that's an enormous waste of time. It makes sense to be looking up APIs, because interfaces change and have caveats. But DeMorgan's laws, divide and conquer algorithms, basic data structures, should all be in your brain. These are the building blocks of software and if you don't have them you can't build software. > Also, in the real world a candidate would probably google De Morgans laws. So I hand you a function to optimize: def is_taxed(transaction): return (not transaction.buyer.is_nonprofit()) and (not transaction.location.is_duty_free()) What about this problem would indicate to the candidate that they should Google "De Morgan's Laws" if they didn't already know it?
  - onion2k 11y ago
    Most developers would be able to work out that the answer to the test is "return not (X or Y)" (unless Python has a nor operator.. I don't know because I rarely use it) without even realising they're using De Morgan's laws, but... 1. If the app is anything bigger than a trivial case there will be bigger things to optimize. Individual code optimizations give you so little in return they're rarely worthwhile. 2. Unless you're doing it millions of times a second you won't actually see the time saving. If you are then you're probably better off generating is_taxed when the transaction object is generated (eg generating and caching the result). 3. If you're still at the point where this change will actually make a difference you probably should be using something that isn't Python. I wonder if something like Nuitka would be able to optimize it automagically.