Wednesday, August 27, 2014

I Have to Hire an SDET (Software Development Engineer Test) for iOS, What Should I Ask?

One, of many, of our beach rock finds.
This was the question I got a few weeks back when an acquaintance from Xcoders messaged me to say he had to interview an SDET, for their iOS product, later that day. He did not know what to ask and what areas he should ask them to dive into. Did I have any suggestions?

So, over Twitter I gave a couple quick ideas on what to ask.  Here is that list, expanded a little.
  • What frameworks have they used to test iOS?
    • Compare the differences between those frameworks.
    • Go review this answer on stack overflow about iOS Testing. This will give you a rundown of the testing frameworks and tools for iOS.
    • What are the pros of those frameworks? What are the cons? And the next question...
  • Have they done UI Automation testing? How? What were the results of that testing?
  • How do they manage their tests? It should be better than I don't. Tools used to track the tests to know what coverage you have is essential.
  • How do they report on them? Not much good doing tests without being able to report on the results.
  • What are the different granularities of tests and how have they used them in past positions? Which do they find the most useful for iOS?
    • Unit Tests
    • Functional Tests
    • End To End Tests
    • UI Automation Tests
    • Manual/Adhoc Testing
  • What difficulties have they had testing iOS?
    • Or maybe the more blunt; What have they found to be unsuccessful or not of value when testing iOS?
    • Ask this since it might highlight the one area you want to concentrate on they might hate.
  • I have seen testers write great and sometimes not so great bug reports. 
    • How do they log a bug? 
    • What information is important? 
    • They should have an opinion on what to include.
  • Most iOS apps use a web service back end of some kind. How do they test the results of web service calls?
    • They should be saying Charles (or alternative packet sniffer like WireShark) here and using a proxy to sniff the HTTP packet flow.
  • Whiteboard time
    • Give them a simple method (Objective-C based please), just the definition and what the method is supposed to return.
      • For example, something that takes a string and returns a sorted array that includes each unique word found in the string. I just has to be complex enough to cause them to write several examples.
    • Ask them to write testcases for this method.
    • Do they know the syntax of Test::Unit style or RSpec style?
  • Can they program? If not, then you don't want them as an SDET. The whiteboard coding question should be a breeze for them.
  • Do they know scripting languages? Ruby? Python? Javascript? 
    • They should since the tools built on top of Apple's iOS testing frameworks are normally written in a scripting language.
    • They will also need to integrate tests with build systems which means command line knowledge and the ability to script command line jobs.
That was the short list I came up with with some additions once I expanded on the brief Twitter exchange.

Anything else you'd look for or ask?

Monday, August 25, 2014

Is Contracting For You?

I have not answered that myself and as such I am asking myself that question. I certainly like the fact I am working on new things and getting to branch out into areas I might not normally get a chance to work with. That said, there are some downsides as well.

At first you are going to see that hourly rate and say, wow that is a lot per hour. Hold on there though. Most likely that rate does not include paid holidays or vacation time. So you need to take your salary/year based on 40 hour work week (if your contract is 40hr/week) and then minus the vacation time you'd like to have and the holidays you won't get paid for. Check up front to find out if you can work holidays. If you can't, each of those days off is 8 hours of pay you are missing.

That adds up to make your hourly rate start to not look so good.

The other thing to consider about your rate and contracting is are you going to go with a firm (I have) which makes finding contracts easy but eats into your rate. Meaning, that the contracting company is taking a cut of the rate per hour you are being paid. Now, you don't see that taken out of your pay cheque, but needless to say, if you want to do the harder path and run the business side of things then you can make more contracting on your own.

Also, do you want to gain ownership of something and make decisions about the design and direction of the product? Then contracting, unless it is an architectural position, may not be your thing. So far I have seen that contractors in general are paid to get stuff built. That is great if you don't want to have ownership and just like doing new things each day. Not so cool if you like to have a say in the product and help design what you ship.

