Codemaze presents a puzzle (“problem”) to user. The puzzle can be solved by doing Steps. Visually it’s a 2-dimensional, traditional maze.

Let’s take a real puzzle I had:

• given a string that represents a number, cut it so that the resulting number in the string shows only the integer (whole number) portion, disregarding decimal numbers
• example: “1.7019” => “1”
• example: “1” stays the same “1”

An algorithm: divide and conquer!

A good Programmer might think here that the degenerate case is first. So let’s handle a “non-case”: if the function is passed a empty string ”, then return the empty return; we’re done in degenerate case. Let’s move on in the algorithm: Does the string have a comma?

So, pseudocode here:

• IF string DOES NOT have a comma, means the number is already the correct answer; then just return the number as-is.
• IF string HAS comma, return the part of the string Left of comma.

This is whole our algorithm. It is based on a simple divide-and-conquer strategy; we were able to split the whole problem into 2 distinct cases: a) an Input string without comma and 2) string with comma.

We’d have a few primitives and functions available.

• findCharInString
• giveLeftOfCharInString
• giveRightOfCharInString
• giveFirst_N_CharsOfString
• giveLast_N_CharsOfString

Each step taken solves part of the puzzle.

Now this is quite simple construct so far. Where the original idea for Codemaze came when I thought of ways to test software developer’s skills with a few particular (perhaps) novel twists:

• no code would have to be done by developer, in order to solve the maze
• the test would be equivalent as possible to estimating real world programming aptitude
• the test would be a reliable estimator of general problem solving capabilities of the testee, without a weight on a particular environment, stack or programming language
• if you choose a wrong step at particular time, game is not “lost”
• the test can also be made to measure persistence (grit) in addition to purely acute clarity of understanding a given puzzle
• wrong steps however penalize your score

Real life software development has a few founding cornerstones. Some aspects hinder perhaps the ability of a developer to keep advancing in true sense of solving a business problem. For example, apart from human-to-human interruptions, there’s other kind of “external” interruptions from the fabric of the software project:

• outdated dependencies
• inability of the programmer to recall precise names and other literal, unforgiving data (often remedied with aid of the IDE = editor, or with time)
• hardware limitations or disk space running out (seldom)

The act of programming itself is sustained by things such as

• salary
• ambitions
• social significance and meaning of the software and your workplace
• joy in making the fulfillment of a desired product
• learning new techniques and paradigms
• co-operating with team members
• having fun!

Technically speaking almost everything is possible to do with software, given enough time. So there are boundless possibilities to be creative. Business and the nature of clientele ultimately decides what developers get to work on, day in – day out.

Where developers actually stumble and fall is:

• lack of initial patterns of advancing towards the goal.
• sometimes there’s a really hard problem, which stalls development for a while
• code may have become disorganized during the haze of development, and is difficult to mentally grasp (maintainability is low)
• bugs riddle some of the functionality and developers start to pay attention to these instead of doing forward functionality
• lack of proper coordination between teams’ participants results in waste and overlap of development work, leading to throwing away and the need to integrate code together

But on a individual level we’re talking about only a handful of things that developers need to consider.

• knowledge of available keywords (commands)
• syntax of the language
• logical ordering of commands in order to solve a problem
• matching inputs and outputs of a function
• understanding what a particular function does
• knowing the limits of a function
• call signature of a function and providing it with proper variables
• preparing upstream data to match that of a function call
• deciding the nature of whether to keep data in sort of temporary throw-away registers or use global space
• thus, developer needs to answer a question of which tool is proper for solving a particular problem in given point of time

The user is presented at each round of the maze 3 choices:

• one choice is the ‘correct‘ one
• the other choice is ‘wrong‘
• a neutral choice

Presentation sequence is the linear array, sized 2 * Len (Len = length of correct solution)

Algorithm for making a presentation sequence

• correctSol.length is the amount of steps required for solution
• correctSol[] is a sorted (in correct order) array of steps
• we will build a presentable steps array by inserting 50% wrong steps
• build a presenSteps array by:
  ps=[]
  L=correctSol.length
  w=generateWrongs(L)
  i=0 // loop counter
  while (i<L)
  pair = {r: correctSol[i], w: w[i]}
  // let’s push the JSON pair into ps array
  ps.push(pair)
  i++
  end

User is always presented 3 choices. He must choose one to progress.
He can also click ‘yield’ to stop doing the puzzle and let the
engine calculate score.