Interviewers: stop the puzzle games !

I was active in looking for a job in a software company in the past three months (although I also did some contract work), and I failed at a puzzle game test because « I was too slow to answer the questions ».

Here are a some of the questions I was asked to do:

You are given a string variable $str.
Write PHP code to print the given string with every third letter removed.
For example, if input string is « Apple iPhone », the output should be « ApleiPon ».

 

Array $a contains integer numbers. Write PHP code to print an index of an element that contains the maximum value among array values that are even numbers (can be divided evenly by 2).

 

The questions and quizzes I’m going to talk about are the ‘basic’ quizzes, where your task is very near to algorithmic: eg write a function that sorts an array,
write a function that finds an integer inside an array, etc

tl;dr

They are many reasons for which I think this kind of questions do not make sense to choose between candidates.

  1. Some people will cheat
  2. It doesn’t show how you organize your code
  3. It doesn’t show how you work with others

Some people will cheat

In the book « The honest truth about dishonesty » by Dan Ariely, he explains that the most effect of cheating doesn’t come from big cheaters but rather from many cheaters.
In other words, they are not a few people who are tempted to put lots of effort to cheat.
However, they are many people who would put some effort to increase their score artificialy.
For example that could be done by using one or many of the following tricks (ordered from the difficult to the easiest):

  • If the test doesn’t require you to login, you could do the test twice, the first time providing information false information. This way, you can prepare
    yourself to the questions that are asked and achieve a score that is higher than what you could do normally
  • If you have unlimited time for the test (eg have one week to complete it), than you could very easily ask the help of a friend or even ask you question on
    a forum to make you smarter.

It doesn’t show how you organize your code

One of the biggest problem with quiz like problems is that you don’t encounter them in real life. You already have functions that can sort arrays in most of the
languages, or you could easily find a library that takes care of this for you.

The real difficulty in a codebase is not how to sort an array, or if that is the case your programmers are probably not that good. The real difficulty in a
codebase is how to organize your code.

I would also like to talk about a very positive experience when looking for a job : it was the test of the Financial Times Lab. They ask you a set of questions
which are « Stackoverflows » style of question, eg they ask you what’s the difference between

helloWorld()
function helloWorld() {
console.log(1);
}

and

helloWorld()
var helloWorld=function () {
console.log(1);
}

and why they give different results.

It doesn’t show how you work with others

Working with others is a huge part of what a programmer does. To achieve a task, some work must be done. But what takes most effort is the communication between
members of the team. If the communication doesn’t work well, your project isn’t going to meet it’s deadline.

Work in progress

Your support tickets are just the tip of the iceberg

Iceberg
The tip of the iceberg

If you run a product and have some kind of support system, you’re for sure, depending on the number of customers, managing a few support tickets per month. You might think « why are my users so stupid ? » , but this is not even the tip of the iceberg. Think about it from the user perspective. How many times are you annoyed by something a day ? Probably somewhere between five and ten times a day. And how often do you take the time to share your problem to the app’s creator? Probably once a day of you’re quite a world improver.

They are so many broken things that most of what is broken will not reach to you because other things are much more annoying.

By removing the most painful problems first, you will be able to get some feedback from the less urgent things.

Vim serving as a model for keyboard-based software

vim is a good example (if not the best) of a keyboard based application. Vim being alive and still maintained during more than 20 years (40 if you count its predecessor ex with its visual mode vi), it shows that such an application is robust and doesn’t get caught up by the new sleeky editors.

Vim’s powerfulness is due to its inner coherence. The letter `d` always has the signification: delete. The letter `w` means a word, so `dw` means delete the next work. `$` means the end of the line, so `d$` means delete to the end of the line. An abbreviation for `x$` where x could be any character is `X`. So `D` will delete all characters to the end of the line. In the same way `C` (change) will delete all characters to the end of the line and put you in insert mode (The mode that lets you use Vim like any other editor).

I’m trying to do the same with my own software. `j` and `k` are used to go up and down a list. What is very great about keyboard shortcuts is the following:

* They never take space on screen, delivering you the best experience
* They will go into your muscle memory, and you won’t need to look at the keyboard to go the next item in the list (just press the key with the little mark on it :-) )
* They make it possible to add functionality without loosing clarity: you don’t need to learn the keyboard shortcuts, but if you want to go one level up, you can.

Features : Value vs Cost

When you create a product, you’re probably discussing a lot about features. Here are a few possible questions :

Where should we put that button ?

Who should get access to that feature ?

How should we introduce that new feature (blog post, tutorials, …) ?

How should we implement that feature ?

