Random Musings on Technology

On Pointers and Software Developer Candidates

 • 

Recently read a good article by Joel Spolsky. The Guerrilla Guide to Interviewing v3.

This paragraph brought me some chuckles first, and later some sadness:

I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude. In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol’ time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good looking members of the appropriate sex in their CompSci classes, that’s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirected thinking that some people just can’t do, and it’s pretty crucial to good programming. A lot of the “script jocks” who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.

Unfortunately, more and more Software Developer candidates are becoming "copy pasters" and do not have the skills to understand what they are doing, understand what is happening.

A Patch for AoE II HD on Linux

 • 

So apparently there is a wine bug that has been open for more than 7 years affecting Age Of Empires II HD. The game keeps scrolling the screen when inside a battle.

Fortunately someone found the specific bytes that can be changed as a workaround for the bug. I am saving the workaround here in case it is lost at some point:

Original link: https://steamcommunity.com/app/221380/discussions/2/622954302095447538/#c154645539343670235

Quote:

Ive been having this issue under wine as well, and finally got annoyed enough to look into it. I have an explanation and fix which seem to have fixed the issue for me so far.

The game is using the GetKeyboardState() function to read the arrow keys (and other keys), and is not checking the result correctly. The MSDN documentation for the function only defines the low bit (0x01, meaning that the key is "toggled" à la Caps Lock) and the high bit (0x80, meaning that the key is pressed). Age of Empires (both 1 and 2) check if the key is pressed by checking if the result is > 1. This works most of the time, as it does not depend on the low bit. However, the undefined "middle" bits are occasionally used by windows/wine internals, and are not guaranteed to be zero. The game should check only the high bit (by ANDing it with 0x80).

I've patched version 5.0 to do this for the arrow keys (replace 80 3C 01 01 at offset 0x4525D4 with 80 24 01 80 and 0F 97 C0 at 0x4525DB with 0F 95 C0 in AoK HD.exe). Note that this doesn't fix the issue across the board — the Tech Tree screen also uses GetKeyboardState() and checks the result in the same way. It'll also need redoing for each version until it's fixed properly by the developers.

I only had to do the first replacement for it to work :); this using any hex editor (like Bless). Afterwards, I can enjoy AoE II HD on Linux.

Evaluating for a Project Manager

 • 

I was asked to describe how to evaluate a Software Project Manager. I remembered this nice challenge I did at some point, and realized that had to dig in memory a lot (and ask someone who actually had taken the challenge). For that reason I decided to write about it here.

At some point in the past I have had to hire a Software Project Manager for a startup. We were looking for someone who had great Project management skills, but that also understood the Engineers.

As part of the evaluation process I did an "onsite challenge", which took around 3 hours. For this challenge the candidate had to define a plan (in the form of a type of Gantt Chart) for executing a Software development project, given a set of constraints (in time, resources, and scope of course).

The Challenge

The objective of the challenge was to test how the candidate handled the definition of a real-life project, with its constraints. The constraints came in the form of insufficient resources and time, for the scope

The candidate was recommended to ask questions to the interviewer, who played the roles of a) The Engineering team and b) The Product Team. The points to evaluate were:

  1. How well the candidate interacted with the Engineers and Product "teams" to ask them questions, clarification, etc.
  2. How much "domain knowledge" did the candidate have allowing him to make sound decisions when making compromises.
  3. How did he handled the scope/resources duality and what solutions did he came up with to address them.

Scope

To define the scope of the project, we provided the candidate with a list of stories needed to develop a mobile App. This list was comprised of Frontend stories (to implement standard UI HTML/JS), Backend stories (for the APIs to be used by the app) and Mobile stories (which required specialized mobile knowledge).

The stories were provided in the form of Story Name - Story Points - Skill, where Skill defined which type of Engineer could do it (everyone, Front End only, Backend only, Mobile Only). The stories were real stories (they actually were partially based in another project we had made before).

Resources

We provided a set of theoretical Engineers for the project. Engineers were defined in 2 dimensions: Seniority (Jr., Mid level, Sr, Tech Lead) and Skills (Fronted, Backend, Full Stack, Mobile). Each Engineer had a specific seniority and a combination of Skills they had.

The Seniority factor was modeled as the number of story points that an Engineer could finish per Week.

The idea here is that the Project Manager candidate had to consider the skills and seniority when assigning each story to the different Engineers.

Time

The last of the constraints was modeled as the date when Business had asked us to release the software product. The available time of course was not enough to implement the full list of requirements considering the available resources.

Moreover, as part of the definition of the problem, we asked the candidate to consider people going on vacation and getting sick (I barely remember even adding some vacation days for some of the Engineers, although I am not sure of that).

