Michael Sullivan

to get an idea of what you'll be learning, check out the "10 day mba".

also, read this link where Guy Kawasaki challenges the notion of the MBA. (he's not the only one doing so lately)

<post created in error>

Hello Sam, thanks for stopping by this week. Do you have any future book related proejcts in mind?

Normally I'll post my own thoughts on the matter, but in this case the wikipedia entries sufficiently explain the differences.

Programmer/ code-monkey
Software Developer
Web-Developer and Web-Development

Being unfamiliar with Eclipse could cause you to lose sight of the real goal: Java programming. I don't know when your interview is, but if you have even a few hours to get somewhat familiar with eclipse, do so. It's a free download - and widely used. Here is a 12 minute video that will get you familiar with the basics.

And here is where you can get Eclipse

Good luck!

May I ask you to define "make it big" in software? Is that to create an open-source project that is peer respected and widely used (like Apache commons)? Perhaps it's to make one well executed piece of software that people really enjoy using (instapaper anyone?) Maybe you just want to make a piece of software that is so popular, that it's purchased for a handsome price by some other company (like tweetie, purchased by twitter).

Instead of giving you an answer, I'll simply share my story (and early goals) with you. I wanted to get into software development (specifically, web-development) before I had any experience. While taking the necessary courses - I began designing websites for realtors. Even though I was freelancing, I had completed projects on the Internet before I ever worked professionally. Don't let not having a full-time gig (or the gig you want) stop you from getting experience.

When I entered professional IT, I had two goals: To become a webmaster, and to work for a large company like Sun, Lucent, Avaya, etc. My first gig was a short-term contract as a front-end developer. Immediately after, I was lucky enough to find a job as.... a webmaster. Woohooo! Wait... what? That wasn't supposed to happen yet?! While I worked at that job for the next few years - I watched my title morph into programmer/programmer-analyst/developer/etc. And those big companies I once envied? They were busy restructuring, re-organizing, and reducing staff year after year.

The moral of my story was: I'd better be agile with my master-plan!

The interesting thing is that my "master-plan" became much simpler after those experiences. It no longer references companies, job-titles, or contains words like: Java, ESB, EJB, Cloud, or Enterprise. Today it looks like this:

Build the right software. Make it usable, test-able, and get it in front of someone who will use it - pronto.


Anyhow, good luck to you as you start out. It may not seem like it now, but you have lots of control over your career path.

Instead of asking purely hypothetical questions (tell me about a time where...) you'd instead assess the candidate in the context of software development. Consider the following:

Scenario 1: code review
Myself and another interviewer act as junior and senior level developers. The candidate is our peer, performing a code review of a feature that we have built. The coding is poor, and there are design issues.

What I'm looking for: Can the candidate find the issues we think they should spot? How does the candidate approach giving us feedback on this code? Does the candidate's approach differ as he talks to a junior vs senior developer? How does the candidate react if we challenge specific assessments? Does the candidate allow us to "talk our way out" of things?


Scenario 2: design review
Myself and another interviewer act as senior level developers. The candidate is our peer, performing a design review of a proposed project. While the design is simple, it solves all the necessary business and technical cases. However, I play the role of technical-bully - insisting that we need to turn the design into an SOA solution residing on an ESB. We need services! We need transaction support! We need BPEL! I interrupt a lot, I fail to listen, and I generally denounce the current design as having poor scalability, performance, and not being enterprise-y enough.

What I'm looking for: How does the candidate handle a bully? How do they handle the loudest voice, with the weakest argument? Can they keep their composure under stress? Do they attack the person, or the problem? Do they hold their ground or back down?


Anyway, I think you get the idea. There are plenty of "in-context" ways to assess non-technical skills.

How about when someone accepts acclaim for work, clearly done by one someone else, as their own?
How about twisting statistics to fabricate project success in a less than truthful manner?
How about under-reporting the number of hours you spent on a deliverable?
How about passive-aggressively undermining a project/person/strategy because it conflicts with your own?

I've witnessed these practices even in the best of organizations. While ruthless may be too harsh a word, I view them all immoral if done pre-meditatively.

That said, I'm as perpelexed as Henry as to why someone would pose this question (unless I've misunderstood the premise).

A similar question was asked here...

in that thread I also point to some crossover frameworks that allow you to target multiple mobile devices without writing native code (by using web-development instead).

Games tend to be the biggest seller on the iPhone - which may not be the type if application that most are used to writing.

As far as my interviewee recommendations - those were handed down from a recruiter friend many, many moons ago - and have served me well.

