A New Beginning, Part 21

WEEK 20: STILL MORE REVIEW, ANOTHER JOB APPLICATION, AND A PIECE OF CAKE!

This week I began to review what I’ve learned about JavaScript — most notably, the first 2 chapters of You don’t Know JavaScript — FABULOUS! — and once again felt more like I actually UNDERSTAND some of this stuff.

Then I went ahead and applied to Stelligent (see above). And got letters back from them saying that actually they’re currently looking only for a mid-level developer and I don’t fill the bill. But maybe later…

Well, at least I’m in the game.

The BEST thing that happened this week was that (folowing up on a hint in the job prep guidance from Firehose) I discovered the answer to a whole lot of my anxiety about the “technical interview” at which I’ll have to actually show that I can do programming by meeting a challenge the interviewer poses on the spot.

Not only is there no way to know what I’ll be asked, but the “katas” where I’m given a random problem with no preparatory guidance have been the hardest and most nerve-wracking part of the whole Firehose Project. I’ve typically had NO IDEA how to approach these problems and as soon as I feel that for a couple of minutes, my brain freezes up and my chances of thinking of anything to do plummet.

The answer is a site called “Interview Cake” and it was created specifically for people like me. The guy who created it was helping a friend prepare for the technical interview and came up with a truly brilliant and amazingly helpful approach. What he does is take problems one at a time and build up to solutions through a series of hints that point not just to how to do THIS problem but to underlying STRUCTURES that MANY problems have in common, how to recognize those structures, and the remarkably few ways to approach each of them.

In other words, he’s teaching STRATEGY, not just solutions. Exactly what I needed.

This still doesn’t make it EASY to solve many of the problems he poses (which he says are indeed the same kind of problems that typically show up in technical interviews), but I no longer feel so totally at a loss. I have some ideas about how to at least GET STARTED solving a problem. And as many people point out, in an interview getting the right answer isn’t nearly as important as being able to describe how you go about SEEKING a solution in a way that makes sense.

And who knows? Maybe the time will come when at least SOME of the problems even seem easy?

WEEK 21: O IS FOR… WHAT?

Part of getting ready to deal with the Technical Interview is learning about “Big O.” That’s a way of representing how much a program will slow down as the number of elements being processed increases. (For example, if you are pulling the first item out of an array the time it takes to do it won’t increase at all no matter how many more items there are in an array, but adding the items together will take longer the more there are, and comparing each item with each other item will take a lot more time VERY QUICKLY as the number of items goes up.)

I got curious: What does Big O stand for? No one I asked knew, so I Googled it and discovered that not everyone agrees. The guy who runs Quora said it stands for “Order of” as in order of magnitude. That sounds plausible, but it’s almost certainly wrong.

Much more likely: There is a family of notations known as the Bachman-Landau notations, which are named with Greek letters. The one most relevant to algorithms was the one with the Omichron symbol which, as Van Nguyen (“Entrepreneur, Hacker, Maker”) suggested on Quora, “can be best described textually or verbally as a ‘big O’.”

Now you know.

THE ELIXIR OF LIFE?

One of the best parts of getting into the job market is that it encourages me to go to meetups where local developers are sharing the stuff they are most excited about. Last week that meant I joined two other people hearing about a cool language named Elixir.

Elixir is essentially a new, more user-friendly version of Erlang, a language developed to make Ericssen phones work better. (Erlang began with the premise that things will break, so instead of trying to prevent that you’re better off planning to deal with it gracefully when it happens. But Erlang was apparently a bear to work with.)

What is so great about Elixir, besides its ability to deal well with things that break? During the meetup I heard about three things:

First, Elixer has the ability to work with different “cases” differently in an elegant way. Depending on the TYPE of argument you pass a function, the function can do entirely different things!

Second, it’s really easy to do test-driven development, because you can incorporate tests right in your regular code. As Adam (the guy running the meetup) put it, “In Elixir tests are a first-class citizen, not a second-class citizen.”

Third, documentation is incredibly easy with Elixir: As soon as you get done writing some code, you just give it a specific command and bang! — your code is transformed into a gorgeous document. Documentation, too is “a first-class citizen” in Elixir.

Very few companies are using Elixir so far (Ken at Firehose says he only knows of one in Boston), so knowing Elixir is unlikely to help me in my job search. But it’s still extremely cool, and that’s reason enough to learn more about it!

(More to come… click here!