I am still out on this one. There is certainly an advantage to just being a grunt, getting stuff done. It is amazing to see the amount of code/progress you can make each week just implementing and not planning. That said, it's nice to have some more skin in the game with the design of a product.

Some other things to keep in mind is that you (most likely) will not get matching contributions for retirement or other benefits. That is fine if you are getting paid a high enough rate. If not, then you are missing another chunk of cash.

Contracting has the allure of new projects, less maintenance of products, and the ability to make more hourly. The truth is that the new projects and less maintenance of long term code comes at the price of ownership in the product. The high hourly rate hides the visible benefits of full time positions that you might not consider.

So, like many things in life, it all comes downs to tradeoffs. Which ones are you willing to make and what do you want out of your job.

Saturday, August 9, 2014

Do What You Love

Riding Bauline, Newfoundland, 1999
I love a lot of things. My wife, my kids, my music, and my many passions. One of those has been with me as long as I can remember.

That is biking. I still remember one of my first bikes. It was a yellow bike that was branded the Mark II. Pretty sweet and I am sure my parents felt they hit the jackpot when they came across that bike. Boy I loved that hard plastic wheeled bike. Not even inflated tires. It was a tank and had traction about as good as you'd think for hard plasticly (very hard rubber) tires.

Of the many forms of biking, Mountain biking holds a big place in my heart, for things I love.

It's something that sits unloved sometimes. Gathering dust in the garage, tires deflating, oil drying out, forgetting the thrill of the trail.

Then a call or text comes, "Want to go biking?" Hell yes I do!

I get out the gear, I prep the bike, and I go.

The other night I went for a ride.

It was great to get on the trail and hurtle downhill at speeds my Mom would disapprove of and my kids would watch in disbelieve.

Nothing quite beats the sensation of throwing that bike around underneath you as your legs and arms pump it over roots, rocks, around ruts, and then throw the bike (and you) into a turn.

As we speed down a section of trail with beautifully hard packed corners, I saw a rise coming in the middle of the S as the turn I was dipped into, leaning over to the right, was going to transition into a fast left hand turn before switching back to the right. Stupidity came over me and I said, I bet I can jump that rise right into that left turn and swoop through this set of curves.

I write this like I had time to think this out. There was no time, my brain thought it, and I pulled up. The bike and I flew into the air.

Was this a good idea I started to think. But before I could finish the thought, the bike and my body knew what to do. Lean back to the left like I was entering that turn on the ground instead of in the air like I was.

Thump! The tires hit. My legs and arms bent. And my ass and rear wheel threw my bike and I into the turn and we both flew through it beautifully.

We had done something stupid again and both made it through.

Mountain biking is freeing. It frees the mind and the spirit.

Mountain biking is exhilarating. Am I going to fast? Will I make this turn? Phew! Did it.

Mountain biking is pounding. It makes the blood flow and the muscles ache as you drive to go faster and climb the hill back up.

Mountain biking rejuvenates my youth as I slip back into my gear and get to pretend to be a Scout Trooper on his speeder bike, whizzing through the forests of Endor.

What do you love?

Go do it.

Remember why you love it.

Tuesday, August 5, 2014

The Illusion of Expertise

Replacing a section of my front
step. Definitely not my area
of expertise.
How much time does it take to become an expert with a new thing?

Let's pick a language.

I mentored a Junior Engineer on a work term who did some Perl development for our project. He then applied to work with us full-time when he graduated. Hey, I must have done something right to have him want to come back.

When reviewing his resume he had listed Expert Perl Knowledge or some such phrase. He wrote 2 scripts for us based off of scripts I had written. I asked him in the interview if he had done more with Perl after we introduced him to it. Nope.

Expert level knowledge? Sheesh!

As a professional developer I get asked to solved problems I have no idea how to solve every day. It's par for the job.

