Programming a chatbot may seem to be the preserve of an elite group of professionals, confined to technical support. And yet,“conversational agents“, as the boring people say, are proving surprisingly effective in areas where they are least expected. And with good reason: while intelligent chatbots are gradually beginning to replace us in many tasks, some people seem reluctant to see them take the place of so-called relationship professions.

A process already in action

First of all, it might be naive to think that chatbots are mainly used by after-sales service providers. In mobile telephony with Orange, internet provider with Free (Eva), digital platform with OVH. Many companies selling products are opting for an initial after-sales service with chatbot. Why? Simply to save time. But can we classify these chatbots as intelligent? Not really, but it was just the beginning of what could be described as a revolution to come. Conversational agents are set to revolutionize marketing. That’s all there is to it.

While this may sound scary, there’s no need to worry about a simple after-sales chatbot. The more time passes, the more chatbots will no longer be defined by users as such. Does confusing AIs with humans at the conversational level sound familiar? The Turing test is exactly that. An AI is considered to have passed the Turing test when a human is unable to determine whether it is an AI or a human behind the keyboard. HAL 9000 you said?

Let’s get back to marketing, shall we? The first sign of corporate interest in chatbots, which follows the trend of the AI craze, is evolution. While after-sales chatbots have been around for a while, the last two years have seen the “massive” appearance of pre-sales chatbots, which operate before the customer buys. Once again, e-commerce sites regularly feature a chatbox, usually with a name. By extension, many start-ups and large companies are turning to chatbots. The latest craze is the smartphone.

Let me explain: have you ever noticed how many banks or of insurance company with a beautiful logo derived from the image of a message. Hello Bank by BNP, Fortuneo, Alan etc… All its companies have moved away from Customer / Sales to Customer / Chatbot / Supervisor exchanges. Initially, the user exchanges with the AI, and if a question is not understood, the supervisor takes over. Why? It saves an enormous amount of time, and paradoxically, you feel closer to the person you’re talking to through the application. In fact, where we imagine the banker as an adversary, we tend to place the personified chatbot as an ally.

And now it’s a real marketing argument. Now let’s see what can be done.

What professions are affected by chatbots?

“Concerned”, not “replaced”. There’s no need to think of bots, or even AI or robots, as entities that have come to take away your jobs. There will always be a need for a supervisor. And why not imagine a collaboration?

Imagine you’re in charge of recruiting for a position in a start-up company. Why not subject candidates to a preliminary interview with a chatbot? You’re a fashion blogger and your community is asking you questions. the same questions via your Facebook. Why not create a Messenger bot to answer recurring questions, all with your personality in the answers. These cases are already possible, and even rather easy to access. Like many companies, they help you stand out from the crowd and give your company a modern image. Soon it will be practically mandatory. Why not be one of the pioneers? It’s already possible to create your own Messenger bot pretty quickly, without necessarily being a super-good developer.

Last but not least, chatbots are likely to take over the leisure industry. Netflix proposals, for example? Twitch moderation? Pure conversation with Discord and its bots?

These indications are general and each case must be treated individually. If the subject interests you, you can contact us to discuss what would best suit your project and needs. As for me, I’ll see you next time, and hope to see you on this site!

Hello you,

Whether you’re a CTO, a project manager or just in charge of recruiting developers for your tech team, you’re often faced with this question:

How can you quickly determine whether a developer is a good fit for your team?

After working as a trainer for Octo Technology, CTO for the startup Modalova and finally CEO of my own agency KNR Paris, I’ve had the opportunity to interview a large number of developers from all backgrounds. Some were graduates of prestigious schools, others self-taught; some were young, others older; men and women.

Over the course of these interviews, I came to realize that some candidates with “perfect” CVs didn’t actually know how to code; they had some knowledge of the subject, but I didn’t see them as real developers. So I set up a “roadmap” for conducting my technical interviews, a checklist of things I needed to check during the interview before considering integrating a profile into my team.

This roadmap enables me to eliminate on average 80% of candidates who, despite having a very good CV on paper, don’t have the necessary skills to join my teams.

But Gabriel,” you might ask, “how is your roadmap going to help me conduct MY own interviews? Maybe I don’t have the same expectations of my developers as you do!”

Well, reader, you’re absolutely right. That’s why in this article I’m only going to talk about the technical aspects that enable me to separate the good developers from the not-so-good (not to say bad) ones. Developers, who for me are not yet developers. Developers who, in my opinion, won’t be able to produce quality code that can be used in production without the supervision of another, more experienced developer. Let’s just say that developers, whom I consider to be “less good”, will find it difficult to be autonomous, to make proposals and to produce bug-free code.

Ok, let’s get into it!

The famous Fizzbuzz test

The Fizzbuzz test is a relatively well-known test for developers. Simply knowing that this test exists is proof of a certain level of computer literacy; but not knowing about it isn’t necessarily prohibitive. For example: I didn’t know him when I joined Octo Technology.