There are probably much more questions you can ask yourself when you think you’re going to implement a feature.

However, one question that is essential and often not asked is the following one :

Should we add this new feature at all?

I think most of  the time, the answer should be No.

This is because how costly features are. I have tried to set up a few questions that you can ask yourself the next time you’re thinking about a new feature, to help you balance the value/costs of a feature.

Value

  • Will your customers use that feature often, or is it very useful even if it is not used very often ?
  • Does your software sell better if the feature is present ?
  • Will the feature benefit to many customers ?
  • Are you the only one to provide that value ?

Costs

  • How long will it take for you to develop that feature ?
  • Are there bugs in your software that you will take longer to fix because you will be busy working on the new feature ?
  • Are there pending support tickets that will still be pending because of the new feature development ?
  • Will the feature you’re building increase complexity ?
  • Is it easy to drop that feature if it doesn’t fit to the customers needs ?
  • What will be the cost of maintaining that feature ?
  • Is the new feature likely to add a security leak ?

Hope that helps !

 

You don’t need to be scalable from day 1

I see so many developers asking themselves the following question :

How should I write my code so that it will work if the traffic explodes ?

I believe thinking about this from day 1 is counterproductive. Here’s why :

Most of the time, you aren’t going to scale

Yes, that’s a truth, 99% of the projects will never have to scale. Some of the projects will die, others will just reach a certain amount of users and stay stable from there. Thinking you are part of those few organizations that will scale is an illusion. Furthermore, most of the time, you’ll see when you project is starting to get more traffic. When you know this, you will be able to adjust the size of your team. It is faster than ever to change the size of your team.

The overall speed of your growth is defined by the limiting factor

I went to a generalist engineering school, so I’ve done a bit of chemistry too, and here’s what I learned from that :

If one crop nutrient is missing or deficient, plant growth will be poor, even if the other elements are abundant.

Liebigs Law

Applied to start ups, this means that you can’t scale your business if you just make your application technically scalable. There’s customer acquisition that is very often a limiting factor, but also other bad conversion rates between the acquisition and the revenue.

They are some cases when your app’s design is the limiting factor of your growth, but in this case, you probably know it yourself (because your app is slow, customers give bad feedback , …).

Support is one of your main marketing channel

At beequick, our top priority is answering to support tickets/incoming mail. When a customer asks us something, we try out best to answer in the following hours. However this is not the case everywhere.

The current state of support

I have seen many companies where the employees would say:

This is Tom’s problem, he has some holiday, so I won’t answer that ticket.

And the ticket stays unanswered for a week or more. What a nonsense !

An other problem appears when separating the support team from the development team. Rule number 5 of Six simple Rules states:

5. Extend the shadow of the Future

What does that mean ? It is about responsibility.

If the people who build your stuff are not as well responsible for the support, your developers will not care if the product gets better. If your developers are not responsible for support, the customer feedback loop is broken. This feedback loop ensures that requests of your customers are getting implemented in your product. The customer feedback loop is one of the most important feedback loop in business, especially in the start up environment.

Put your customer’s requests first in line

I don’t have data to prove it, but from experience, I have always felt that customers who get quick answers are more loyal than others. Often a first support ticket that was answered quickly can trigger a purchase from the customer. For example, that’s what triggered the buy process when I first got a response from the support guys at fortrabbit.

It makes your product more valuable

A reason I’m never going to buy again from DELL is their poor support. 2 years ago, I booked a computer on their site, but I never received it. I had to speak hours over the phone with different persons who would never listen to me. They had standard problems they were able to solve, but anything outside of the standard was too complicated for them. I finally got my cash back but without any hassle.

When on the contrary, the support you get is personal, friendly and fast, you appreciate the product even more. It humanizes the product.

Having great support at the beginning doesn’t cost much

At the launch of your product/startup, you should try to do as much support as possible. Don’t try to hide the support button or make « premium paid support ». Support will bring you a lot of:

  • Valuable feedback from real customers : what do they like/dislike, where do they have difficulty to understand your product, what is important to them and what doesn’t matter
  • Trust : when trying a new product that just launched, you just don’t know if the product will still exists 6 month from now. Having spoken with someone about the product will at least give your customers more confidence.

Don’t eliminate support when you become bigger

When companies get bigger, they try to reduce their support budget. The reason for this is the scale argument : we are currently scaling our business, so we’re reducing costs. However, if you’re in the service business (almost everyone nowadays) , support is still one of the core component of your value. If you don’t continue to have nice support, your company will lose in trust, and thus in revenue.

Here’s a great article form Signal vs Noise about why they put everyone at their company on support.