This is no different than many jobs I am sure. I know I have asked building contractors to build or fix something that they've never built or fixed before. So as a professional your expertise comes from being able to tackle these problems without fear. I am paying them for their past experience and ability to successfully deliver; same goes for being a software developer.

What do I mean by without fear?

I have worked with people that say they can't do something since it is outside the realm of their experience? They are asked to add some new functionality to an existing app or script and they say they can't, they don't know that language. I think this is the wrong attitude.

As an Expert, you are expected to step up and say, "Sure, I don't know that language but the program is already written and it just needs some small changes. I can take that on and learn a bit about the language it is written in at the same time. Thanks."

That's how I like to approach tasks outside my realm of Expertise. With contracting, this has become something I have to say more often. Does it slow me down to learn a new language? Sure, I don't know it off the top of my head but with the wealth of information on the web and help within IDEs, there is no reason not to jump in and try out a new language.

If you think you need to be trained in a language or domain to work in it, then you are missing out on being more useful to your team. Being willing to jump in and work in any language is a plus for you in your career that will make you more valuable as an employee.

Don't fear your lack of expertise. Dive in and take on challenges. You grow more from them than staying in your comfortable shell.

Saturday, August 2, 2014

Building Web Services Quickly

Haven't We Been Here Before?
Seattle from the harbour.

The last time I built a web service was back in 2009. I figured out Google App Engine (GAE), it was great since it used Python (my pet language at the time) and with free hosting at the level I was going to use it, that was the platform for me.

I built Hockey Tweet with GAE and then designed Tweety10, a Cocoaheads Ottawa app, which a team of 6 built in 3 weeks in 2010 for the 2010 Olympics to use GAE as well. I ramped up one of the guys on GAE and he built out our web service while I worked on whatever needed my help.

What's This Web Service For?

I have a team that is interested in hiring me, possibly on contract, for their app. They would like a portfolio to see what I have done; which is hard to show when you work for large companies. So I am building a demo app, that will have a web service backend. As such I need to build a web service to simulate some of the features they mentioned. So I am cooking up a web service to simulate the backend service they want to build. I figure this is a good portfolio piece.

You see, I have worked for many teams/companies but those have been larger teams that had many people building the end-to-end solution. For this, I need to show I can build the app end-to-end. They are looking for their own on-site web services programmer but I need something to build my app against for the demo.

I also want some experience with technologies/framework/APIs I have not used yet. There are a lot of frameworks and APIs available to use in modern mobile apps and as such it is hard to find time to learn stuff you don't need for your day to day job. So, I want to try out some stuff I would need for this project, if the team decide to go with me, and also that will help me improve my portfolio to show that I can build an app from scratch with various technologies to meet a clients needs.

Tonight I laid out the storyboards for the app based on the initial use cases the team told me about. The storyboards let me get an idea of what data I will need to support the app. With that in mind I can also think about what the API calls should be. I see the storyboards as a visual walkthrough of the user stories, a kind of overview of the apps back-end.

Deciding on the Web Service Framework

I did some research an evening or two ago on various web frameworks so I could figure out what to mockup the backend web service in. I decided on sinatra, which is built on ruby. It is an alternative to Ruby on Rails and instead of following a Model-View-Controller design it is geared towards quickly developing a web application. So in other words, throw good design to the wind and hack up that web service fast. Perfect.

With Sinatra, you get the basics, but there are some additional features I want which were easy to add. I have added the following gems:
  • gem install sinatra
    • Basic sinatra framework
  • gem install sinatra-authentication
    • Adds authentication framework for your apps. I want to simulate adding users, login, logout, and then mapping users to resources (i.e. events for a user)
  • gem install sinatra-jsonp
    • To add json data payloads.
  • gem install shotgun
With that I have a basic web service running that I can talk to.

Next I will start to build up the API and write tests to hit the web service. I will then start to fill in the app by populating the UI with the data I am pushing from the web service.

I could skip the web service and do this with dummy data in the app but I want some current experience building a web service and so I am approaching the demo app this way.