Prior to Mentis, no employer I have ever interviewed with had asked me to write live code. At Mentis I interviewed with 4 separate people who asked me to write code on a whiteboard. After Mentis I had one other interview with a small startup company, and they also asked me to write live code. I’m surprised that some employers don’t require this in their interviews. To me it makes perfect sense to include code writing in the interview when you’re looking to hire a programmer.
I fortunately do not have anxiety while writing code for an audience. In fact, I feel more comfortable writing code than I do talking about what I’ve done. For those that do have anxiety though, Scott Hanselman has a great post about how to deal with anxiety when coding live in technical interviews. The only thing I feel I can add is, regardless of whether or not you feel anxiety writing code on-the-spot, it can be helpful to explain to the interviewer additional steps that you would normally take in addition to what you show them. For example, if you rely on IDE tools such as auto-complete, documentation links, or Internet searches, these may be things that you should mention. If you normally refactor your work several times before calling it done, this may also be something to mention. Ultimately, when you explain your process for creating quality code, this will supplement what you’ve shown them.
Start raising awareness for something you care about. One man asks people to care about ALS, and Facebook explodes with ice-bucket challenges. Meanwhile, 21,000 children will die today from poverty, hunger, easily preventable diseases and illnesses, and other related causes. Millions more won’t die today, but they suffer from one thing or another. Are their lives any less important than the lives of people who have ALS? Don’t get me wrong; if you care about ALS, then raise awareness about ALS. But also raise awareness about other things that you care about.
Among other things, I care about toxoplasmosis. This disease killed my beautiful, innocent nephew. I am not going to dump a bucket of ice over my head, but I have donated and will continue to donate to help prevent this disease.
While I’m on the topic of donations, everyone should know that charitable donations are tax-deductible. What this means is, the more you donate to causes that you care about, the less the government takes away from you to waste or give to causes that you don’t care about. So don’t whine and complain about where your hard-earned tax dollars go. Instead, reduce your taxes by deliberately choosing where your money is going to go. I’m not saying by any means that we shouldn’t keep our government in check by exposing how they waste tax money. I believe that is important, but let’s give the government less of our money to waste by choosing to donate where it will do the most good.
In addition to personal donations, we should all shop at businesses that donate portions of their proceeds to charity (preferably a charity that we care about). When businesses donate, not only can they do more to help the causes that we care about, but just like individuals, they also get taxed less as a result. The government gets even less money to waste when we deliberately take care of others in need.
I recently accepted a position with a new company, Mentis Technology Solutions. Although I was already in a good company, it wasn’t the best fit for me, so when I saw this opportunity with Mentis, I was open to seeing if it would be a better match. I am excited to be starting with them a week from now, and I am hopeful – given that they are a great company that values many of the same things I value – that this will be the last time I will ever be interviewing for a new job.
During my professional career I’ve gone through the job search process several times, so I’ve acquired a few tips that I can share. Also, just the other day I came across some of my job search notes from 2002. Twelve years later many of these notes are still relevant, and although I forgot that I had written them down, I still sub-consciously used them to help me get to where I am now. I’ll be sharing some of those notes as well. Jason Elkins, if you’re out there, many of these tips – in addition to several others – I initially learned from you. Thank you, Jason, for the tremendous help!
The Resume’s Only Purpose: TO DISQUALIFY
Earlier this month I posted about the Developer’s Resume. One thing that I didn’t specifically state is that the resume’s only purpose is to disqualify a candidate. This is why it is so important that the skills, experience, and education you list on the resume are as relevant as possible to the position you apply for. One less skill listed on your resume can be the deciding factor between you and the next candidate. Be careful what you include on your resume though. You will be asked about it in an interview. If you claim to have several years of experience in Java, you’ll be expected to write a program in Java during the interview.
Strengths and Weaknesses
I believe that the sign of a good interviewer, and a good company to work for, is one that does not directly ask you what your greatest strength or weakness is, however they will indirectly try to gain this information from you. If they don’t, they may not be the right company to work for. That being said, be ready to answer the direct, cliché questions, “What is your greatest strength?” and “What is your greatest weakness?” There are several other resources that can help you develop strong answers to these questions. Again, these questions may never be directly asked during the interview, especially from savvy interviewers, so be sure that you can work the answers in to the interview in one way or another.
My greatest strengths that I had listed in 2002, which have been surprisingly consistent to today, were “Attention to Detail”, “Willingness to Help Others”, and “Strong Work Ethics”. For over a decade this has been the message I strive to get across during the interview. My greatest weakness was a tendency to get overloaded with deadline pressures. To combat this weakness, I put in extra hours and take extra time to get organized before things get heavy. I can now confidently say that this is no longer much of a weakness for me, but it was because I worked on it. This is important to state in the interview – I put in the extra effort required to improve and reduce or eliminate whatever weakness I identify in myself.
Asking for the Job
Another sign of a good company to work for is that they will interview you more than once before offering you a job. You will likely interview with an HR person, the manager you will work for, the owner or executive who manages the department or company, and possibly one or more peers. Each of these people is looking for something different from you. You may not know what their personal expectations are, but the professional expectations are pretty consistent. During each interview it is your task to “ask for the job” by showing them what you have to offer that will benefit them.
The HR person, who is often the initial candidate screener, wants to know:
• Are you a freak?
• Will you be comfortable (in the position and the company)?
• Will your co-workers be comfortable with you?
• Show them you would like the environment.
The hiring manager wants to know:
• Are you skilled?
• Will you cause problems on the team?
• Are you easy to manage?
• Show them you are eager to learn what you don’t already know, that you follow-through, and that you are self-disciplined.
The peer wants to know:
• Will you do your job?
• Will you like working with them?
• Show them that you’ll be a good co-worker.
The owner or executive wants to know:
• How will you impact the bottom-line?
• Show them you have saved your previous employers money, and that you’ll do the same for them.
If you can successfully show each of these people what you have to offer, and what you have to offer is better than the next candidate, then you’ll be the one getting the job offer. Honesty, of course, is paramount here though. If you can’t deliver on what you promise, you’ll be better off not promising it in the first place. The goal is not just to get a job, but to get a job that you will like, one where you will be appreciated and respected, and one that you will thrive in.
These simple words are crucial to sealing the deal. Always thank the interviewer for their time. During one of my final interviews with Mentis, I was told that they had received over 300 applications and that they had selected only a few to interview. Put yourself in the shoes of the person who has to read through 300 resumes and cover letters. Imagine their pain. When the candidate shows appreciation for you in the cover letter by thanking you for your time, how likely are you to promote theirs to the top of the list? Now put yourself in the interviewer’s shoes. They are already swamped with work – otherwise they wouldn’t be looking to hire someone new. After they take an hour out of their day to invest in you, isn’t thanking them the least you can do to repay them? If you’re the only one of the candidates who sounds sincere when you thank them, perhaps that will be the difference that gets you hired.
About a month ago I took a long, hard look at where I am and where I want to be. The company I currently work for is a great company, and I work with great people. I also get paid quite well. However, the environment that I have been working in clashes with my personal work style. I take application development very seriously, and I strive not to allow any deficiencies into the software that I create. Others within the company, despite their ability to tackle tough problems and create innovative solutions, do not share my love of perfection. I do not claim that I am right, only that I find it difficult to work in an environment that forces me to go against my natural work style. After trying to fit in for over a year and a half, I saw an opportunity to join a company that more closely matched my skill set, interests, and values. I applied a couple weeks ago, interviewed with them a few times, and this week accepted an offer with them.
When I applied to my new job, I evaluated my resume from the perspective of the hiring manager. When I had applied to jobs in the past, I used all of the commonly accepted best-practices for creating a resume. I highlighted my education. I used action words. I included percentages and figures that were meant to impress the reader. I made the visual format appealing. I did everything that was recommended. Unfortunately, I have learned that in my field these best-practices don’t even matter; hiring managers and recruiters look for a couple specific things when they evaluate candidates applying for a software or web development position. First of all, does the candidate have the required skills? Secondly, is the candidate competent enough to present a case that their existing skills match the requirements of the position. They might be interested in other particulars of the resume, but if you don’t satisfy those first two things, I’ve learned that the employer usually is not interested at all. Fancy looking resumes with action words, numbers and impressive educations won’t do the trick.
My advice to developers working on their resume:
1) Create a section of the resume to list your technical skills. Your technical skills are most likely how you will initially be selected in or out of the candidate pool.
2) When you send your resume out, rearrange these skills to match the priority that the job posting lists them in.
3) In your descriptions of your past job experience, highlight the skills required by the job posting if they applied to the position.
4) Always write a cover letter. This lets the employer know that you are competent and serious about performing to the best of your ability.
5) If you are weak in a particular skill, or if there are any other areas of the job posting that might not match perfectly, let it be known, but do it in the cover letter. Explain where there may be an issue and make a case for how you can provide value regardless of the issue.
That’s my two cents on developer resumes. If any developers out there have had different experiences, or have had good results with other tips, I would love to hear from you.
Lastly, the following article contains some other great tips on resumes in general:
I have been working on a Windows application, TM1Compare. If you are a TM1 developer or administrator, I highly suggest you check it out. It can save you a lot of time and hassle. Click here to check it out and download the Lite version for free.
One of the features we have recently added is the ability to copy view data from one server to another. This can be done through TM1Compare without needing to export the view, copy-and-paste, or import the data through creating a complicated ETL process. TM1Compare handles all of this work in the background with a couple simple steps.
A challenge I came across while working on the view data feature was how to alert the user of important information without being annoying. TM1Compare allows the user to copy data on a single-view basis or in bulk. When copying a single view, if there is a warning we need to display to the user about that view, we display a message box and ask the user to make a choice whether to accept and continue or cancel. When the user is copying data in bulk, we didn’t want to repeatedly annoy the user with multiple message boxes, unless we could offer them the chance to make the same decision for all of the views at once. Several applications have similar functionality, such as a checkbox labeled “Don’t show this again” or “Apply to all…”. I was surprised to see that in the .NET Framework 4.5, not only is this not a standard option, but the MessageBox is a sealed class and cannot be extended to add it.
After reading several posts on StackOverflow.com, I found two options for creating the functionality I needed. Several people suggested creating a custom dialog window and displaying it as you would a normal window. I wanted my solution to have a look and feel just like the native Windows message box, which varies depending on the version of Windows the user is on, as well as the configurations they have set up in Windows, so I opted not to make my own window. The other option was a nifty trick posted by Code Project, building on Dino Esposito’s October 2002 and November 2002 MSDN articles to “hook into” to the native Windows message box and add the functionality directly into it. I decided this would work perfectly for my purposes, so I downloaded the sample code and modified it slightly to fit TM1Compare.
In Scanlon’s sample, the MessageBox wrote to the Windows registry. For my purposes, I didn’t want the user’s choice to be permanent, but to last just for the session they are in. I modified the MessageBox.Show() method to take an out parameter, which was then checked by the application and stored in a session variable.
In my current job I work closely with IBM Cognos TM1, creating and extending multi-dimensional OLAP databases and applications that work with these databases. When I first started down this path, I knew very little about OLAP and business intelligence technologies. To further my training last year I read through “IBM Cognos TM1 Cookbook” by Ankit Garg, ISBN: 978-1-84968-210-7. When I picked this book up I expected it to be an advanced manual which would provide some tips and tricks beyond the beginner level. Instead, the author takes the reader through TM1 from start to finish with tutorials of how to construct a single TM1 database as if he was writing a beginner’s manual. He does attempt to teach the reader some tips in-between the basic tutorials, but the author is not a very good English writer so some points he tries to make were so confusing that I ended up skipping past them.
Garg’s book is littered with spelling and grammar errors, and also contains some logical inconsistencies. Another problem with the book is that the screenshots are sometimes irrelevant, incorrect, or incomplete. One of the tutorials instructs the reader to create a “Full Name” attribute and populate it with values from a screenshot. The screenshot, however doesn’t display these values because the author didn’t maximize the window to show its entire contents. A scrollbar is visible in the screenshot, begging to be scrolled so the user can see the values they’re supposed to enter. Unfortunately, since it is a static image the reader will never know what those values are. I had been working with TM1 for a few months already when I picked up this book, so I could look past some of these problems and still move on through the tutorials. I don’t think I would have been very pleased with the book, however, if it was my first exposure to TM1.
In the first chapter Garg not only explains what TM1 is used for, but contrasts it to other types of databases, both relational and multidimensional. He then takes the reader through an introduction of using TM1. I found this chapter to be a little too detailed in areas, and had preferred that the author leave some of the advanced topics for a later chapter or an appendix. Some information seemed like it would be helpful to intermediate TM1 users, while other information was basic enough for beginners to understand.
In chapter 2 Garg starts leading the reader through creating their first database by building dimensions. I like that he takes the reader through creating dimensions manually as well as using a TI process in the same chapter. Since most of what I do in my job involves creating TI processes, I find it helpful to cover TI throughout the entire book. In this chapter attributes are also introduced, which can be a good thing or a bad thing, depending on how you look at it. I have found attributes to be essential in every TM1 system I have come across, but since they are optional I feel it was unnecessary to use them at the very beginning of a system’s design. A more appropriate place to introduce attributes would be when a problem arises that the creation of an attribute can solve.
Chapter 3 takes the user through creating cubes and views. At the beginning of the chapter the author’s grammar had improved, and I had hopes that the editor had started doing his job at this point. Alas, I was disappointed after a few paragraphs. The format of the chapter was pretty straightforward and basic, with a couple good tutorials, and again Garg chose to implement a couple TI processes. There were a few tricky errors in this chapter, which I was able to notice and work around, but they might trip up a lesser experienced user. At the end of the chapter, I was surprised that Garg didn’t go into a ton of detail, given the amount of detail he had written in the first couple chapters. However, it was actually a nice break from the information overload that he had written the previous chapter.
Chapter 4, Loading and Maintaining Data, wasn’t written as poorly as previous chapters, but I was a little annoyed that Garg instructs his readers to manually create several Excel files throughout the book for use in TI processes. Ideally, these files should have been provided by the author via a Web site or data disc. I had an electronic version of the book, so I can’t say for sure that it doesn’t come with a data disc, but I found no reference to a data download. I chose to take the time necessary to manually create the files since later examples build on the work done in previous chapters. Choosing not to create my own data files would likely have made future chapters a little more difficult to get through. Unfortunately, even though I followed the instructions to the letter, when it came to setting up an ODBC data source, I ran into issues. After half a day of troubleshooting the problems, it appeared that they stemmed from a bug in the TM1 software that doesn’t know how to look for 32-bit drivers on a 64-bit system. All kinds of people have had similar issues using ODBC in TM1, as I found on tm1forum.com. I cannot blame Garg for this issue, but since I couldn’t complete the ODBC import, I had to choose between importing the data another way or skipping it. As mentioned earlier, the tutorials all build on each other, so I could not simply skip this one.
If you can get past the book’s many errors, there are some valuable tips that TM1 developers can learn from this book. For example, I have been through several beginning TM1 tutorials, a couple from IBM themselves, and none of them mentioned the simple fact that you can copy-and-paste Dimension elements straight into the Dimension Editor windows. Garg not only tells you that you can do it, he leads you step-by-step through creating a Months dimension using copy-and-paste from Excel. One might think that this valuable fact might be well-known, but in my experience I hadn’t come across this tip prior to reading Garg’s book.
I should also state that this book should not be the first book you read if you need to learn TM1 from scratch. While there are valuable tips that a beginner’s guide should contain, the book’s many errors and the author’s broken English make it a bad choice for someone who is not already familiar with TM1. Garg also makes some assumptions about the reader’s knowledge in some cases and overlooks important details that should be further explained. I would only recommend this book to someone who has already been through several TM1 tutorials, needs a TM1 refresher, wants additional practice creating TM1 systems, and/or wants to learn a few TM1 tips and tricks to make their work slightly easier. For me it was a good fit, since I fall into all of these categories, but I would suspect there are not many others who will get the same benefits from it as I did.
On a scale of 1 (worthless) to 10 (invaluable), I rate “IBM Cognos TM1 Cookbook” as follows:
Accuracy – 4
Bias / Motive – 8
Instruction – 7
Facts – 7
Organization – 6
Target – 4
Knowledge – 7
Reference – 8
Relevancy – 7
Research – 6
Illustrations – 6
Visual Appeal – 7
Overall – 6.4
I’ve finally decided what to use my blog for. In the past few months I’ve come across some pretty challenging tasks in my work. I find that when I discover a solution to a problem I’m working on, it’s generally the same problem that others have already dealt with. Nine times out of ten, the overall solution I end up with is a collaboration of others’ efforts. The tenth time, the solution is my own custom creation, having not found good enough examples. In all cases, however, I find that I come up with the best solution by talking it out.
So that’s what the majority of these blog posts will be. They’ll be my experience of a problem, the possible solutions I’ve come across, the solution I ended up with, and how I arrived at that decision. If I can’t explain it well enough, then chances are it wasn’t the right solution, and I may have to go back to the drawing board. I also hope to gain feedback through my posts of others’ experiences, whether I’ve helped them with my solution, or whether I’ve shown them what not to do and they can correct my flaws. So each post will be a learning experience, in one shape or another.
I’d like to make some connections through blogging, and to build some long-lasting friendships and/or business relationships. Please check out my about page to see if we have similar interests, and drop me a line if you’d like. Thanks!