Why docxtemplater is so awesome to generate docx files

I’m creating a library on Github, which is obviously open-source. The library creates docx from a template with data, much like what you’re used to do for HTML with templating languages like Mustache, Twig (for PHP), HAML (Ruby and Node), Jade (Node). The library is called docxtemplater and is specifically for docx. Docx is a format used by Microsoft Word 2007+. The library was named docxgenjs at the beginning. But I’m opinionated and only want to generate docx from templates. So I have decided to rename the library to docxtemplater. I have also removed the JS suffix. In fact, the library is not deeply linked to javascript as there is a command line interface (CLI). The CLI makes it possible to use the library from any language.

They are two main differences between HTML and Docx. This differences make it difficult to use one of the mainstream templating languages for docx:

  1. Docx is a zipped format, so if you want a solution that works out of the box, you should at least add a way to unzip and then rezip the document. You will also have to write the logic to modify the right files.
  2. Docx is made of xml, and the text is splitted around in the document. For example writing « {tag} » in a word document often results in the following code structure in XML:


<w:t>{</w:t>...<w:t>tag</w:t>...<w:t>}</w:t>

This makes it almost impossible to use a « normal » implementation of a templating language.

The library can process variables, but also loops, conditions, custom parsing of variables (with the angular syntax), and replace images.

Why narrowing to a docx templating system ?

I have a big problem with all other libraries that try to solve similar problems: They all involve that you should write all the document’s content in your application code. This seems very inefficient to me. Why the heck should I write static paragraphs inside my code base ? It has been a long time now that the whole software industry agrees that it’s better to use templates to generate HTML rather than echo out stuff in your application. However, this specific problem seems to have been developed with old standards. Yes maybe, you might want to get some super power and insert a very complex thing in your document (eg something that is not some text nor some image). But even if you want that, I created a syntax that allows you to insert some custom XML: {@tag}. If you want to insert an XML tag that is not possible to generate using normal tags, use the XML Tag. But please, avoid making the same mistakes again, eg don’t put all your static content in your codebase, that’s exactly what templates are for !

Even better, if you use templates, you will find it much easier to switch from one output type to an other, because all of the output types will share the data (but obviously not the template).

There’s still one bonus using the templates: Everyone can edit Word templates, but only a developer can change code that echoes out part of the docx. So using docxtemplater rather than an other library will let you as a developer do the data-binding, and your manager/whoever can create the docx template.

What’s wrong about the 40 hour work-week ?

While I’m still pretty young, I think I have a word to say about the way we work together as of 2014. Of course not everyone works like I’m writing in this post, and this may be a bit too opinionated because I very often have thoughts about how bad this is. I have already worked at 5 different companies as an employee, done some contract work twice and am currently one of the three co founders of an other company called beequick. beequick has one main product : a CRM specialized for Junior-entreprises. We have been working on this company totally remotely since more than a year now, and everything is working fine. I think I work between 4 and 10 hours a week for beequick.

You can’t be productive for 40 hours in a week

Yes, I truly believe that. They are mainly two problems with the 40 hour work week: The first being the interruptions: If you work at a company where people come and go to ask questions (which is usually the case), you probably rarely get 1 hour of time where you are fully concentrated. Interruptions are exactly what makes your day inproductive:

It separates your work day into work moments.

37 Signals

Yes, you hear all the time that whenever you get interrupted, you need 15 minutes to re-concentrate. I think you probably can’t even come back exactly at the same state as you were before the interruption, and if you’re able to do that, it probably requires a lot of (unnecessary) effort. The second being that companies don’t care about productivity. What they care about is how much you work.

Do you work 40 hours a week or more ? Yes ? Then fine, continue like this.  // I don’t care about your speed

A random company

Projects, blog posts, reports, take months to be done while they could be done in weeks or even days.

The way productivity happens has changed

While it might be a good idea to measure productivity with the time you put in it if you work in a factory, this is especially not true in the software companies. Programming, designing, and all of the modern jobs are not physical jobs. Everything employees do is taking decisions. Unlike physical jobs, it’s not how much time in a day you work on a problem that will output most of the good decisions. It is more about how good you know the problem, what your past experiences were, etc…  There’s also a huge factor that comes in : you need to take care of your mental health : reading a lot helps, talking with people from different horizons, eating healthy food and also doing regularly physical activity.

Employee happiness matters (more than ever ?)

40 years ago, people had to leave their hometown to find somewhere to work. Now we have all that countless stuff that permits us to collaborate despite of the distance: Trello, Basecamp, Hipchat, … we shouldn’t have to care that much about working all on the same place, on the same hours. More and more people (especially the ones that care about productivity) don’t want to be constrained by rules that make it impossible for them to have a fulfilled life, like being far from their family, from their friends or their favorite activities.

