Category Archives: Programming

If you wish to make a song from scratch, you must first Invent the Universe…

To write some music, you must first invent some instruments. To do this, one might start with a simple sine wave, then do modulations and superpositions to make various ‘instruments’.

To this end, I did a little bit of research (thanks, soledadpeandes!), and put/cribbed together some python code to make arbitrary .wav files:
# Written 2016-12-26, with special thanks to:
# https://soledadpenades.com/2009/10/29/fastest-way-to-generate-wav-files-in-python-using-the-wave-module/

import wave
import struct
import math

SAMPLING_RATE = 44100
WAV_FILE_LEN = SAMPLING_RATE * 1 # 44.1KHz sampling rate, 5 seconds
MAX_AMP = 32767
CORR_FACTOR = 10
SIN_WAV_FREQ = 100 * CORR_FACTOR # Sine wave frequency, in Hz*10 for some reason, 1000 gives 100Hz

output_file = wave.open('test.wav', 'w')
output_file.setparams((2, 2, 44100, 0, 'NONE', 'not compressed'))

for i in range (0,WAV_FILE_LEN):

data = MAX_AMP*math.sin(i*float(SIN_WAV_FREQ)/float(SAMPLING_RATE)/(math.pi/float(2)))
print data
packed_data = struct.pack('h', data)
output_file.writeframes(packed_data)
output_file.writeframes(packed_data)

output_file.close

For those who are curious, this generates a 100Hz sine wave: .

Next up, some experimentation with different pitches, perhaps different timbres. Stay tuned*!

*Also 100Hz.

Interview Questions: Types of Coding and Algorithm Questions

Part of a continuing series on Interviews and Interview Questions.

Today, we’re going to look at types of coding and algorithm questions. As discussed before, these can be divided up into ‘Problem Solving’ and ‘Knowledge’ questions.

As mentioned before, ‘Knowledge’ questions are very close to ‘human glossary’ questions. ‘What is the Big-O order of QuickSort? Average case? Worst case?’.

But there are some questions which straddle the line between knowledge and problem solving, answers that few but an expert in that topic would be able to exactly recall, like ‘what exactly happens between when you type google.com into your browser and the page appears?’, or ‘compare and contrast various sorting algorithms’.

For those questions, you have to be as widely read as possible, they tend to select for those who are more naturally inquisitive for things outside their specific area of expertise.

Now, for coding questions. There seem to be a few different types, which I’ll try to separate out by data structure[1]:

Arrays and Strings – Any data structure where any element is addressable in O(1) time, where elements are allocated together in memory.

Linked Lists, Stacks, and Queues – Data structures in linear form, where elements far away from the origin are O(N) difficult to access.

Trees – Data structures arranged in a tree form, with a clear root and directionality. Often sorted.

Graphs – Data structures with nodes and edges, where the edges can connect the nodes in arbitrary ways. Home to at least the plurality of the known NP-Complete problems. Note that Graph problems are a superset of the above.

Search and Optimization – Problems where you’re trying to find an optimal (or close to optimal) solution in a large multidimensional tensor or vector field. Many in this category are easily mappable to Graph Theory questions, but many are not, such as 3-D Protein Structure Prediction. Most interviews would likely not ask questions in this category, at least not very complex ones.

Machine Learning and Statistics – Somewhat related to Search and Optimization, problems dealing with how one trains a computer to solve a problem. Likely to become more and more important.

Hashes – Data structures where space is traded for speed. Generally assumed to have 0(1) insertion and retrieval

[1]Hat tip: developer.com

Interview Questions: Other

In previous posts, I’ve talked about the most important types of interview questions:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Technical’ questions ask ‘Solve this defined problem for me.’

Today, I’ll cover some other types of questions that are known to not have much predictive power, but people still ask, either as an ice breaker, or because they have other reasons for asking these questions.

‘Ice Breaker’ questions ask ‘tell me a story about yourself, to help relax you.’

The purpose of ‘Ice Breaker’ questions is to get the conversational flow started. My personal favourite is ‘tell me about the project you’re most proud of’, because it will help to relax the candidate, and has the dual purpose of showing what a candidate is like when they’re excited about something.

