At Intersec we love hiring new talents, especially new C developers who can reinforce our teams. And of course the candidates have to face a technical challenge so that we can assess their technical skills. This is a typical step in the recruitment process that can become very time consuming for the reviewers and stressful for the candidates. Pimp My Recruitment is an initiative to help automatize this whole process, both for the candidate and the reviewer.

Showing new features on a demo platform painlessly Today’s method Currently, when we want to show the upcoming version of a product or new features for a demo, if these features are not already fully available on the code repository, and so existing in a packaged version of the product, it’s a bit painful. We have to create a dedicated demo platform, by compiling the specific product locally, building packages and installing them manually on a dedicated Virtual Machine.

Maintaining old software on new OS Like many other companies, we need to maintain our software for a long period of time. Usually, a version lasts several years (we have had some versions in production for more than 10 years now). While we update our coding environment for new versions, we still need to be able to build and debug those older branches. This can become a problem when our new default system introduces a new tool version (e.

In the virtual world, hardware may feel abstract, nonetheless software still depends on physical infrastructure consuming resources where waste can take place. Let’s look at datacenters, where the physical location is based on the price of electricity, then you have to keep them cool, placing data center underwater is one solution being explored. There is also the high energy consumption of crypto mining but let’s focus on a simpler example, that app on your phone that consumes a lot of battery or memory with no apparent reason which ends up being removed by the annoyed user.

At Intersec we aim to provide the best user experience in our geo-oriented applications, where users need to understand a live situation at a glance and make the best decisions, based on accurate map data. The way to achieve this goal often relies on providing just the right amount of contextual information and actions, keeping everything as simple as possible. Users of Intersec products need to understand the geographic context:

The WordPress years This blog was originally hosted using WordPress, the famous CMS. It was quite an active site at the beginning, with a post every 2 months on average. But then, the contribution rate dropped, and the blog began to be only used to relate the results of our yearly hackathon. As the site was a bit deserted, we forgot to update it, which is quite a fatal mistake when dealing with a WordPress site…

On the 23rd and 24th of January, an internal hackathon took place at Intersec. Our team “Laws of the Universe” took part in this hackathon, with the ambition of “testing” kepler.gl, an open-source solution of geodata viz and analysis. More precisely, what we meant by “test” was a twofold objective: See if we could build nice viz based on the type of data commonly processed by our solutions Ideally, integrate them directly in our products, to demonstrate the feasibility of an industrialized solution based on this technology To be honest, before the hackathon, our knowledge of kepler.

Objective In our products, we use a home-made technology called QRRD (for Quick Round Robin Database) to store monitoring metrics (system CPU/memory monitoring, incoming event flows, …). QRRD (which is written in C) was actively developed between 2009 and 2013, but we have not been investing in it since, so it has not evolved anymore. And even if this is a really great technology (especially in terms of scaling and performances), it has the following drawbacks:

At Intersec, we aim at maintaining a consistent style throughout all the code, depending on the programming language. For example, the C codebase is the most consistent, with our coding rules being enforced on code review. This enforcement, however, can lead to significant time loss and frustrations when patches must be repushed to be adapted to specific rules. In the past, there has been several attempts at configuring auto-formatting tools. They were never fully satisfactory because several of our coding rules did not fit into the limited configuration options of these tools.

The goal was to develop benchmarks on a few of our core technologies in lib-common, in order to: Be able to compare the performances of our custom implementations with standard implementations. Be able to add automated tests on performance (e.g. adding non-regression tests to ensure that changes which seem to be harmless do not worsen performance). Benchmark library The first step was to develop a benchmark library; the success criteria we established were the following (compared to the already existing benchmarks in our code base):