Evaluation

The desired output of the challenge was a type of Gantt chart. We did not explicitly asked for this, but asked the candidate to use any tool hey could, so that at the end of the challenge, he would be presenting to "Business" (i.e. the CEO, given that this was a small startup) the plan for realizing the project. The best candidates usually made some kind of Gantt chart.

The output was only one aspect of the evaluation, another (more important to me) was the interactions that happened while doing the challenge; these in the form of questions to the Development team, or questions to the Engineering team.

As candidates asked questions, possibilities opened here and there. For example, one story that was 8 points if he asked if it could be split in two, the answer was usually yes (given that those were real stories, I tried to stay true to the story and give a "real world" answer. For example if the 8 point story was a complex frontend screen in the App, divided it in 2 stories of 5 and 3, dividing the screen development in two parts).

At some point some candidates even asked about QA considerations (something I did not consider initially), so we gave them some "advantage" (in the form of time, telling him that say, the stories had some QA in them, which could be split and maybe better accommodated).

The one thing that we were looking for was for candidates that not only filled up the scope until filling the time available in the project, but that went a bit further away.

My experience with startup projects has been that there is always not enough time to do all the required features, but the greatest value (and challenge) comes into prioritizing the tasks so that the team can deliver the mythical MVP on time, and then, perform additional iterations improving the product. This type of reasoning is what we were looking for as part of the output of the challenge.

Results From Applying The Challenge

In general, candidates that asked more questions produced a better result. We interviewed about 30 different people for the position and we had a very diverse set of responses.

Some candidates had a stronger technical background, and thus could leverage more the content of the stories. Other candidates had not so much technical background and leveraged more the business side.

In general, the challenge was a success, and in the end I remember we found the right candidate for the team.

Something important to stress is that, this like many other "technical" (in the sense of, having to implement something, in this case a plan) interviews tends to suffer from a "degradation of context" problem: When we created it, it was very clear for us that the evaluation consisted in not only the end product (gantt chart, or anything else) but the interaction and general process that happened during the 3 hours. If other people start using this challenge, it is important not to lose this context and only consider the end product for the scoring, as it will be misleading.

I've seen this happen in other types of challenges (specially ones that comprise programming something). Where inexperienced interviewers decide to apply the problem for an interview and score it as in a "black and white" given the program provided by the candidate.

The Whole Point of Blockchain

 • 

I loved this tidbit from this MIT technology review article describing the point of the Blockchain technology:

The whole point of using a blockchain is to let people—in particular, people who don’t trust one another—share valuable data in a secure, tamperproof way. That’s because blockchains store data using sophisticated math and innovative software rules that are extremely difficult for attackers to manipulate

Evaluating non Technical Employees

 • 

A good post on how on how to evaluate the non-technical side of employees. They used this framework to evaluate Product Design & Development collaborators:

https://mikeindustries.com/blog/archive/2016/06/evaluating-employees-in-product-design-development-roles

They used what they called the "four pillars". And evaluated by asking a person's peers to score them:

  • Getting things done: Pretty simple. Do you do what you say you are going to do? Do you go the extra mile to complete work that needs completing? Are you where problems go to die? This pillar is both a measure of dependability and prolificacy.

  • Creating strong relationships: Product development is a team sport. As I mentioned in Three Years in San Francisco, Intelligence X Collaboration = Results. Note that the relationship is multiplicative. If either I or C nears zero, so does R. Unless you are running the world’s worst interview process or physically sucking brain matter out of your co-workers, I is never really in danger of hitting zero. C, however, always is. If you score highly in this pillar, not just your direct colleagues will love working with you, but your cross-functional colleagues especially will. Know that designer who all engineers want to work with? That’s this woman.

  • Improving the team: One of the benefits of working at a company with other great designers, engineers, PMs, and researchers is that the sum can be a lot greater than the parts. Not only that but by virtue of being around so many talented teammates, your own career growth can happen almost automatically without having to spend nights and weekends learning new skills. We encourage people to make their teammates better by doing things like brown bag sessions on prototyping, brainstorming, and other important skills. Additionally, we encourage people to proactively help their teammates out on projects even if the project is not their personal responsibility. Improving the team can come in many other ways, including recruiting new teammates, but the point is to be a great teammate above and beyond being a great designer, engineer, etc.
  • Technical skills, empathy, and vision: These are the individual skills that most people initially assume are the only keys to success and promotion. We purposefully made them account for only 25% of the total formula to stress how important the other elements are. These are also the skills that are most customized to Design & Research. If you want to adapt this entire framework to PM, Eng, or any other function, you could probably leave the first three alone and just change this one pillar a bit.