The Genesis project

I have decided to start a new project, it’s purpose is two-fold:

  1. do something I am really interested in (random world generation)
  2. be an excuse to use some tech that I want to use and to learn some new ones I am interested in learning

For this project I will specifically make it a point to use :

  • F#
  • Bootstrap
  • Angular2
  • VS Code
  • .Net Core and ASP.Net Core
  • ASP.Net Web API
  • TypeScript

I will also try to do as much of the development as possible on Linux (Mint 17.3 XFCE edition with zsh and oh-my-zsh). Switching to Windows 10 and Visual Studio Community Edition when I need to.

If I see something that doesn’t work or that I don’t like along the way (say I want to replace VS Code with Atom or Angular with React), I won’t bat an eyelid and just make the switch.

The project itself will be a website that allows visitors to create and display a procedurally generated world. I am naming it after the Genesis device from Star Trek III.

I have already created the GitHub repo. My time is severely limited so I don’t know how much time I will be able to invest in this but I don’t mind going with a slow and sporadic approach since this is a personal interest project.

Google Play Store rating/recommendation system is broken and how to fix it

The Google Play store has an app rating/recommendation system. When you are on the main screen of the store it will show you an app you have installed and ask you to rate it using a star rating (no need to type in a textual review) so that it can recommend you other applications.

I used to be eager to fill these in, hoping it would find some gem that would suit my tastes. Sadly, I now realize the mechanism is fundamentally broken.

Here are two recent experiences I’ve had with this feature:

In the first case I had installed two weather applications on my phone. I tried both and didn’t like them. For one of these I wrote a negative review. I removed both and installed a third one. After a couple of days Google asked me to rate this new app. I gave it a four star rating. Google Play then prompted me to try some more weather apps.

This scenario has me, the user, searching for a specific kind of application and settling on one I like. My search for such an application has ended in a satisfactory way. Signaling my satisfaction shouldn’t prompt Google Play to suggest more alternatives.

In another case, the Play Store asked me to rate the to-do list app I have been using for the past few months. Since I really like it I also give it a strong rating.

Again the Play Store suggested more to-do list apps to install. A to-do list app is really something you only need one of.

How to fix it

The solution for this problem is to look at the type of app or product that is being rated. Is it a game, a widget, a productivity app, a book, a magazine?

Each of these broad categories could then be assigned a value indicating whether a good rating from the user would preclude the recommendation of similar apps or promote it.

So if I give a good rating, say 4 or 5 stars, to a weather widget the recommendation system would not suggest me another app with the same functionality.

On the other hand, if I give a poor rating to such an app, I would want Google Play to suggest some highly rated and popular alternative. I took the time to install and try out a particular type of app and clearly I’m not satisfied by it. Chances are I’ll be interested to find a better one.

Similarly, if I give a good rating to a sci-fi book or action movie it should offer more of the same. Movies, books, magazines and certain types of apps should continue to work the way they do now.

The system could be further expended to classify different types of apps or products. Rather than bunch all non-gaming apps in the same category it could be further improved by using the existing sub categories and even making finer distinctions amongst these existing sub categories.

It should also drill down further by using collected user data.

Do users of this app install similar apps in the same sub category after rating positively or not? This information could be collected (it probably already is) and then used to calculate the value of whether to preclude or promote similar results on a positive review.

This modification would make the current system much more useable.

Interview preparation

I have a pretty good track record when it comes to interviews. Although some of it has to do with software developers being in high demand, I also believe I have some talent for it.

If I do a series of interviews I will receive favorable replies from most employers. Some of this has to do with my level of preparation. While it is pretty involved and you can get by with much less, I find being thus prepared helps boost my confidence, which is perhaps the most important thing of all when it comes to interviews.

Here are some tips on the subject.

Interview preparation tips

1. Familiarize yourself with your resume.

You should already know all of this stuff but if you haven’t done any interviews in a long time it helps to go over your resume again. This will help you be sharp and give fast and exact answers to the interviewer’s questions (ie: how many years of experience with specific framework X). Answering rapidly will help project confidence.

2. Prepare answers to common questions.

