I’ve been on countless interviews, and I’ve learned a few things along the way. I don’t consider myself an expert by any means, but I’ve learned how to interview well. It took a while to figure it out, but I’ve learned that interviewing isn’t difficult. On the contrary, if you are focused and willing to view the process as a potentially fun learning experience, interviews can be great experiences.
I was astonished to read this article on CNBC: Managers to Millenials: Job Interview No Time to Text:
Human resource professionals say they’ve seen recent college grads text or take calls in interviews, dress inappropriately, use slang or overly casual language, and exhibit other oddball behavior.
“It’s behavior that may be completely appropriate outside the interview,” says Jaime Fall, vice president of the HR Policy Association. “The interview is still a traditional environment.”
Oh my! If you are texting or taking a phone call during a job interview, you have MUCH to learn. My hope is that such an occurrence is rare. Having been on both sides of the interview table, if I saw someone read a text message I would probably inquire as to the reason. I’ve never had this happen. Perhaps there is a family emergency.
I once went into a job interview very near my wife’s due date. I explained up front that my wife and I had an agreement: If my phone buzzes twice in a row and it is her, I have to take it. “My wife is going into labor,” is a perfectly fine reason to take a call in an interview. I can think of a few other reasons that necessitate taking a call or text during an interview, but only a few. (My wife, thankfully, did not go into labor during that interview. And yes, I did get the job.)
I love interviewing. I mean it: I enjoy going on a job interview! That sounds strange to some, I know. I look at it this way: Either I’ll get a job offer or I won’t. In either case, I am meeting new people and making contacts–and, whatever the outcome, I am becoming a better interviewee. As a child I was a very shy kid–scared to death of talking to people. Perhaps I’m making up for lost time, but talking to people–getting to know new people–is fun.
So here is my list of tips: Read the rest of this entry »
Like all software engineers that I’ve ever met, I have a few other interests. One of those is writing (although I argue that the ability to write, and to do so well is an important skill in the life of a software developer).
My favorite book about writing fiction is Stephen King’s On Writing. He’s the modern master–even his critics must admit as much–And this book is full of great advice.
Of course, The Elements of Style is ABSOLUTELY required. This book should be on the desk of anyone who writes.
Just last night I discovered a fantastic book on Amazon, and I purchased it because of the negative reviews. It had many 5-star reviews, of course, but a good many 1-star reviews decried the author as filthy and crude. I was sold!
The book: 250 Things You Should Know About Writing, by Chuck Wendig. AT 99 cents on the Kindle, it was well worth it. I read most of it in one sitting, and will read it again.
During nearly ever job interview I’ve ever had, on the phone or face-to-face, I’ve been asked some form of the question, “How do you keep your experience current?”
Sometimes (emphasis on sometimes) this is asked by someone who seems impressed that I have such knowledge on a fair amount of “new stuff.” More often this is a genuine question (and a very good one) asked of an interviewee in an effort to gauge the type of software engineer that this candidate may be. Does this candidate have a desire to keep current with emerging trends? In many ways this is a unique necessity in the world of software engineering as a career.
Software engineering is a discipline that requires a real love of the work. Its not something that anyone hoping to find easy employment stability along with a solid paycheck should pursue (warning to those considering Computer Science).
So the question remains: How do you “keep current?”
No matter how much I love software, the fact remains that I have a life outside of work: family, friends, hobbies… Its not easy, but its necessary. One guy suggests learning a language every year. I like to pick up books that look interesting, read Stack Overflow and listen to podcasts. Woe to the “software engineer” who wishes to dismiss all emerging technologies as gimmicks or buzzwords… Such engineers will quickly find themselves (if lucky) performing maintenance work on antiquated legacy code. As long as software is something of a hobby, something that is personally rewarding, all of the above should be easy enough.
While all of the above is good, and its even better to have a pet project, I have found that nothing compares to working around extremely intelligent people for a company that is serious about software.
The Peter Principle says, basically, that people are promoted until reaching a level of incompetence. I think the reverse of this can be true as well: An employee may not be promoted because he or she performs very well in a given role.
This is just me talking, but I think there are a few problems with the way we view employment hierarchies in the software engineering world:
- Managers never knew software development
- Managers who used to know software development have been away from it for so long that they no longer know it
- Developers don’t know management
- There is no clear promotional path for the motivated software engineer
I’ve known a number of software developers who have either turned down promotion or given up a management role because they preferred software development. I suspect then, that the people left to do software management are either people who didn’t like software development or were not very good at it. This isn’t to say that they aren’t great managers (they may be), but it does lead to the possibility that the people in charge of software decisions may not be the best equipped to make those decisions.
Managers Never Knew Software Development
These days many large companies like to assign a PMP to a software project. This is an individual whose job is only to “manage a project.” The individual contributors of the team (software developers, testers, writers, etc.) don’t actually report to this person. The project manager’s role is specifically to work on timelines, track progress and ask the people who are working diligently to report their status (presumably for input into the timelies). If the company doesn’t have a dedicated project manager, this set of tasks falls onto the shoulders of some other manager.
What ultimately happens is that a lead developer will be tapped for all this information anyway, since the project manager, who doesn’t know software development and isn’t writing software, isn’t equipped to provide a meaningful level of detail in this regard. Interrupting a software engineer to ask his “status.” achieves nothing that a good project plan and appropriately used ticketing and version control system cannot.
That said, a good project manager is an individual who knows and understands software development and can provide project status details to upper management without constantly interrupting a team. I’ll take it a step further: I don’t think there is ever a need to have a project manager on a team who isn’t in some way directly contributing to team goals. This doesn’t mean that the project manager must also be a software engineer, but the project manager should be a product contributor. Creating timelines, scheduling meetings and asking people, “When will you be done with that?” is not a full time job!
Yes, we may need a “project manager,” but only if the amount of work is so significant that project management activities are warranted. A better model, in my mind, is to have the group manager, that person who is responsible for the project, have a working team lead for each subgroup. In many cases I think a single team lead of all activities (software, QA, documentation) can suffice.
Managers Who USED TO Know Software Development
Here’s something that annoys me to no end: For a software engineer to take his or her career to the next level, moving into management, seems to require giving up on ever actually engineering software again (at least in the workplace). Ironically, the very people who are required to be hands-off are also expected to make major decisions about software, while their software expertise dwindles. Software engineering is a unique discipline in this regard. As a friend of mine recently put it, it is one of the few careers in which those of us involved with it essentially learn all new stuff every 5 year years.
I find this strange because, in my experience, there very best software leader is not the MBA or the person who has never been a software engineer, rather, it is someone who is STILL a software engineer; Its someone who knows what is going on in the world of Ruby, Rails, Grails, Hibernate, Spring, JQuery, Clojure, , Git, Maven, etc. because he/she is someone who uses such things regularly. The manager whose most recent software engineering experience is a string as a Cobol developer on an AS400 years ago isn’t very well equipped to make assumptions about the effort involded with a web application, for example. 20 years from now I don’t want to be telling some junior developer how easy a project should be because “I wrote the same thing in Java in 2 days back in 2010.”
No Clear Career Path
What I’m getting at is this: A software engineer NOT have to give up writing software in order to move into management (even beyond the lead engineer role). On the contrary–I think it would be better if software management, from director on down, included actual software engineering.
This is a somewhat old article (2006), but it eludes to something that I have found a bit bothersome about attitudes regarding software engineering career paths.
I recently interviewed for a Business Analyst position with the CIO of a large multi-national software development firm. This man was in charge of the company’s worldwide IT operations, including offshore development projects, for which he was searching for qualified Business Analysts. The interview quickly became a casual conversation about current trends within the IT service sector, how the company was planning to take advantage of those trends, and, most importantly, how I could fit into those plans. It was during his evaluation of my skills that I asked how I fit and whether it was technical or business skills that were most valuable to his projects. The CIO summed up his advice about my career path with one small sentence: “Stay on the business side.”
The author goes on to state:
My job searches have suggested that business and systems analysts with a good programming background and a high-level of “business savvy” are becoming the next hot ticket. More and more organizations are finally hiring business analysts to explore, record, and recommend systems that fit the business—as opposed to the other way around.
While I agree with what the author is trying to say here, I think he missed the point. And the CIO quoted above is severely mistaken… Sure, you can train anyone to “be technical” and write a program, but you cannot train those people to do it well. There is a
big huge critical difference between a software developer and a good software developer. I first observed this in college, when some of my classmates loved working on programming assignments and performed very well on such things, while others fumbled through the simplest assignments, unable to get their code to compile, much less work.
Why were such people majoring in computer science? I’m not sure, but its probably because they thought they liked computers and would therefor like programming, or maybe because they heard it would make for a good career.
I don’t mean to pat myself on the back, but I (like many others in my field) didn’t realize that software engineering may be a good career until I was well into my Computer Science major. I started writing simple programs in the 6th grade, going to the library and checking out every single computer and computer programming book I could find. Later, after I had read all of the books that the small local public library had on the subject, I discovered Nibble magazine (also available at the library). Every good/great programmer I know is someone who landed in the career because it was something that he was drawn to naturally, and most of these people began at a young age. These are the people who write software because they like it, and this is why they are good at it.
Anyway, at one point, after being frustrated that my library didn’t have any more computer programming books to read, I found a strangely titled book that had been misplaced next to a book about Applesoft BASIC: The Peter Principle. I checked it out, if only because I thought the title was funny, and I took it home and read it–all of it! I was probably the only 7th grader in the world to ever read the book, which by that time was already very dated. The closest I had ever come to the corporate world by that point in my life was delivering newspapers. I was a fairly competent paperboy, and even if I wasn’t, failing as a paperboy doesn’t lend itself to a very clear path of promotion. That said, the wisdom of The Peter Principle was lost on me.
Little did I know that years later this strange book would be remembered much more vividly than the Applesoft BASIC book that I had checked out dozes of times.
The CIO, probably much older, wiser and richer than me, missed something major: Anyone can write code, but do you want just anyone making important technical decisions that can make or break your project, department or company? I didn’t think so either. Not just anyone can write good code. I’ve seen the results of software written by cheap labor… Indeed, I’ve rewritten code written by cheap labor!
I think there is a very obvious career path for software developers, and it doesn’t necessarily involve moving into a role that no longer includes hands-on software development. I disagree that upper management doesn’t realize this. I think in many organizations they do. I intend to write more on this subject…
I recently decided to start a personal Wiki. I decided to do this, partially, not only because wanted to mess around with Github, but more importantly, because I often find myself spending a lot of time figuring things out only to forgot the issue a year later when having the same problem.
I highly recommend the use of a Wiki (Trac, Redmine, Github, etc.) for any software team. I’ve found them to be excellent tools of collaboration. My personal Wiki, so far, is pretty small. I’ve only been using it for a month or so. Even so, I’ve already referred to it a number of times. I wish I had been maintaining a personal development wiki throughout my career!