Dumb’ questions ask things outside the normal boundaries of a standard interview.

From the link, examples might include “What kind of animal would you like to be?” or “What color best describes you?[1]” The ostensible purpose is to try to get beyond pre-programmed/rehearsed answers, looking for original thoughts. (I tend to prefer the ‘tell me what you’re most proud of’ type of question, as if you’re trying to knock a person off their rehearsed interview game, if they’re nervous, that might torpedo them, and you’re torpedoing them based on their interview skills, rather than actual skills. Better to choose a topic they know, and explore the limits of their thinking there.)

‘Illegal’ questions ask ‘I want to discriminate against you, in some illegal way’

Which questions are illegal will vary by jurisdiction, but generally include questions about things such as gender, age, marital status, religion, etc… Larger and governmental organizations tend to be better at not asking such questions, whether because of visibility or lawsuits. Knowing how to answer such questions can be tricky, because of the power differential between interviewer and interviewee, but especially because the organizations asking such questions may be hiring from a labour pool with few options.

‘Brainteaser’ or ‘Fermi‘ questions ask ‘How many piano tuners are there in New York’?

These questions are the stereotypical ‘Google interview’ question, which is funny, because Google no longer asks this type of question[2]. I happen to enjoy this type of question, and they can be very useful for back-of-the-envelope estimation, but don’t really have a useful place in job interviews.

Next time, we’ll go more in dept about specific types of technical questions. Stay tuned!

[1]My favourite story on this topic comes from the brainstorming exercise: “List all the things you could do with this brick.” People would come up with some small number of ideas (like <10) for how to use the brick. Then the facilitator would say something like: "List me all the ways that your wackiest friend could use this brick." Interestingly, this generally elicits many more ideas, as it removes some of the social opprobrium of being 'weird'. [2]cf. The British Empire no longer uses the ‘Imperial’ system.

Interview Questions: Technical

I’ve been writing about interview questions recently, most recently about ‘behavioural’ and ‘Situational’ questions. If you recall:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Technical’ questions ask ‘Solve this defined problem for me.’

Today, I want to talk about ‘Technical’ questions. This includes two types:

‘Problem Solving’ questions, where the interviewer asks a technical question, and expects you to go through some process to solve it, similar in some way to what one would do in a job in the field.

‘Knowledge’ questions, where the interviewer asks specific questions about your field of study or work. For a programming job, they might be about memory management or data structures, for HR, they might be about what is legal or accepted practice in the jurisdiction in question, etc…

(Note that these generally don’t include questions about a resume, which I would group under the ‘Behavioural’ umbrella, as the interviewee is expected to tell a story about them.)

So what is an interviewer looking for in these questions?

For both of these questions, the interviewer is looking for command of the subject matter and problem solving ability. There’s a whole smear of possible questions between these two extremes. (‘What is an array’ to ‘Design LinkedIn’.)

For basic knowledge questions, it would probably suffice to re-read a textbook, or read (and understand!) a glossary of the topics one would be interviewed in.

For ‘Problem Solving’ questions, answers are generally more involved.

Generally, the interviewee is given a problem statement:

“Write a program which counts from 1 to 100, and outputs ‘Fizz’ when the number is a multiple of 3 and ‘Buzz’ when the number is a multiple of 5.”

This problem statement may or may not be well defined, so it falls on the interviewee to ask questions until it is adequately defined:

“Does it also print the number when it is a multiple of 3 or 5?” “Is proper syntax required?” “What language?”

(This also makes sure that the interviewer and the interviewee are on the same page.)

I like to draw a large diagram, and/or write down my assumptions in the upper-left corner when doing problems like this. Makes things explicit, people can see what you’re thinking.

One of my best bosses described his best programmer as ‘having a reason for every single line of code’. Talking through one’s code as it’s being written can help with this.

So:

Write down assumptions
Draw a big diagram
State the overall algorithm
Write down the solution, while talking about it
Think about corner cases, run an example through in your head.

Next time, we’ll talk some other types of questions, the kinds that are known to be not as predictive, but that interviewers still ask anyways, for various reasons. Stay tuned!

“Of All the Things I Miss, I Miss my Cache the Most.”