There are some common non-technical questions that are often asked in interviews. Along the lines of: where do you see yourself in 5 years, why should we hire you in particular, what would your ex colleagues say about you, etc.

We all know these.

The trick here is to think about what is needed for the current position and what you could highlight from your experiences and existing skills that would be the best fit for those requirements. I like to do this thinking in advance and prepare for some of these questions. I don’t memorize exacts answers but rather think about the specific ideas I want to convey.

3. Read up on the company interviewing you

This is a given but I will list it here nonetheless. Do some quick research, even if it’s just reading a website on the company or it’s main product. Make an effort to show you did some basic research during the interview but try not to overbear the interviewer by completing each of his sentences with facts from your research.

4. Go over online sources that you use for personal promotion.

This could include your LinkedIn profile, personal website, blog and such. Make sure everything is up to date and take some time to freshen them up if need be. These may be looked at by the people interviewing you. They can also help you recall interesting stuff you did and that you could bring up during the interview.

5. Skim over favorite books

Skim rapidly over books you have already read and that inspired you. For me these would be books like The Pragmatic Programmer, Getting Real and Clean Code. I like to go over these and remember why they had inspired me in the first place.

Check for overall design tips and general concepts and make sure they are fresh in your memory.

6. Language and Frameworks

Go over and review technical details about the language and frameworks you have experience with or are interviewing for. Look for typical interview questions, read up on what was added in the latests versions.

7. Familiarize yourself with some design patterns

From time to time I still get questions similar to: “tell me about your favorite design pattern” or to talk about a specific design pattern of my choice. I usually re-check the details of two or three patterns I already know just to make sure everything is still fresh in my mind.

10. Fizzbuzz and other interview coding problems

From time to time people will ask you to solve a simple problem. One popular example is FizzBuzz(link or variations thereof. You should be able to solve this one easily even if you don’t know it, but if you fear you will get nervous try it at home first.

Try looking into slightly more advanced problems. I tried Interview Cake ( back when it was free and liked it. There are also other sources of questions. If you are looking for a challenge rather that interview prep questions you might want to look elsewhere (Project Euler comes to mind

11. Customize your preparation for the type of interview

If you are meeting with a head hunter you can skip the technical preparation. On the other hand if you know will be grilled by a senior developer and an architect focus on the technical and design side of the equation.

During the interview

During the interview use examples and anecdotes. People love stories and they help to make an impression. Of course you are in an interview so keep them short but if people ask you about your best quality, tell them how this quality manifested itself in your previous work rather than simply saying : “I have great attention to details!”.

For example, when people ask me : “what would your past co-workers say about you?”, instead of replying: “Oh, they would probably say…” I tell of an actual instance where a co-worker complimented me about my work and what led to this. If I can’t recall anything specific I will use a formula along the lines of: “since people often come to me for advice on X I guess they would say Y”. The trick here is to find, if possible, real examples from your work history that fit in with the job in question. Never make up stuff. I could give you reasons like it might make you look bad if you get caught, but the simple fact of the matter is that it’s neither moral nor ethical and that should be reason enough.

After the interview

Reflect on the interview itself. What went great, what could have gone better.

If some example or anecdote you told confused the interviewer or failed to make the point you were trying to make think about how you could reword it. Or maybe just drop it altogether for subsequent interviews.

Sometimes things don’t go smoothly. This has happened to me in the past because I was tired and didn’t have enough energy. If this happens to you don’t blame yourself and don’t worry, this isn’t a reflection of your preparation or your skills and it doesn’t necessarily mean you won’t get the job.


One of the first tips in The Pragmatic Programmer is “Think! Stop and think about your work”. This can be applied everywhere, including here. If you really want to get good fast at interviews you need to put in some focused effort in the process.

Green Ruby

Green Ruby

Green Ruby is a pretty nifty news letter. You can follow it on their web page or subscribe to receive it by email. Receiving emails may sound outdated but I actually like the medium. The fact that it’s one of only two such email I receive makes it stand out from amongst my daily browsing.

It’s a collection of links to sites, podcasts and blogs related to JavaScript, Ruby and general web development. I’m giving them a shout out on my blog because considering how often I find things of interest in Green Ruby, that have a pretty low readership.