Why you should hire someone with Wolfram Mathematica experience

I had explored a lot of programming languages and programming paradigms before I actually knew about Wolfram Mathematica. I actually started out my programming journey with C/C++, then I read Eric S. Raymond's essay and learnt the proper sequence to learn programming in which I outlined with some modifications in my book: How to learn programming.


With every new programming language I explored, I learnt about the motivations of the language designer and how that language fits in the entire software ecosystem.

1. C/C++ for high-performance systems, not very easy to think in.
2. Perl for people that want to efficiently deal with loads of text.
3. Java for official programming at large institutions
4. Python for rapidly prototyping solutions to problems
5. Javascript for everything web, as flexible as python
6. LISP for high dimensional exploration of advanced research ideas

Nowadays we have a lot of frontend/mobile applications and these are powered by tools like Angular, React, etc. But for classical software engineering, you will most likely use one of the above-listed languages.

Every language has a bunch of libraries available for it beyond what is builtin. The builtin stuff is what you need to do your daily programming but when it comes to many specialized tasks you will get in some library written by someone else, import it to your project and then follow the conventions of that library to add functionality to your project.

When preparing for a technical interview, apart from other specialized questions about systems engineering etc. the programming questions requires that you have a well developed technical sense or like I prefer calling it, a well developed mechanical mind.

You will be asked to do things like write sorting routines, or solve some problem that requires you to directly use some of the standard algorithms or data structures of computer science. Being able to do this will up your chances of being hired.

Whenever I learnt a new programming language, I would always go back to Python. The reason I loved Python so much and started thinking about many programming problems in Python alone was that it was so flexible, and allowed you to focus more on the problem and less on the mechanics of getting there.

EFFICIENT CODE vs. NAIVE IMPLEMENTATION

As I got deep into programming I realized that there was this huge gulf between the efficient implementation of a solution to a problem and one that would be easy to understand. After reading a book about programming with all the example code and the toy problems, when you see some real-life codebase, you will be shocked and discouraged from chasing programming further.

Like Eric S. Raymond always emphasised, books won't teach you programming, they will only teach you syntax. To be a real programmer you will have to delve into a real-world codebase as soon as possible after you have learnt the basic syntax of the language.

Another approach is project-oriented learning, but you must remember that if you start a project from scratch after you just learnt a programming language, even though you can research your way to a solution, you must understand that all you will really do is solve the specific problem for which you started the project for and you will learn a lot but your code will be naive and inefficient. To tap into the mind of master programmers you must read through a lot of high-quality code bases. This doesn't mean that project-oriented learning is not useful, but it is a longer path to becoming a master programmer. A better approach to project-oriented learning is to adapt some small high-quality opensource project to your own needs rather than starting a new project from scratch.

The thing many people don't know about programming is that illustrative code, that is code that was designed to teach you something is completely different from real code from some real working codebase. Understanding some real-world codebase is like understanding a new programming language from scratch even though you are well versed in traditional computer programming and the syntax of the particular language.

What recruiters are looking for is someone with a solid mechanical mind, that can reason through a problem efficiently. The assumption is that when this person is in the company working on the company's codebase they will learn very fast because they have been able to excel at vanilla computer science.

The standard algorithms that you learn from beginner computer science are not the best there are. There are some really sophisticated algorithms that will baffle most people who are non-specialists. So the fact that you are well versed in vanilla computer science stuff does not mean you have known all that there is, the really efficient stuff is very hard to master.

So are technical interviews useless? No, they're not. They are useful for filtering the right candidate out of the mass but as useful as they are, they are not very efficient because they discard people who do not spend all their time mastering Quick Sort.

WOLFRAM MATHEMATICA

So what can a programmer who wants to solve some sophisticated problem efficiently do without needing to get a PhD in computer science? There is a tool called Wolfram Mathematica that has been designed by a lot of extremely intelligent PhDs from all fields to help you focus more on the problems you want to solve and less on the mechanics of engineering the primitive algorithms you will need.

What you do with Wolfram Mathematica is actually meta-programming. Because you use a lot of inbuilt powerfully crafted algorithms and data sources to solve problems of any complexity without requiring years of experience in computer science.

So rather than writing a dynamic program to solve a problem like a Knapsack problem, you just use a simple inbuilt function like KnapsackSolve[] and you have one lego brick-like-solution to an aspect of your problem and then you can focus on a larger scale problem you might be faced with like building an application that helps dieters choose the best value items to include in their shopping basket, etc.

The underlying algorithm behind the KnapsackSolve[] is as sophisticated as it can be, if there is new research out on a new more efficient algorithm to solve the Knapsack problem then you can be sure that if it isn't already included in the current version of Wolfram Mathematica, then it will be included in a new release or an update to the current release.

You don't have to track research papers on the Knapsack problem or the Traveling salesman problem. They are there in Wolfram Mathematica, available at your fingertips in just a single function call.

There are about 5000+ of these functions available at your fingertips for solving all kinds of hard computational/algorithmic problems. You can use these sophisticated algorithms as building blocks to solve some higher-level Business or Research problem you might be encountering without having to spend too much of your time worrying about engineering the base algorithms.

What you do when designing algorithms in Wolfram Mathematica is mostly building meta-algorithms that solve high-level business problems by combining inbuilt algorithms like lego-bricks. Very rarely will you need to do anything from scratch, if what you seek is not within the system, then you will find the necessary general-purpose lego bricks to rapidly stitch together an efficient solution to accomplish your goals.

WHY YOU SHOULD HIRE A WOLFRAM MATHEMATICA CODER

Software engineering is about solving real-world problems with Software. As a company, your goal is either adding new features to your product or solving other challenging problems that arise from large volumes of data or optimizing already existing processes.

When you hire a programmer, especially entry-level programmers, you expect them to rapidly understand your software ecosystem so that they can start innovating as soon as possible. Even if you don't have Wolfram Mathematica within your stack, hiring someone who knows how to work with the system is like hiring two programmers, because the programmer is one person and the Wolfram engine is a second person. These two can rapidly come up with solutions to many problems in your ecosystem faster than a single entry-level programmer without Wolfram language experience.

Even if you have no plans to include Wolfram Mathematica in your stack, at least your in house Wolfram Mathematica coder can rapidly prototype a solution to any problems you might be faced with and use that solution as a foundation to solve the problem in your ecosystem using your tools.

Rather than using any of the heavy modern programming languages to do your first prototype you can have someone spin up a solution rapidly in Wolfram Mathematica and using the understanding you have gained, you can now do further research on the appropriate libraries in your regular stack that can solve the problem or before you devote more resources to engineering the solution in your stack.

But if you are forward-thinking enough to include the Wolfram Mathematica Engine in your stack, then you have a powerful backbone for solving and deploying compute-heavy solutions rapidly. Then you can spend more of your engineering resources, improving UI/UX and innovating rather than getting bogged down with finding the right algorithms or the right Senior engineer to build it from scratch.