She was in the zone. It had taken two hours, half a RedBull (she would be paying for that later), and pissing off that guy who always seemed to want to talk longer than a conversation.

Free, flying through the code. There really was nothing like it.

She was working on a new DB caching layer for their server-side app. It was one of those ‘augmented reality’ games, but for corporate training. It still felt good to work on it though, to coerce the bits to bend to her will.

“Achievement Unlocked: You have met five new people in one day!”

Ugh. It sounded terrible, having to meet so many people all the time. To have to spend all that time and effort to convince them that the correct answer to a problem was, well, correct. If only they would just *see*.

But she had given up hope of being able to open peoples’ eyes. Give her code, or a nice juicy math problem, and she’d be content for hours, sometimes days.

*rumble* *rumble*

“Time to eat”, she thought to herself. She gets up, to go to the kitchen. Nyancore streams from her discarded headphones. As she turns, you can see the t-shirt she’s wearing says:

“Of all the things I miss, I miss my cache the most.”

She looks towards you and says “You can’t fault me for that.”

She laughs to herself and continues on her way.

“Senseless Juxtaposition of Wildcards.”

He had to admire the the gall of the programmer who wrote the error messages.

“Senseless Juxtaposition of Wildcards.”

It might as well have said:

“Grow a brain!”

Or:

“Try listening to classical music.”

But then it got him thinking…

What would be a senseful juxtaposition of wildcards?

First, we would have to make a list of possible wildcards:

The ‘standard’ wildcard character, specifically referring to a character is the question mark, ‘?’. Generally standing in for any one of some set of things (or in Perl, 0 or 1 of a thing).

The ‘larger’ wildcard character, ‘*’, which stands for any number of something (including 0), sometimes expressed as ‘%’, if you’re speaking SQL.

The ‘even larger’ wildcard character, ‘…’, which is like a recursive ‘*’.

But could there be something larger still? Something which climbs the directory hierarchy in the oppsosite direction, perhaps? Something which can make it past all of the automatic filters, but is clearly wrong? Something like typing ‘NaN‘[1] into a number field box? Something which steps outside the usual boundaries, like Thiotimoline?

In a biological context, there are entire alphabets of more-and-less-specific wildcards.

So, knowing all of this, what would be a senseful juxtaposition of wildcards? Something like ‘**’, or ‘?*’, or ‘*?’ would be meaninglessly equivalent to ‘*’.

You could attempt to mix SQL with bash-isms: “WHERE ID LIKE ‘%*’ “, showing that you expect an SQL character string followed by a bash character string, but that is again non-sensical.

Maybe it would have to be something like ‘hello??????'[2], to say that there are 6 characters of some type after your ‘hello’.

But there it was. The senseful juxtaposition of wildcards… bash statements inside command-line SQL statements.

That was it! But he had to think. How would he use this?

[1]And like the link says, you really don’t want to confuse it with NaN3. You really don’t want to confuse *anything* with NaN3.

[2]Or ‘hello……’.

Adventures in Mobile Phone Resurrection

My day, in a nutshell:

[Background:]

0) See that your phone may be having issues. No time to spend the week fixing it. Tape[1] it up and take it to Burning Man. Wait 10 months for the issues to become serious. Go on vacation. Drop it in the airport on the way there. Nursemaid it through the vacation, trying to read through the horizontal lines of ‘VGA cable is partially detached’. Drop it on the plane on the way home.

0.5) Take it in to the store. They say they’ll replace the phone for $100, but the data won’t be transferred over. I buy a new phone and go home to check my backup situation. (All my photos and videos are fine, it’s my notes and TTD lists that I’m most concerned about.)

0.7) Get home and find out my last full backup sufficient for a ‘Restore’ is about 10 months old. For some reason the ‘Sync’ doesn’t actually sync any useful amount of data, and there are no useful ways to gain finer control of this (I’m assuming) without jailbreaking the device.

0.8) Restore the device using the old backup. It’s really odd to see your last messages with someone that are 10 months old. Resolve to transfer over the rest of the data somehow…

[Next Day]

1) Start backing up the old phone. Discover that your phone needs some number of tens of gigs to do a full backup, and your computer only has 11GB free.

