I was listening to a piece on NPR on 6 Steps To Find A Job For Soon-To-Be College Grads and it got me thinking about my resume (Word version), what I'm doing right, what I could be doing better, and how to make it stand out.
One of things that I think that has worked for me (really well, I'm guessing based on the response rate to my resume, feedback I've gotten when I've copied this format for others in my family, and comments made to me by interviewers) is that my resume uses a two column format.
I have interviewed quite a number of people over the last several years for various projects and I'd say only 1-2 resumes have popped up in my inbox in two column format.
But there is a very good reason why I think it's a successful format -- especially for techies: you can present all of the key information in the first page and it ensures that you can put your most recent experience up front and center without losing the ability to call out additional information in a side column. Almost every resume I've gotten from any resource with actual experience has been longer than one page. But the problem with the traditional one column format is that:
- It is not an optimal use of space because in many cases, you don't have enough text to go the full width of the page (for example, a bullet list of skills) or going the full width of the page makes reading the text more laborious (for example, using a comma separate list instead of a bullet list).
- It becomes more difficult to get a concise view of a candidate without having to flip pages or scroll. With a properly configured two column resume, I can easily get a very concise understanding of a candidate by simply reading the first page without having to jump around.
I think one additional benefit is that it allows you to more clearly isolate your experience from the other sections of your resume. What this means is that you have your experience all in one vertical list without breaks or sections. Even though it's a minor nuance, I think it makes the information easier to digest as it makes a clear spatial delineation of content.
The format is flexible. I like to put my personal statement and education on the side column on my first page, but you can easily switch it with whatever information you deem to be more pertinent to how you want to express your qualifications.
One closing bit of analysis is that the format works in this age because many web sites and blogs are designed in the same manner in terms of visual layout with a primary column of content and a secondary, smaller side bar of navigation or smaller chunks of content. I think that this is very effective because it creates an easy analog to how a reviewer of your resume would visually navigate a web site.
In some discussions regarding Windows 8 and Surface, it has occurred to me how miserably Microsoft has failed in advertising the Surface.
Check this ad:
There is no substance to their message. You can watch this ad 100 times and not understand what is being sold here.
Look at Apple's ads for the iPad or i-Anything.
"Hey, look at how simple this is!"
"Look at how you can do all the things you want to do easily!"
Their recent ads for the iPad mini are brilliant in its simplicity: just two tablets side by side with people video chatting, playing games, playing apps, etc. They've effectively communicated "Hey, it's the same thing, only smaller" (whether this is true or not) and "It's so easy, even your grandmother can use it" and "Look, you can stay in touch and communicate so easily with your loved ones!".
This is what consumers want. Whether iOS is actually easier or not is another debate, but great advertising creates the perception that iOS is indeed the easiest to use. Consumers can connect with this advertising because it is simple, straightforward, and effective in communicating a brand image and embodied that brand image: "It's so simple, we don't need gimmicks to sell it."
What has the Microsoft campaign given us? What is the message? What is the key selling point of the Surface according to these ads? How is Microsoft capturing the market? A bunch of folks dancing around clicking a tablet into a keyboard dock. Is this ad selling me the dock? Is this an accessory? Why do I want to buy this hardware? Does it come with great software? A consumer can't tell based on that ad. Microsoft has literally given consumers the song and dance -- a gimmick, if you will.
This would not be the first time that Microsoft has failed miserably in designing a marketing campaign lest we forget the abomination of those Seinfeld commercials. They had a pretty good stint with Windows Phone, the "I'm a PC" campaign, and the a few clever bing commercials as well. Their tablet marketing campaign has been lackluster and has failed to differentiate themselves from the competitors. They have not demonstrated a reason to choose a Microsoft tablet over an iPad or Android tablet when they could have easily done so with an effective campaign around the software.
There have been many defenders of Microsoft online in various forums, but I'm not sure why there are so many fervent Microsoft defenders when clearly, the Win8 release has been a mess on nearly every possible level from the software architecture to the hardware to the marketing. "Yeah, but it's perfectly fine if you do this and that" is not a good defense because the operating system should be usable right out of the box.
It occurred to me that enterprise social is kind of like holiday parties -- AKA: enterprise socials.
When you go to a holiday party, you probably primarily interact with and socialize with the group of people that you work with on a day to day basis anyways.
But more importantly, according to recent studies, while 9 in 10 companies plan to have a holiday party, only 1 in 20 employees actually want to have a holiday party.
In my opinion, this more or less mirrors top down enterprise social initiatives. Employees would probably rather have better communication and collaboration tools and don't actually care about social tools (I make the distinction because you can have communication and collaboration without social).
It is the leadership that crumbles to the sexy sales pitch of enterprise social, failing to make the distinction between communication, collaboration, and social. Give your employees more communication and collaboration and skip the social.
Reflecting on the past year and a half, I've come to some conclusions on how development teams can be successful in delivering software. I don't think any of them are major or relevatory, but I think each team and each project has a different take on the same ideas. Here are mine:
During our active build phase, we release a new build every week and each build is functional software that incrementally incorporates requirements and defect fixes from previous builds. This has given us the benefit of allowing our customer to preview the software and help us identify flaws or areas requiring additional clarity in the requirements continuously and early in the process.
It might sound insane, but it is possible to release weekly builds because our solution incorporates a heavy dose of automation where it counts on many levels.
- We've removed raw SQL from the equation, relying purely on FluentNHibernate and NHibernate to automatically generate our schema
- We've invested in building tools to automate the export and re-import of configuration and data, allowing us to easily and quickly reset our development environments entirely with standard test data (bonus: the same tool allows us to move configuration and data from environment to environment)
- We've invested in idiot-proofing our installs so that they are boiled down to a few scripts
- We've built automated build scripts that package everything up neatly and even FTPs a build to our integration and test environments
- Our domain data model is 90% generated automatically from content schemas (SharePoint content types) which we have to create anyways.
Because of the automation, tasks which would otherwise be expensive are cheap to execute.
It also cuts down on mistakes and missed steps.
Our team is 100% geographically dispersed with developers and team members in Vietnam, Mexico, Virginia, New Jersey and California.
But relatively speaking, we meet very infrequently. Two development team meetings a week: one at the start of the week -- our "A" meeting -- and one towards the end of the week -- our "B" meeting. We use the "A" meeting to discuss our deliverables for the week and the "B" meeting to discuss the outcome of our weekly sprint walkthroughs, any adjustments that need to be made, and so on.
We also use these sessions as show-and-tell to let everyone see the progress and changes being made by different team members as well as to inform of upcoming breaking changes and mitigating actions required downstream.
Otherwise, developers are encouraged to have long spans of uninterrupted work time instead of constantly being pulled into meetings. One-on-one sessions and communications occur as necessary, but this recipe has been very successful in minimizing the amount of time the team spends huddled up in conference calls and gives everyone more time to solve problems.
Meet with a Purpose
Every meeting should have an agenda and an outcome (an action, decision, or an issue for followup). Demand a bullet-listed agenda when someone sends you a meeting request and provide one if you need to schedule a meeting. Ensure that the goal and outcome of the meeting is clear for all parties and schedule new meetings to resolve items not on the agenda or do not contribute to the outcome.
Additionally, create a record of every meeting. Who attended? What was covered? What was not covered? What was left open? What are the action items? Ensure that this record is easily accessible (wiki or forum system is perfect for recording these details) and email a copy to all participants and other relevant parties to ensure that everyone has the same understanding of what was just discussed. This basic task can often clear up misunderstandings before they become systemic issues. I take the burden on myself to record and followup with major bullet points from the meetings and it's saved my butt many times when following up with customers.
This is the simple art of not running a terrible meeting.
Lead by Example
A bit of career advice for those with a passion for software development: never remove yourself from the process of creation.
I have witnessed it as the career ladder moves individuals up and up, further from the pure act of creation that is software development. For those of us who feel invigorated when we solve a difficult programming task, for those of us who feel a great rush of exhilaration when a machinery of thousands of lines of code executes in harmony, it is our burden to tinker, to learn, and to create.
When you "ascend" from developer to architect or team lead or such, never leave your passion for creation behind; authority flows naturally from understanding, knowledge, and mastery -- not just a title.
I was inspired to reflect on this by an interview with James Dyson in Wired:
Wired: Now that Dyson is a sprawling, multinational corporation, how do you keep the spirit of innovation alive?
Dyson: We try to make the corporation like the garage. We don’t have technicians; our engineers and scientists actually go and build their own prototypes and test the rigs themselves. And the reason we do that—and I don’t force people to do that, by the way, they want to do it—is that when you’re building the prototype, you start to really understand how it’s made and what it might do and where its weaknesses might be. If you merely hand a drawing to somebody and say, “Would you make this, please?” and in two weeks he comes back with it and you hand it to someone else who does the test, you’re not experiencing it. You’re not understanding it. You’re not feeling it. Our engineers and scientists love doing that.
As a team lead, never just be a middle man with the developers and requirements; be an active participant in the process. Work on the hard problems. Understand the creation process and understand the challenges of the team from the bottom up and build your authority from your ability to innovate and solve problems.
If you watch shows like Iron Chef or Chopped, every one of the judges and every one of the Iron Chefs can be considered the vanguard of their craft and it is from there that their authority flows. You would not watch Iron Chef if all the Iron Chefs did was design the menu and then watch their team cook. You would not trust the judges on Chopped if they weren't great chefs in their own right that understood the ingredients, the techniques, and the skill required to pull off a dish.
The better you understand the system, the better you understand your team, the more effective you will be in understanding the root cause of an issue and how to route defects within the team.
Push Your Team Incrementally
As a young developer, I always found great satisfaction in solving new problems and new challenges. I think it's important that throughout the process, you push your team members and give them tasks that challenge their knowledge and abilities to push them just a little bit.
Of course, there will be plenty of mundane code and defect fixing, but don't box in your team members intellectually. Understand their capabilities individually and push them to try things that are just beyond their current level of capability, understanding, and comfort zone. This will keep them engaged and improve their skills to boot.
Invest in Code Quailty, Especially Early On
It's a lot easier to write good code earlier on in the process than it is to come in and try to refactor later on. Additionally, code written early on tends to be reused more often and patterns and solutions are copied by other developers later on. So early in the process, it is important to keep code quality in mind and correct bad behaviors since the most influential code will be written earlier in the process rather than later.
What this means is that detailed code reviews are far more important at the beginning than at any other time in the project. If you can correct bad programming practices or show a developer a better, more modular way of writing a piece of functionality early on, she will carry that knowledge throughout the project.
We rarely do code reviews now (1 year in) as I focused heavily on working one-on-one with developers as they joined the team to ensure that the code was up to standards. I frequently rejected code and asked developers to rewrite whole pieces of functionality to help them understand why one design was better than another.
Put Your Best Developers on Your Least "Visible" Code
What this boils down to is the framework level components. Your best developers should be working on the deepest innards of the system that power what the rest of the developers do at the presentation and business logic layers. This code will be the most invoked and the most reused so it is important that it is:
- Easy to use and as intuitive as the platform you are working on
- Well structured and object oriented to reduce repetition of code and code complexity
- Well documented with abundant examples -- your best developers must embody and practice whatever best practices have been designated
Do not waste your best developer's time with defect fixes (unless there is sufficient bandwidth), even if they can do it better than anyone else on the team because it will throw off the balance of the team (your more junior developers might not be able to fix a low level defect as quickly, but there are many design issues and higher priority defects that they cannot solve effectively yet).
Document, Document, Document
Early on in our process, I had to decide between a wiki system or a Word document for our documentation. Because of the fast, iterative nature of the project, I decided to use a wiki/forum system as it was more flexible and -- in a sense -- more "visible".
While our formal documentation is trailing, it is easy to assemble it from our weekly sprint guides which document every new feature with screenshots, details, and examples.
But at any given time, our customer and our delivery partner can load up the wiki and see exactly when we delivered a feature, how to install and configure the feature, how to use the feature, and so on. By putting it all out there in lock-step with the weekly delivery, it is easy to ensure that the entire team is aware of the status of the project and progress being made and allows test teams to progress iteratively so that by the end of the project, most features have been tested for weeks.
Mid ways through the project, we moved from "status" focused meetings to "demo" focused meetings where we would do a weekly writeup and walkthrough of what changed, what was added, and what was fixed. It also allowed for open forums for test and business teams to ask questions and get clarifications.
This approach has allows the customer to see progress and the customer will never be surprised at the end of the project as they will have seen the progress and documentation update on a weekly basis.
So far, we have done well with these basic guiding principles.
I'm sure I will revise and add to my own lessons learned as the project continues, but I think that this is a good starting point!
I had always been under the impression that the pineapple plant itself dies after it bears fruit so after my pineapple bore fruit this summer, I pretty much ignored it -- rarely watering it at all. I've even left it out at night in sub-60F evening weather thinking that I was going to dump it anyways.
Lo and behold, as I was walking past it yesterday, I noticed something...interesting:
I'm not quite sure what happened here as it appears as if there are now three plants in my pot with two of them growing out of the original (click the picture to see a larger one). I also peeled back the dead leaves at the base. Check out the root system:
For reference, here is a wider shot that shows the two new (?) plants, the original plant, and the root system:
The pineapple is indeed a fascinating plant!
Yet another post on interviewing
As both an interviewer (mostly) and an interviewee on topics of SharePoint, I've been working on refining my questions and technique here to get right to the core of understanding a candidate's suitability.
As a general rule, I never start with "factoid" type questions and almost never bring them into an interview in the first place. I don't believe in quizzing on facts unless there is a very good reason since nowadays, unknown facts can be googled instantly anyways. Oddly enough, I only end up on factoids when I'm interviewing a very strong candidate. I generally run interviews with a "choose your own adventure" type of style -- no two candidates ever get the same exact questions. It works for me because I like to talk about technology and design in general.
That said, I've pretty much boiled it down to a very small set of questions that I start with to determine a candidate's level of expertise and suitability for a given role.
What do you think are some of the more interesting/significant/useful features in SharePoint 2010 compared to SharePoint 2007?
This is an open ended question and what it measures is a candidate's suitability for an architect or lead type role. The function of an architect or lead is to understand the platform and tool as a whole so thus they need to know what they can do with the tool and understand how to compose the components and capabilities into a set of solution patterns.
With this one question, you can pretty much weed out anyone who is not suitable for an architect or a lead. A good answer will run down a list of the core feature changes in 2010 compared to 2007 and a strong candidate will be able to identify 2-3 which she thinks are significant in her view.
The exact ones don't matter as it's a matter of opinion, but a strong candidate will be able to talk about it with detail. I will note that the ones that a candidate picks will help expose their strengths and leanings (enterprise content management, custom development, configuration, etc).
This question alone can carry you for 20-30 minutes of discussion.
Consider a scenario where you are developing a product that integrates with SharePoint and has a number of ASPX pages. You would like to implement a license check on every page to ensure compliance and show an error message if the license is invalid or not found. Give a high level design of how you would implement this.
Again, there are multiple ways to implement this but some ways are clearly better than others. What I'm looking for here is for the candidate to expose how she thinks about SharePoint as a platform.The first sub-question is where would she propose the license be stored? It can be stored in SharePoint itself, in the web.config, in the hive, as a persisted object, etc. -- but it is up to the candidate to justify and explain their choice. Whatever they choose, I point out a weakness and see how they respond Strong candidates can defend their position or can see the weakness and will propose a workaround. Weak candidates get thrown off pretty easily.
The second sub-question is how the candidate would get the functionality on every page. The best and most straightforward answer is to create a base page which implements the license check and all pages inherit from the base page and automatically get the license check capability. There are other ways (perhaps an HttpModule?), but the point here is to see if they naturally think of inheritance to coalesce common functionality. It's really an inheritance question put into the context of a realistic scenario -- if you understand the goal, then you can create variations of this question that suit your use cases.
Consider a scenario where you develop a component and it requires modifications to the web.config file to work (i.e. custom HttpModule, custom HttpHandler, third party library). Can you propose a way to manage this at deployment time?
Again, a question with a lot of possible answers, but really only two optimal ones (SharePoint itself offers at least two ways of doing this and automatically propagating those changes across all servers in the farm). The key here is that most answers will be "I'd update it manually" but this is clearly a sub-optimal solution as a farm may have multiple servers in it and each will have to be updated. But I like this question because it's a "thinking" question, even if they don't know the answer from the framework perspective, you can tell if they are thinking about the question because some will realize that this is not manageable with a large farm and prone to errors (say 8 servers).
Of course, there are other more specific technical questions that I ask that are feature and role specific, but these three are really my "go to" questions. What do you think? Any other questions that you've found to be useful in interviewing for SharePoint candidates?
One of the things I've had to do quite often in the last few years is conduct technical interviews.
It's always a challenge as of course, if you want to make sure that a resource is technically competent in specific tasks or role for which you are resourcing, that's pretty easy; just ask questions oriented around those tasks that they will be responsible for. But what if you want to assess an individual's broader technical competency of and experience with a platform?
As a technically oriented guy myself, it's very easy to inject my bias and my core knowledge into the equation and I think that typically makes for a bad interview. There are always many things that I know well and many things that I don't know well for any given platform. So how can I go about measuring a candidate's competency without injecting my own knowledge and experience bias?
As an addendum, for technical interviews, it's sometimes difficult to come up with a good set of questions that are "fair". I don't think it's fair to ask obscure questions for which few folks would know off the top of their head, but would have no problem solving with Google and StackExchange, for example. I also don't like to ask brain-bender type questions as I don't find the outcome of those questions to be generally useful in evaluating technical expertise.
One approach is to ask open-ended design type questions. "Given this platform, how would you design a solution to meet requirement X?" "What are the benefits of approach U versus approach V for modeling this data?" These are okay, but I find that I often get clouded by situational bias. What I mean by that is that I tend to think of problems I've solved in the recent past or problems that I'm working on now. But I know that many of these design issues took me days if not weeks of research, prototyping, experimenting, and discussion to settle upon -- it simply doesn't seem fair to ask a candidate to produce a response on the spot. It's worth something, I guess, if they are able to come up with the same solution (or a better one!), but if they can't, does one hold that against them?
So in thinking about these issues, I think one good approach is to go with a reverse technical interview. What this means is that I ask the candidate to produce a list of technical and design questions for me for the interview. My thought is that this allows me to turn the bias that I would otherwise have into a tool because they will have the same biases. They will tend to ask questions around what they've worked on, what hard problems they've solved, and what experience they have. This seems like a much more dynamic approach and would seem to provide more valuable insight...I think. It's one thing to list a skill or a technology on your resume, but it's another thing to be able to ask deep, challenging, technical questions around it.
As a bonus, being able to come up with and ask good questions is itself a valuable skill.
It's finally happened! My pineapple is finally flowering WOOOOOOOOOOO! I can't even believe it. I didn't even notice it until I randomly looked over and took note that I probably need to water it.
I started this plant some 3-4 years ago now (after my previous one died due to exposure to the cold) and it's FINALLY bearing a flower (in the middle of frickin' winter no less!). I am very much looking forward to eating this pineapple
Caught an unexpected segment in the news on airline boarding (ending is great):
I've mostly had (terrible) experiences with boarding Continental flights and I've often thought why the process is so screwed up. I've come up with the following conclusions myself:
- Problem: Last time I flew out of John Wayne International, literally 3/4 of the flight was "Elite" status. So when they did the pre-boarding, it was a huge throng of people boarding the plane at once, which negated the whole point of boarding the plane from the back first. There's something broken about the system here because it creates a weird paradox. Being able to board the plane faster is a "benefit" of Elite status, but by using this system, it extends the overall boarding time, thereby actually making those with Elite status spend an overall longer period of time sitting on the plane. Solution: Elite status is only used in consideration for upgrades and seat selection at check-in, not boarding order.
- Problem: Gate reps don't actually check the size of carry-ons. In some cases, preemptively removing larger carry-ons and forcing gate-checks would dramatically reduce overall boarding time since the large bag causes an additive delay effect. That is that it not only slows down the individual with the large bag, but also affects every passenger that boards after that passenger because a large bag taking up too much space forces "bin hunting". Solution: Actually enforce the existing rules? Seems too simple to be true.
- Problem: No one keeps their outerwear until the boarding process is over. Nothing more frustrating than people stuffing their outerwear in the overhead before everyone has boarded. This takes up valuable overhead bin space and, again, delays the boarding process for everyone that comes afterwards by forcing bin hunting. Solution: Add coat hooks on the seats and people will more likely just hook their outerwear on the back of the seat for easy access.
- Problem: Some people just don't give a damn what the gate rep calls -- they're just going to get onto the plane anyways. Solution: See below.
- Problem: Because of a combination of the above, it often causes folks to end up back-tracking and bin-hunting. Sometimes, it also causes folks to preemptively place their carry-ons in forward rows, thinking that there is no space in the back rows, which only further exacerbates the situation. Solution: See below
The whole process is generally full of chaos, completely inefficient, and seems dated -- as if no one has stopped to think about these issues and how to solve them for decades. So it's interesting to see this guy -- Dr. Steffen -- propose something new. But it got me thinking that this guy's method still has an issue: it's not realistic for gate reps to call out this seating scheme (one row, one aisle at a time). Yet this is what it demands as the process breaks down if you have passengers in row n-2 blocking passengers in row n. Furthermore, the Steffen method makes an assumption about the nature of people: that they will obey order and think in the best interest of everybody. When the gate rep calls the aisles for rows n, n-2, n-4, n-6, all of those folks are going to rush the counter at once in a single mass.
So I think an extension or more realistic approach to this method is necessary to get it to work: a new passenger queue system at the gate. It should be -- like a plane -- one center aisle with several color-coded lines on each side of the aisle and just have people queue up in "bins" first. It shouldn't match the rows in count, but should be at a 1:3 ratio per bin. In essence, it's a modified block boarding pattern, but we break it down within the block so that, for example, window aisle passengers in the block are in bin "Purple", middle seat passengers are in bin "Blue", and aisle seat passengers are in bin "Green".
The gate rep would call bin "Purple 1" to board the window seat passengers in the rear of the plane. Then call "Purple 2" to queue the passengers in the window seat in the middle of the plane, then call "Purple 3" to queue the passengers in the window seat near the front of the plane. However, the real efficiency is in having the folks get into the bins first, before they are queued up. The current Continental system results in 60 people all standing around, blocking the entrance of the queue when all that's needed is a bin system so they know where to line up.
This system acknowledges that the ideal boarding pattern cannot be achieved in real life and thus only attempts to gain efficiency by segmenting the users by zone in a pre-boarding line first. Now everyone isn't standing around in one big mass, blocking the boarding line and rushing the line as soon as their block is called. It's a hybrid of block and WILMA (which is what the Steffen method is) but not as granular as the Steffen method and adds an extra layer of organization at the gate to account for real-world considerations.