In a decade of IT work - I've only changed jobs a few times, though I've interviewed a lot of potential candidates in each position I've held. During my undergraduate work - I even took a course on interviewing. That was a very humbling experience as I was cast as both interviewer and interviewee in front of a group of 25 (almost) strangers. There was even a point where we recorded ourselves in both situations, in order to review and adjust our strategies.

Even as my software-development experience grew, interviewing wasn't really comfortable until my technology-vocabulary caught up. These days, I really don't feel that a sit-down, in person, technical Q&A is the best way to gauge a software-developer. I'd rather have a combination of: pseudo-code, code, refactoring, code-review, and test-case generation instead. If the candidate has open-source code for review, great.

I'm surprised that this hasn't been suggested previously - but it's common practice (for me at least).

1. I write down the first and last name of the interviewers, and ensure I have the mailing address to reach them (main office address is fine)
2. Upon finishing the interview, I ask the highest ranking person (manager or HR) this question: "If I don't hear back from you in a week, can I call?"
3. After I return home, I write thank-you cards and send to each of my interviewers. I try to include something specific in each. Post is better than email here.
4. If I haven't heard back in a week (or other agreed-upon timeframe) I call back and inquire.
5. I continue my job search.


If they say "we'll call you in a week" but do not, I assume that it's a no-go. Whatever I do, I don't sit and wait for a call. See #5.
YOU should set the terms of when you'll hear about the job. It shows that your about getting things done, including getting a job.

The ability to present your past accomplishments (via paper or interview) is a skill that can be improved. The details of projects are sometimes important, sometimes not. Let me give you an example:

Early in my career I was part of a web-dev team who built a very small website (both physically and functionally) targeted at blackberry handheld devices. This was way before iphone or android - so naturally many interviewers were perplexed.

The interesting thing is that most never asked HOW we did it (screen-scraping with Perl, persisted to M$-SqlServer, rendered as a Coldfusion web-app). They all wanted to know WHY.

And so instead of explaining the technical details of what, I explained the business problem we solved. The call-center managers who, "walk the floor" to manage customer service reps, needed to see the call volume and types of calls at all times. Since they carried blackberry phones that could access our internal website, a mini-webapp made perfect sense. Even in a year when mobile applications didn't really exist - my interviewers were able to understand the business value we provided.

Since that position, I've never written coldfusion, nor have I engaged in screen-scraping with Perl. Yet that item remains one of the most asked about by organizations and interviewers. Even in 2010, people are still curious about how we accomplished it "back in the day."

Make your past accomplishments interesting. Explain how your efforts are relevant. It's your job as a candidate to demonstrate how your past experience will enable you to succeed in a new position. (otherwise, why are you applying?)

Sam's reply in this thread seems like what you need...

oh, come now. The phrase "make a good living" is so subjective that it's difficult to support or defend. I met a person once who thought that $300k a year was the absolute minimum necessary to "make a good living". I've never approached that salary level, yet I feel very fortunate to "make a good living".

IT salaries in the USA, on the whole, are much higher than average - and certainly support cost-of-living increases year to year (especially for skilled developers).

The OP question was about making more money in IT, when they feel that salaries are decreasing. There are a few strategies for this:

1. Jump any "hot" trends (mobile, cloud, social-media, whatever) and be ready to switch often.
2. Exploit a niche market (cobol, mainframe, up-and-comers like no-sql)
3. Chase positions (lead, architect, senior architect, manager, director, VP, SVP, CTO)
4. Change jobs often (by choosing companies who'll pay you more)

Obviously, each one of these is flawed - but if your only goal is to increase your income, they are options. Maybe you'll be happy with the outcome, maybe not.

Would it make you less of a generalist if you add more general purpose languages to your skillset? I would consider a candidate who knows how to program in both Java and C# to be a multilingual generalist. I wouldn't even consider web-development a specialty as it's so wide and saturated with similar talent.

However - I know a guy who's great with Java, but he spends most of his time traveling around working on IBM WebSphere jsf portlets. He really knows the websphere portal stack, and since there aren't that many that use it - he's constantly in demand. He's what I'd consider a specialist in web-development.

IMHO, the important skill isn't knowing how to program, it's being able to produce with what you know.


CANDIDATE: I know Java, C#, JavaScript, HTML, CSS, SQL..... (goes on and on)
ME: yawn.

ANOTHER-CANDIDATE: I developed this web-app with Java web technologies and had to port it over to a C# implementation as part of project-x. The views were ajax heavy and required a lot of CSS and Javascript.
ME: Now we're getting somewhere.