By default, Xamarin.Forms handles orientation changes for you automatically, e.g.

My goal was to take the name and address of a place and show it on the native map app regardless of what mobile platform on which my app was running. While Xamarin.Forms provides a cross-platform API to launch the URL that starts the map app, the URL format is different depending on whether you’re using the Windows Phone 8 URI scheme for Bing maps, the Android Data URI scheme for the map intent or the Apple URL scheme for maps.

This is what I came up with:

Settings allow you to separate the parameters that configure the behavior of your app separate from the code, which allows you to change that behavior without rebuilding the app. This is handle at the app level for things like server addresses and API keys and at the user level for things like restoring the last user input and theme preferences. Xamarin.Forms provides direct support for neither, but that doesn’t mean you can’t easily add it yourself.

App Settings

In 1992, I was a Unix programmer in Minneapolis. I’d graduated with a BS in Computer Science from the University of MN a year earlier and had written my programming assignments in C and C++ via first a VT100 terminal and then a VT100 terminal emulator on my Mac (running System 7, if you’re curious). My day job was at an AT&T VAR building multi-user voice response systems on Unix System V. My favorite editor was vi (not vim) and, like all good vi programmers, I hated emacs with a white hot passion.

Being bored with my current job, I posted my resume on the internet, which meant uploading it in ASCII text to an FTP site where tech companies knew to look for it. The tech company that found it was Intel. To prepare for my interview in Portland, OR, I went to play with a Windows 3.1 machine that someone had set up in the office, but nobody used. I had a Mac at home and Unix at work and for the 10 minutes that I could stand to use it, Windows 3.1 seemed like the worst of both. In spite of my distaste, Intel made an offer I couldn’t refuse and I found myself moving with my new wife to a new city for a new job and a new technology stack.

This is the last in a 4-part series on how to interview well. Parts 1-3 covered the phone screen, the technical interview and the fit interviews. In his part, we’ll wrap up by talking about how to make the hiring decision.

Make Time For Questions

If you just found yourself here, you’ve stumbled onto a multi-part series on the technical interviewing process. Part 1 covered the phone screen and part 2 covered the technical interview. Today we’re going to discuss the “fit” interviews, that is, team and cultural fit.

The Team Fit Interview

It’s incredibly important to interview well as you’re building your technical team. Further, interviewing well is hard to do and, like anything, you only get out of it what you put into it. In part 1 of this series, we discussed the phone screen. In this part, we’ll discuss the technical interview.

The Technical Interview

In 30 years, I’ve done a lot of interviewing from both sides of the table. Because of my chosen profession, my interviewing has been for technical positions, e.g. designers, QA, support, docs, etc., but mostly for developers and program managers, both of which need to understand a system at the code level (actually, I think VPs and CTOs need to understand a system at the code level, too, but the interview process for those kinds of people is a superset of what I’ll be discussing in this series).

In this discussion, I’m going to assume you’ve got a team doing the interview, not just a person. Technical people need to work well in teams and you should have 3-4 people in the interview cycle when you’re picking someone to join the team.