Archive for April 2014
Yesterday evening I did an Introduction to TypeScript at CRineta. I agreed to do it on short notice, so I scrambled to pull the talk together over the weekend. Much of this version of the talk was based on Anders Hejlsberg’s Build 2014 talk. And of course I used the resources from typescriptlang.org along with TypeScript in Visual Studio. I’ve had a small amount of TypeScript code in production for about 6 months, but I’m going to start converting more now that 1.0 is released.
What is TypeScript?
“TypeScript is preview of EcmaScript 6 with a downlevel story and with static typing on top” – Anders Hejlsberg
The TypeScript Playground is a great place to start testing TypeScript.
Their tutorial is of limited value, but the Handbook gives you a compact view of the language features and is very useful.
And of the course the language spec is available as well.
Anders Hejlsberg at Build 2014 – http://channel9.msdn.com/Events/Build/2014/3-576
Luke Hoban at Fluent Conf 2013 – https://www.youtube.com/watch?v=5UPMqtrbw7E
One aspect of my current job that has been rewarding is getting to train and mentor other people in my group. Years ago I did technical training as my full time job and I did reasonably well at it, but I learned that doing it full time wasn’t where my interest was.
Training and mentoring as a part of my full-time software developer position is more rewarding because I get to keep my fingers in code much of the time and am still able to invest in others in my group by teaching them skills that are necessary for our department to operate well.
Today I worked with a more junior developer teaching him how to really think about Mercurial and distributed source control. He’s been able to do basic push, pull, commit and summary commands for over a year, but he’s never deployed to production. So we walked through how to think about merges and how to read the TortoiseHg graph so he could see what happens as he goes to other branches, merges, commits and pushes his changes. After about 30 minutes of explaining the metaphor and the terminology, he started running with it on his own.
Over the last 5 years I’ve trained three graduate students to work on our web projects. Two students I trained for a year and another I trained for 2 1/2 years. They each started on our web projects with a wide range of skills and abilities. So the key was taking them where they were at and giving them the right amount of space and information to grow as fast as they could handle learning.
I have to admit that it can be a bit exhausting investing in people at that level and still developing software full time, but it is very rewarding to see them be able to use those skills in other settings and move onto other jobs.
In all of my future work I want to keep developing my ability to train and mentor others.
It can be easy to snipe about bad or mediocre interview experiences I’ve had. So instead I’ve been thinking back to what really worked with past interviews.
One company from my past that stands out regarding the interview process is MetaCommunications here in Iowa City. If I recall correctly it was split into three phases. We ended up talking over the phone at first to see if there was mutual interest, but that wasn’t part of the process.
Also, when I say that it was done well, I’m not saying that it was done well because I performed well. I’m saying that it seemed to give the person being interviewed the best chance of being able to show their potential, how they go about solving problems and how they interact with others.
The first phase of the process was mainly a meet and greet to get to know each other. I went into their offices to see where they worked. There is nothing unique here, but it is a nice touch to take the pressure off and it’s the first logical step with any employment relationship.
The second phase was on a different day and it was the core of the technical interview process. I was given a computer with Visual Studio and asked to do a couple of tasks. One task was to implement a puzzle in C#. During the process I could ask questions, look stuff up and they could observe how I went about things. I forget the specifics of the second task but it had something to do with building a validation system in ASP.NET MVC.
The first task I did relatively well on and the second I performed so so. But instead of the interviewers being on the high ground and me just having to defend what I know over a phone, we were on equal footing, face to face and I was using a tool I was familiar with. We were interacting somewhat like if I were actually in the job. I strongly believe that this types of interaction gives both sides more accurate and far more information about if the position will be a good mutual fit.
The third phase was on another day and it was primarily about negotiating a salary and deciding when to start. Once again this is an important phase but it is pretty standard.
Spreading the process into 3 interviews gives some time for both sides to consider what is happening. It also puts them on equal footing, so they know who they might be working with.
Some employers might balk because it takes them out of the perceived position of control in the interview. To them I would say that even though this is true, they still will get better information on how the person interacts, better information on their technical skills and if they would be a good fit in the company.
Others are going to balk because they have to spend more time interviewing people. Yes, and it’s worth it. Finding the right people and not artificially weeding them out is critical to your business.
And others may say that the process doesn’t scale. It is more costly time-wise, but once again it is the one method I’ve seen that has been the most fair and provides both sides with the data they need to make better decisions in hiring.