The statement of the Fizzbuzz test is quite simple: the developer is asked to write a code (I usually leave the choice of language to the candidate) to solve the following problem:

Let’s take a list of numbers; let’s keep it simple, let’s take positive integers between 1 and 1000 (here we’ll keep it simple so that the candidate doesn’t waste time thinking about the type of variable to use if he decides to take the test with a strongly typed language, such as C).
For each number n in the list, we want to perform the following operations:

• if the number is divisible by 3: Fizz is displayed
• if the number is divisible by 5: Buzz is displayed
• if the number is divisible by 3 and 5: Fizzbuzz is displayed (hence the name of the test)
• otherwise: the number
  n
  

And that’s all there is to it; the test looks simple enough, and indeed it is. But I found (to my horror) that around 70% of the candidates I interviewed were unable to pass this simple test. Some were even in engineering school, practically graduated, with 5 years of “web development” on their CVs; but couldn’t pass this simple test. It makes you wonder what they learn at school…

The first step is to see if they can pass the test. A good developer should be able to produce drinkable code in 5 or even 10 minutes, may encounter a bug when testing his code with the number 15 (divisible by 3 and 5), but should find the solution in less than 5 minutes.

Now, if the person doesn’t pass the test, they’re disqualified as far as I’m concerned. I think this kind of problem should be child’s play for a developer who offers to develop for you, carry out your project or join your tech team. Admittedly, the stress of the interview can also work to the candidate’s disadvantage, causing them to lose their nerve: that’s why it’s important to reassure them: this test is simple, there are no traps, the aim of the game is to keep things as simple as possible. Under these conditions, if your candidate needs 30 minutes to come up with an acceptable code, it’s NOGO for me.

function fizzbuzz($liste) {
  foreach($liste as $n) {
    if($n%3 == 0 && $n%5 == 0) echo 'fizzbuzz';
    elseif($n%3 == 0) echo 'fizz';
    elseif($n%5 == 0) echo 'buzz';
    else echo $n;
    echo "\n";
  }
}
fizzbuzz([1, 2, 3, 4, 5, 7, 15, 20]);

Now you have my attention

OK! Congratulations, your dev has passed the Fizzbuzz test, so he knows how to program.

The idea now is to try and estimate its sensitivity to the beauty of clean, uncluttered code that respects the rules of single-responsibility.
To put it simply, in the code example proposed above, all the logic in our code was in the fizzbuzz function. Now, in computing, we like to cut up a program so that each piece of code has a unique role (the principle of single-responsibility). As you explain this principle to your developer, ask him if he can see a way to improve his code to make it more readable, while respecting this principle.

Here, we try to see how the developer responds when asked to “improve” his code.
Many developers will confuse code improvement with code optimization. When we talk about optimization, we’re talking about increasing the performance of a code; for example, making it faster and less resource-hungry. It’s all very well knowing how to optimize code, but I think that with the machines we have today, saving a few milliseconds on the execution of a simple program is less important than it used to be.

But I digress! So we ask our developer to improve his code. By improve, I mean make it more beautiful, more readable, more Charlie-able, more likely to be taken over by another developer without them thinking WTF when they read the lines of code, easier to debug and above all easier to modify. That’s what I call good code, beautiful code.

So ask your developer to improve his code; if he starts talking about optimization to make the algorithm faster, just tell him that’s not what he’s being asked to do; we’re just looking to make the code more beautiful.

Here, I generally expect the candidate to output the logical part of the code used to determine whether a number X is divisible by a number Y. This would make the code more DRY ( Don’t Repeat Yourself ) ; and also improve its readability. We’ll also pay attention to how it names its variables and functions. Code with variables named a, b, c, x, y is synonymous with a developer who has never really worked in a team.

function est_divisible($nombre, $diviseur) {
  return (0 === $nombre % $diviseur);
}

Read between the lines (of code)

And there you have it, the few lines of code that allow a developer to prove to me that he can actually code. But is that enough to set them apart from the other candidates? Well, no…

A good developer is also (and above all) a developer who masters his tool.

I usually ask candidates to bring their computer to the interview, so that they can use the tool they should be comfortable with. During the fizzbuzz test, I’m going to observe how they use the said tool; use of an IDE, use of keyboard shortcuts; do they use their mouse/touchpad too often ( spoiler alert: this is a bad sign ); do they type quickly on the keyboard, with two hands; using several fingers. In principle, this gives me a fairly general idea of the candidate’s ease of use of the tool, which often goes hand in hand with his or her skill level.

So that’s it; am I hired?

Not yet, young padawan. This article deals only with the technical side of interviewing. I’ve already turned down candidates who had passed the Fizzbuzz test with flying colors. See you in a future article where I’ll explain how we recruit at KNR and why technical skills alone are not enough to make a good candidate.

Don’t forget to subscribe to our newsletter to be notified when the article is released!

Are you a CTO, project manager or even a developer looking for a job? Tell me what you thought of my roadmap in the comments below!