2qjbsw
Last Updated: February 25, 2016
·
1.16K
· mcansky
892a174c18182a2a3157e51cd071d1cf

The need for simple exercises

As I was going through job interviews some companies asked me to do simple coding exercises.

As I am now used to I solved those exercises using a TDD approach. Doing this I discovered it was a simple but helpful thing to do to improve my skills or keep them in good shape.

I knew this is the kind of thing that coding retreats and dojos are made of. So far I was wondering how helpful they were, I know now that they are probably quite helpful.

The solo experience

As I solved those little puzzles I quickly understood that it was more than just writing code. It was the opportunity to root deeper the habit of writing software using a TDD approach with KISS and other good practices.

Advices from different authors and friends came back to my mind I quickly started to hack away.

I pushed myself to slice the problem to very little concepts and steps. I then wrote tests for each followed by the code required to make the tests pass.
Once I had something working I would refactor what was possible.

The duo experience

I took the train to RuLu and tracked down a former colleague of mine and fellow Ruby developer as I knew he was in the same train. After 2 hours of travel and talks I suggested that we could do a series of small puzzles.

As he started to work on the solution of one of the exercise I had been asked to do in my job interviews I was amazed to see a different approach to the problem. I also saw how much I would try to push him in a specific direction instead of just watching and learning from his different technique. Yet I could not resist to tell him when he wrote code before tests.

He also encountered some locks that as he was trying to see too far ahead (imho). He would pause for a long time and try to fit a lot of functionality into one single method.

Am I using a functional approach ?

As I discussed that story with some friends at RuLu one of them pointed out to me that my approach was quite functional.

For example to implement a simple string compressor ('aaaabb' -> 'a4b2') I would split the process in the following steps :

  • split the input string
  • grab a letter from the array
  • check that letter with the previously picked one (if any)
  • group identical letters together
  • exchange a group by its compressed value
  • return the result or the original string if it was of shorter or equal length

This approach might not produce the fastest algorithm but I think it helps to have high modularity. This modularity allows me to keep each method simple which means that it can be tested and replaced simply too.

In a product context this approach now tend to keep my code super clean and lean, it also forces me to check my classes for proper single responsibility.
By being quite modular and tested it will also allow me to replace parts with external modules without fear of breaking things.

Does it make sense ? How could I improve this process ?

More ?

I think I will try to keep doing such puzzles every week or few weeks on my own or with a small group of fellow developers. This has proven to be interesting and source of improvements.

Say Thanks
Respond

1 Response
Add your response

7405
Profile

This would make a good code golf:

(s) -> ((if s[i-1]==c then n++;'' else "#{x=n;n=1;x>1&&x||''}#{c}") for c,i in s+"$").join("")[..-2]

In ruby:

s.chars.inject(Hash.new 0){ |r,c| r[c] += 1; r }.map { |k,v| k + "#{v if v>1}" } * ''
over 1 year ago ·