2) Rummage through your hard drive, using suggestions from helpful sites, finding another 15GB.

3) Figure out that 25GB is again not enough. Start taking a closer look at that 40GB backup from 10 months ago. Look at the directory, noticing that it contains about 40k files, each named with a 40 character hex hash. Try uploading it to back it up. After about half an hour, calculate that it will take 15-20 hours. Try tar -czvf to reduce the number of files. this doesn’t significantly help the upload time.

4) Decide to bite the bullet and delete the old backup. As there are too many files in the directory for ‘rm *’ to work, start with ‘rm 1*’, through to ‘rm f*'[2].

5) Start the backup of the old phone again, it finishes, and I start the restore to the new phone.

6) After waiting for a while, the phone has reset, and it gives me the option to ‘restore from backup’. More waiting. ‘The backup was corrupt or not compatible with this device or device version.’

7) Try again. More waiting. Once again having the new phone factory reset to start the restore. Once again: ‘The backup was corrupt or not compatible with this device or device version.’

8) Look in the directory to see if there’s something obviously corrupt. Wait a second…Some of those files starting with ‘0’ are from 2015…

9) Move all of the old remaining files to a new folder. Try the restore again. ‘The backup was corrupt or not compatible with this device or device version.'[3] Realizing that I had missed other files (not starting with 0-f), or that some of the 0-starting files had made their way into the list of files for the new backup, I delete all of the files in the directory this time.

10) Full backup. Full restore. Full day.

[1]Duct tape, of course. My little friend was suffering from an ‘expanded battery’, which eventually became bad enough that the screen became separated from whatever was feeding the screen data. Two drops later, it was unfixable, thankfully still okay enough on the inside to back up.

[2]You may notice something here.

[3]Interestingly, (from behaviour, not from looking in the files), the backup program (iTunes) blindly adds new files to the list of hashed files, and probably adds them to a list somewhere in that directory. It apparently doesn’t do much checking of the backup until it tries to restore it somewhere.

Running A Sprint Planning Meeting

It’s the little things that sometimes make a difference. When I was teaching standardized test math so many years ago, I noticed as I was drawing problems on the board, all the little habits that I had picked up. Habits which make solving problems easier, habits which reduce the chance for error.

Things like the curve on the leg of the lower-case ‘t’, so that it doesn’t look like a ‘+’. Curving your ‘x’ so it doesn’t look like a ‘*’ sign.

I think some of this (probably sometimes annoying) attention to detail had carried over to Sprint Planning meetings[1].

Planning Poker is a method for a group to converge on a time estimate for a task or group of tasks. There are a number of ways to do this. The ‘canonical’ way we were taught to do this was to use Fibonacci-numbered cards (1,2,3,,5,Eureka!). This involved a discussion of the task(s) to estimate until everyone had a reasonable idea of their complexity, then each person would choose a number estimate, all of which would be revealed simultaneously, to hopefully reduce bias. The discussion before estimation would not include estimates of how long things were estimated to take, to also try to reduce bias.

While we were running our planning meetings, I noticed that we would start to slip away from this ideal, perhaps because certain things were not important, perhaps because we didn’t see that certain things were important. For example:

We moved from cards to apps, and then to fingers. Using apps for estimation is less annoying than finding the cards each time, but fingers are even faster to find. I/we tried to get around the bias effect by having everyone display their fingers at once, and that worked reasonably well. Even making each person think about their estimate before display can help a lot with reducing the impact of what others might think of them.

One thing I tried which never really caught on when other people were running the meeting was saying ‘A,B,C’ instead of ‘1,2,3’, with the idea that it would be less biasing on the numbers people were choosing. (This may have mostly been an impression of mine, as the moving of the estimate from a mental number to a number of fingers may cement it in a slightly different mental state…)

If one is not careful, and perhaps somewhat impatient in meetings[2], one can start suggesting estimates before they are voted on. It can take considerable discipline and practice to not do this.

Another thing I noticed was how difficult JIRA was to use when one is not practiced in it, especially in a room with many people watching. Something that any experienced[3] demo-giver would know like the back of PowerPoint’s hand.

