Slices of pizza


A logic test from a job selection process:

Cut slices of a pizza with exactly 8 straight cuts. How many (at most) slices can you get?

Solution

  1. With 0 cuts I get 1 slice, i.e. the whole pizza.

  2. With 1 cut I get 2 slices, wherever I cut the pizza through.

  3. With 2 cuts I get 4 slices, if the second cut crosses the first one at any point (inside the pizza).

  4. With 3 cuts I can make a straight cut that crosses all of the previous cuts at different points (inside the pizza).

    • Each cut defines two slices (one on each side)

    • but N cuts define N + 1 slices

      because N – 1 slices are shared between each cut and the next, thus 2N – (N – 1) == N + 1.

    • I’m crossing all the N = 2 cuts from the previous step, which define N + 1 == 3 slices of the X = 4 slices.

    Thus I now get X – (N + 1) + 2 * (N + 1) slices == X + N + 1 == 4 + 3 == 7 slices.

  5. With 4 cuts, I get 7 + 4 == 11 slices.

  6. With 5 cuts, I get 11 + 5 == 16 slices.

  7. With 6 cuts, I get 16 + 6 == 22 slices.

  8. With 7 cuts, I get 22 + 7 == 29 slices.

  9. With 8 cuts, I get 29 + 8 == 37 slices.

12 Parties


A logic test from a job selection process:

A nation’s people can vote for members of parliament from 12 parties. One voter must cast only one vote for one representative. If a party doesn’t get more than 5% of votes, then it won’t get any chairs in the parliament. How many chairs can get (at most) the party which collects 25% of votes?

Solution

  1. If V1 == 25%, then Sum(Vi, i=2..12) == 75%

  2. The best for P1 would be that the other parties get 5% of votes, so that they lower the 75% but don’t get any chairs.

    • 5% * 11 = 55% < 75%
      11 other parties cannot get 5% each because there are no parties left to absorb the remaining 20% of votes.

    • 5% * 10 = 50% -> V2 = 75% – 50% == 25%
      10 other parties can get 5% each instead because the remaining party can get the remaining 25% of votes.

  3. Only P1 and P2 will share the parliament, and each of them with 50% of the chairs.

About uniformity

Use uniform schemes, at least project wide, if not company wide.

When an engineer is a world apart, allowed to work alone on a big chunk of functionality, during a few weeks in a row, they produce lots of code which is seldom harmonized with the rest of existing functionalities.

Why does this happen? There are many reasons. Clearly there is little to no interest in improving code quality at a management level, because they think that technical debt can always be fixed later by adding more cheap laborers, when it’s probably the exact opposite of that, i.e. you can always add more cheap laborers to produce more code if the technical debt is kept at bay along time.

Another reason is that the size and number of code changes in a single merge request makes it nearly impossible to perform meaningful code reviews, and in fact seasoned reviewers skim through them very fast and accept true atrocities.

For example, in the same API

  • they allow the same properties to have different names, having to use one or the other depending on the state of the object, like
    • activeGroup.name
    • pendingGroup.groupName
  • they allow the same concepts to have different values, having to use one or the other depending on the endpoint you use, like
    • operations = ['CREATE', 'UPDATE', 'DELETE'];
    • operations = ['C', 'U', 'D']
  • they allow the same operations to have different results’ structures, like
    • `POST {name: ‘John’, age: 32}
      • success response: {name: ‘John’, age: 32, created: …}
      • error response: {error: ‘Age should be less than 30’}`
    • `POST {city: ‘Barcelona’, temperature: ’18 C’}
      • success response: ‘OK’
      • error response: {msg: ‘Italian cities only, please.’}`

Of course there are many more typologies of incoherences in some code bases.

It could seem that they are just little inconveniences but they contribute lots of lines of code to the app. For example, a thing so simple like comparing two instances of the same document in different states, becomes a mess (i.e. more intricacies and bugs) when the names of the properties change according to the state.