Try to hire remotely and stop to force your employees to work for a specific time.

 

La librairie jQuery: Principe, Utilisation et liens

 

Petite histoire du JavaScript

Javascript existe depuis bien longtemps, puisque en septembre 1995, le navigateur Nestcape Navigator 2.0 sort, et avec lui la première implémentation du Javascript qui porte à ce moment le joli nom de LiveScript. Ce nom a changé dans les versions suivantes.

Microsoft à l’epoque était un des grands précurseurs dans le domaine du web, et créa Internet Explorer 3.0 en 1996, qui supportait le Javascript. Cependant, le Javascript a toujours été un langage interprété différemment selon les navigateurs. Ceci a posé beaucoup de problèmes au développeurs pour qui le Javascript n’était pas un langage particulièrement mur et intéressant.

Inventer un nouveau langage pour remplacer le Javascript n’était pas concevable pour éviter de pénaliser une grande partie des utilisateurs qui ne mettent pas à jour leur navigateur fréquemment. C’est dans une optique de simplification du Javascript (et d’accessibilité pour les développeurs) que jQuery a vue le jour

Naissance de jQuery

Il faut savoir qu’il existe plusieurs langages qui ont été créés pour améliorer l’utilisation du Javascript, comme par exemple jQuery, Dojo, Backbone , Coffeescript, jQuery UI, EmberJS.

jQuery est devenu un des incontournables, puisqu’il permet de simplifier largement l’utilisation du Java-script: L’idée du créateur de jQuery est très simple: sélectionner un élément avec javascript est assez compliqué nativement:

En effet pour obtenir tous les éléments qui ont le tag html h1 par exemple, il faut utiliser le code suivant:

var h1_array = document.getElementsByTag('h1');

var h1_class_array = [];
for (var i=0, len=h1_array.length; i < len; i++) {
if (h1_array[i].className.indexOf(‘classname’) !== -1) {
h1_class_array.push(h1_array[i]);
}
}

En jQuery, l’operation est bien plus simple:

h1_object=$.("h1")

L’idée est d’utilisée les mêmes sélecteurs que ceux utilisés en CSS, pour ne pas avoir à apprendre un nouveau langage de sélecteur. C’est pourquoi jQuery a eu un tel succès:

Voici des graphiques montrant la répartition des sites qui utilisent jQuery:
Statistiques jQuery

Les gros sites (classés dans les top 10k) utilisent en majorité jQuery, les sites de plus grande ampleur ayant souvent peur de dépendre d’autres librairies, ou ont créés leur propre librairie. Cependant, jQuery reste un incontournable en terme de développement web, et je pense qu’il faut au moins réfléchir à cette possibilité lors de la création d’un site internet.

Exemples

Dans cette partie, je vais vous montrer quelques exemples de code permettant de faire certaines opérations rapidemment: 

Changer la couleur d’un élément

Exécuter$(this).css("color","red");

Ajouter un élément à une liste

  • Banane
  • Pêche
  • Framboise
Exécuter$("ul.ex2").append("<li>Myrtille</li>");

On utilise le sélecteur ul.ex2 qui signifie de choisir les éléments ul qui ont la classe ex2

Effectuer une action pour chaque élément




Résultat:
Exécuter$("div.ex3 input").each(function(){$("div.ex3").append("<b>"+$(this).val()+"</b><br>")});

Utiliser jQuery

Pour utiliser jQuery, c’est très facile, il suffit d’utiliser une simple balise script dans le code HTML de sa page. Une bonne pratique est de la placer juste avant la balise <body> pour éviter les temps de latence du à l’attente du chargement du javascript.

Il est possible d’utiliser une version de jQuery hostée par google. Cela offre les avantages suivants:

  • pas de téléchargement de la librairie pour chaque site qui utilise la librairie, puisque les utilisateurs auront très souvent cette librairie dans le cache de leur navigateur
  • pas de bande passante utilisée supplémentaire pour la librairie

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

Site du Javascript ninja

Bonjour,

Je m’appelle Edgar HIPP, créateur du site http://www.javascript-ninja.fr. Mon but est de montrer l’importance de l’ergonomie dans les sites internet, ainsi que de la bonne utilisation des langages de type client (c’est à dire qui s’exécutent sur le navigateur de chaque ordinateur). Je parlerai donc d’utilisabilité des sites internet en général, mais également des technologies intéressantes qui existent dans tout ce qui concerne le développement front-end des applications web.