That’s all I have for now. For more minutiae, tune in tomorrow!

[1]For those of you who have not had the pleasure, these are the meetings at the start of an iteration, where the team sits down in a room, estimates a bunch of priority-ranked tasks, and decides (generally by consensus) how many of them they will commit to getting done in the next two weeks. Like all meetings, they can be good or bad, and the meeting chair (I feel) can make a large difference.

[2]I am probably as guilty of this as anyone. I would recommend Randy Pausch’s ‘Time Management‘ for those who feel similarly.

[3]Read: ‘Battle-scarred’

What are your Non-Negotiables?

What are your Non-Negotiables? Most recently, I was talking to someone[1] about my New Year’s resolutions, and we were discussing why I had done one of them, but not the other two. It eventually came out that the resolution that worked (writing every day this year[2]), worked because I had made it a Non-Negotiable[3]. I had resolved that no matter what, every day this year, I would write something. Somehow, every day, I would carve out an hour or two, pushing other things aside so that I could focus and write.

(Incidentally, this practice focusing has done wonders for me, helping me find ‘the zone’, or ‘flow’ much more consciously and easily.)

Sometimes I would push aside a computer game, or facebook, sometimes sleep, but those things didn’t matter compared to the commitment I had made (mostly to myself) to write every day.

Interestingly, the other Non-Negotiable that came to mind today was the 5-minute standup. I was talking to someone about it today, and they started to say ‘5-10 minutes’, and I had to interject, with talk of Non-Negotiables, how if you let something like that slip, pretty soon you’re having daily half-hour sit down ‘stand-up’ meetings.

Interestingly, biking to work every day is not quite a Non-Negotiable. I take probably a couple of weeks off each year, some for snow, some for rain, some for events. It’s pretty close, though, and I’m not so worried, because I’ve been doing it for long enough (14 years, I think), that it’s a pretty deep-seated habit.

So, what are your Non-Negotiables? What is the one thing you want to change this year?

[1]Pretty sure it was G at a life coaching session, but my brain has this annoying tendency to abstract things away, but that’s another post. I also remember it from a speech by the head counselor at music camp many years ago, but that’s another story…

[2]At least so far…

[3]This is a good precis from a life coach on Non-Negotiables.

Computers Win when the Rules are Fixed

One of the important reminders from game four of Alpha Go vs. Lee Sodol was the difference between what computers and humans are each best at.

Traditionally, computers were best at the most repetitive tasks, that were well understood and could be completely described.

If you talk to any release or test engineer, they will tell you that once you can fully describe a process, it’s only a few more steps to be able to automate it.

What makes Machine Learning so tantalizing is that it’s been giving hints of being able to learn to perform not-fully-described tasks, most recently Go.

At the same time, Machine Learning still requires thousands or millions of examples in order to be able to ‘see’ things, whereas humans can understand and make inferences with many fewer examples. It’s unclear to me (and I’m guessing most people) exactly why this is. It’s like there’s something about the way we learn things which helps us learn other things.

But back to the topic at hand. What game four showed us (yet again) is that the better defined the problem, the better humans perform vs. computers.

A different example of this is how high paid market research analysts are being replaced by automation, doing in minutes what would take the analysts days.

So, how do you stay relevant as things become more and more automated and automateable?

As Lee Sedol showed, one strategy is to play Calvinball[1]. Find the part of your discipline that is the least defined, and pour yourself into pushing that boundary, leaving defined pieces in your wake[2].

Note: Playing Strategema like Data is another ‘fun’ option[3], but most useful only when playing against a computer opponent, not so much for forging your own path. It consists of playing sub-optimal moves so as to confuse or anger the other player, to thrown them off balance. It is postulated that Deep Blue did this to Kasparov.

[1]Calvinball is a mostly fictional game invented by Bill Watterson for Calvin and Hobbes. The game has only one rule, that it can never be played the same way twice.

[2]Technically, Lee Sedol played a very ‘loose’ game, which was difficult to define, where parts of the board far away from each other were more easily related. You can also use this tactic to find things and do them in a way where humans are better than computers.

[3]We called this ‘victory through annoyance’ during undergrad. It had mixed reviews.