Tag: interviewing

Doing the Same Thing Over and Over Again and Expecting Different Results

Posted on by Rob Larsen

Here I am taking a shot at shorter form writing. Watch me write!

The biggest job/career related error I made this past year was going against my own policy and talking to a company I had a bad feeling about from the beginning. I’ve actually known about this company for a long time and think poorly of them. The thing is, a recruiter came along and told me how much they were paying for a high profile role they were trying to source. That number was higher than the honestly very high number I have in my head to go work for someone else at this point. So, against my better judgment and against my own stated policy of not talking to people unless I’m sure the company will be a good fit, I talked to them.

I’m a dumb-ass.

The one part of the conversation that sticks with me is the “big” question in the interview. Apparently, they’ve got a lot of separate development teams who have worked in multiple versions of Angular on different components that have to play nice together on the same page. As you can imagine that has caused problems. Apparently, they’re also kicking off some development using React. With that cluster in mind, they asked, how would I help solve the issues they were having with all these interoperability concerns at an architectural level.

My answer was simple. I said, “Stop doing that. Don’t use React and standardize on one Angular version.”

I could hear the frustration in the interviewer’s voice as he said, “that’s not really an option” as if pointing out the obvious solution to their self-inflicted problem was an insult to him personally. I could tell he wanted to hear some hair-brained technical solution (“I know we’ll write REACTANGULAR and it will normalize across all Angular versions”) that would rescue them from a disaster of their own making, without having to do hard work. He lead me down that path a little with some follow-up questions. The thing is, that’s precisely the kind of bullshit is never going to come out of my mouth. I wasn’t going to blow smoke up his ass just so that he can ignore the obvious solution. To me, when you’re doing something so fundamentally wrong, the best solution is to bite the bullet and do something fundamentally right to counteract it.

How they thought introducing an entire second library to the mix was a good idea is something that will forever confound me. They’ve already identified this as a problem and they’re willingly making it more complex. That’s insanity.

Suffice it to say, they didn’t like me for the role.

So many companies are obsessed with being on latest and greatest libraries and frameworks. If, like this company, you want to be a great engineering organization you should focus on doing great work. If you’re architecture is a patchwork monster it doesn’t matter if you’ve got the new and shiny. You’ve just got a new and shiny patchwork monster.

Palatino Consulting, One Year In

Posted on by Rob Larsen

While I’ve been consulting independently for slightly more than a year, I’ve been doing so under the Palatino Consulting banner for exactly one year, this week.

It’s been going pretty well, thanks for asking.

I’m at the point now where I’m starting to think about whether or not I want to expand this business to include more than just me. The opportunity is there (and has been since day one, to be honest), I’m just not sure if that’s the way I want to go. I like my simple life right now, but I do miss having a team to work with so I’m tempted to start to expand. Maybe, like the founding of the business itself, I’ll be forced into a decision one way or another by some circumstance. At least in this case it will be positive (some opportunity I can’t pass up) rather than negative (getting laid off.)

The one downside to the success is that I’ve had a hard time finding time to write . Which is fine on a lot of levels as I like what I’m doing and working for myself makes even the longest week a lot more satisfying. This is especially true because, unlike many people putting in 60 hour weeks, I get paid for every minute of my time.

Fireworks
Fireworks by Flickr user maf04

Still, I’d like to share more here as a lot of what I talk about in the book is still going strong, but I’ve found it hard to get into the flow of writing again after 3 or so years writing books back-to-back. We’ll see how it goes. I may try to take some baby steps with short pieces and see if the habit sticks.

If not, remember- I’ve still got the web’s back.

Notes from the Interview Front

Posted on by Rob Larsen

Interrogation Room #5

Sadly, I won’t be sharing a bunch of funny anecdotes from my time on the interview trail. While that might be fun, there are some bigger trends that I wanted to talk about after having reviewed dozens of job descriptions and talking to dozens of people at one level or another over the month of March.

AngularJS is the new boss

At least in terms of green field development it seems like no one is talking about anything other than AngularJS right now. My year and a half’s worth of Angular experience set off alarm bells for many recruiters. Backbone comes up, but not with as much frequency. Several people were moving from Backbone to Angular. Nothing else in the MV* space was really in the running.

Lots of smart people (including many that I know) are still pouring a lot of time and effort into Backbone, so it’s clearly not going anywhere. It is weird, however, as Angular seems to be winning developer mind share no matter what the regular front end engineering taste-makers might think about it. I’ve had a lot of conversations with people (including some big names) where they’re completely flabbergasted that anyone is even using Angular, forget about the fact that it’s storming the castle.

It’s definitely storming the castle.

In the course of writing this post, I saw a bell clear sign of Angular’s rise. I saw an “Angular expert” job posting from a company who had spent a ridiculous amount of time and money (hundreds of thousands of dollars worth of developer hours) crafting a “perfect” Backbone based application development stack. I’m sure they’re still quite fond of Backbone, but it was interesting to see them hedging their bets, trying to get some Angular expertise on staff.

Start-ups are spreading like wildfire.

The Boston start-up scene is pretty nuts. I’m not generally interested in start-ups, but as part of my “talking to everyone” thing I ended up talking to a few of them. I remain mostly uninterested from a full-time perspective, although I did get up to the brink with one group that seemed pretty cool.

There is a lot of opportunity out there for someone like me to help them out on a short-term basis, however, so in my new life as an indie consultant, I might go back into the fray.

Start-up Geography

At this point start-ups are no longer crowding around South Station. They’re in South Boston proper. It’s a walk to get over there these days.

Bocoup might be leading a smart charge over to North Station.

Agency vs. Startup/Product

When I interview at agencies I don’t do tech screens. No one has asked me to do anything like that in 4 years. The shared experience of the agency existence and the number of people I usually have in common with agency folks means that the “tech” portion of interviews usually doesn’t go beyond philosophy and general experience. For most agency people knowing the level I’ve been at the places I’ve worked is a pretty good indicator that I know what I’m doing.

Product people, on the other hand, are super wary of my experience. They seem to think that because I’ve been a manager and been in charge of teams that I don’t know how to code. Some of them have even made the assumption that I don’t want to code (yes, I do open source software to torture myself.)

Interviewer: “So you’ve been a manager, running teams for a while. You haven’t really been coding since 2007 then?”

Rob: “No, unless today is opposite day. I’ve worked on probably 20 sites or applications in that time. Some with thousands of lines of JavaScript and incredibly complex UIs.”

Let me set the record straight on that assumption. Being an engineering manager at some companies might include no coding/all meetings, but at an agency the pendulum usually swings way too far in the other direction.

A technology manager at an agency will probably be doing coding/architecture most of the time and will not have any time officially allotted to do anything strategic or to work with their team on anything other than project work. .

Even if their target allocation is something like 60% billable work, they will probably be fully allocated to client work. Occasionally, they will be over-allocated to a client (or two.) Oftentimes, soft-skills “manager stuff” happens in hours 40 and above (or 80 and above.)

Personally, at one point a couple of years ago I was allocated 100% to two separate divisions at the same investment bank for six weeks. Not a lot of time to get soft when you’re scheduled to work 80 hours a week 🙂

This is actually a systemic problem at agencies. There’s not a lot of room for people at even the director level and above to really nurture staff. There are exceptions, of course. If you look around and spot stable teams at different agencies you can usually spot a guy or gal at the top who makes a point of keeping their staff happy, but the pressure to do that is not coming from up on high. The pressure from up on high is to keep your billable rate as high as you possibly can in order to justify your continued presence at the agency.

To that end, senior people at agencies are constantly getting their hands dirty. No one is hiding. I know start-up people think their experience is special, and in a lot of ways it is, but the experience on the agency side isn’t any easier.

To be perfectly honest, looking at someone from an agency with a good engineering culture and thinking they’re going to be soft is insane. That person has probably built up and torn down more architectures than most people do in a career in the product world.

There is a reverse bias

Agency people don’t want to hire people who don’t have agency experience. This is undeniably true. There’s a fear that you will hire someone, they will walk in the door, see the maelstrom and walk back out the door.

That happens, so it’s a valid concern, even if I don’t put as much weight into it as some people do. For my money, I’d rather have people get the shot and fill the role than play gatekeeper just because someone is coming from another industry. Sometimes it turns out really well.

Front-end engineering isn’t, universally, a first class discipline (although it’s getting closer to being one)

Something similar to the following happened twice when interviewing for very senior architect positions (including one that was titled something like “Front End Architect.”)

Hiring manager: “We want an architect whose focus is on the front end. You’ll lead projects, working with other developers and vendors, but we really want someone who can make a difference with the user interface layer. We see it as a game changer for us. ”

Me: “Sure, great. I’d love to come in”

Rob interviews

Feedback: “Rob was really strong on the front end, but he wasn’t as strong as we want him to be with Java/C#”

(So you actually want a Java guy? You want a Java guy who’s also an expert with JavaScript? Does such an unholy chimera even exist? )

The thing that drives me crazy about this scenario (beyond the fact that it’s a waste of my time) is that I’ve worked with architects who knew so little about JavaScript that they didn’t know enough to leave the JavaScript alone. I’ve seen very smart people completely break the UI because they were completely clueless about JS and didn’t even realize the depth of their cluelessness.

Up until they start breaking things, I’m cool with this. As long as folks delegate I don’t want or expect someone to be an expert across the whole system or to be able to code the whole system. I wouldn’t trust many of the absolute geniuses I’ve worked with to code the front end of any system. Just like they wouldn’t trust me to code up the services layer or come up with a database schema. But yet, in many organizations, you are simply not allowed to be in charge if you don’t have significant back-end experience. It doesn’t matter that the heavy lifting is happening in the browser now. It doesn’t matter that the potential advantage is in the user interface because there’s still an incredible shortage of strong front end engineers. It doesn’t matter than getting people to be effective at their jobs is a skill that stretches across technology domains. If you’re not a Java or C# expert, in some places at least, you still can’t straddle domains and run the show.

It is getting better

The good news is, the previous used to be universal. It’s no longer. I did interview for two general technology leadership roles (Director/VP) and those were judged on their own merits. No one once gave me the stink eye because I’m not a reformed Java developer.

Random notes

The Interrogation

  • I don’t like people who do tech screens like it’s an affront to their honor that you would even think you are good enough to work at their company. This doesn’t happen too often, but it does happen and I fill up with quiet rage pretty quickly when I encounter one of these people. When I run tech screens, I want to fill the role. I’m not happy when people aren’t up to snuff. I’m truly disappointed. It seems to me like these people would be happier to keep the role unfilled. That’s the absolute wrong way to approach the interview process. My reaction is invariably: “You don’t want me here? Cool, I won’t work here.”
  • I’ve been contacted by 28 separate recruiters in six weeks for various jobs at one company. I want to opt-out permanently please? I wish there was a central registry to opt out of contact by company.

  • I’ve got a hint for people who have been trying to fill roles for a six months or a year and can’t find anyone. Pay more money. Instead of losing out on some opportunity waiting to get someone at a 50th percentile wage and fitting it into some budget, push the pay envelope by 10% or more and people will be a lot more receptive. There are very few job descriptions I’ve seen in the Boston area, at any level, that had an aggressive (for the level) salary attached. There are some, but not many (maybe 10%.) Everyone else seems to think that being able to use new technology and getting free soda and coffee should be enough of a selling point to get you to choose them in the middle of one of the hottest skill sectors in the job market. The salaries seem to slot into very clear strata and there are few outliers. I know people are afraid because money is money and front-end developers should be worth $xxx. But if you have a need now, paying aggressively is one way to fill it that’s within your control. Everything else is outside of your control. Pay more than your competitors. Everyone is using Angular or other modern architecture. Everyone gives out free snacks and coffee and all that crap. You can’t win with that stuff.

And that’s it for now. I may add onto this as other trends percolate around in my brain. For the most part I enjoyed the conversations I had even if nothing turned out to be a perfect fit for me and I hope that people on the other side of the desk felt the same.

My New Job

Posted on by Rob Larsen

I’m late with this post. I’ve been busy! Finishing this post has been tougher than I imagined it would be.

Starting a new job is tough enough, adding in two visits to New York, one to Toronto and getting ready for HTML5 Live have made it even tougher. I think I’m through the toughest part of the transition now, so here I am, writing like a madman.

Anyway, I promised to talk a little bit about my new job. I won’t go into exhaustive detail, but I know some of you are interested, so I might as well get it out of the way now, before it doesn’t feel like a “new” job any more.

As I mentioned previously, I’ve moved over to Sapient Global Markets. My title is Senior Specialist, Platform.

As for what I’m doing, my job splits into three basic components- thought leadership, building a world class front end engineering team and bringing cutting edge solutions to clients.

  • Thought leadership. I’m not a huge fan of the phrase, but “writing and talking about emerging technology” doesn’t fit as well in a job description. I’ve already been doing this as much as possible. The difference with my new role is that it’s written into my job description and mandated from up on high. So, now I’ve got scheduled time for the kind of activities (writing, speaking, open source work) that I previously had to fit in around client engagements (which rarely happened) or after hours in my “free” time. Hopefully you guys will get some benefit out of me being able to write a little bit more.
  • Building a team. I’ve been instrumental in hiring and have worked developing junior staff for a few years now, so I’m pretty comfortable with this aspect of the job. The two key differences here are that I’m basically starting from scratch at my new role and I’ll be looking to build a truly global team. I’m not 100% sure what the eventually distribution will be, but I’ll be filling out slots between Boston, India and potentially a couple of other spots around the world. Making sure a team with that sort of geographical spread feel like a “team” will present a new wrinkle.

    Another clear challenge is cultivating front end engineering talent in India. Traditionally, people doing front end work there are junior and are doing so as a steppingstone on their way to writing “real” code- C# or Java. The combination of looking ahead to getting to do “real” work and the limited experience these guys possess have conspired to make it tougher than it should be to staff front end engineers in India. Hopefully I can help to change that by getting young Indian engineers excited about the web as a platform and open standards in general.

    By the way, one of those roles is already open. We’re looking for a Senior Interactive Developer in Boston. Come work with me. It’ll be fun. Shoot me an email, if you’re interested.

  • Client Work. The interesting challenge at this job is that I’ll be working with clients who are much more conservative than some of the organizations I’ve worked with previously. Educating some of the financial services giants on the power of the open web platform and delivering work that leverages those technologies in novel, but concrete ways will be an ongoing challenge. The good news is many of the cooler open web technologies are tailor-made for markets based businesses, so I’ll be selling them on Canvas, SVG, WebSockets, etc. Should be fun.

And that’s it. That’s the new gig. It’ll keep me busy for a while, I think.

On Interviewing Front End Engineers: Be Prepared (or at Least Pretend You Are.)

Posted on by Rob Larsen

On more than one occasion I’ve been interviewed by someone and they’ve told me, point blank, that they “didn’t prepare at all for this” or “didn’t even look at your resume.”

Really?

While this is lame no matter what industry or role, with front end engineers it’s incredibly frustrating.

Throughout the “Ajax era” any other experienced front end engineer has been interviewing from a relative position of strength. In my personal situation, I’ve been employed over the past five years by good companies, working with people I like and respect; but anyone with a strong background in HTML, CSS and (especially) JavaScript who is looking for a job is going to have several options available at any given time. That’s just the nature of the industry right now. We’re in an extremely fortunate place right now.

So… with that in mind it should be clear that if you’re hiring on the front end you have to actively recruit. This is just the reality of hiring front end engineers. Everyone wants someone great and there just aren’t that many great people around. If you find someone you’ve got to put forth some actual effort. I know all about this from both sides of the table. For example, we’ve had this role open at Isobar for ages and we haven’t found the right fit just yet.* There aren’t all that many people that fit those requirements.

So, what’s a candidate supposed to think when someone walks in and admits, in effect, that the candidate’s time and/or the role isn’t important enough to merit even minimum effort?

How is that recruiting?

It’s not, and speaking from experience, being on the other side of some of those comments it reflects poorly on the organization as a whole. People picked to screen and interview staff should recognize that it’s important for a team or organization. It should never be such a burden that they can’t even do the minimum, and in the rare occasions where it’s impossible to do proper set-up they have the common decency to pretend that they did so as to not insult the candidate. If the person you’ve picked to do interviews can’t do that minimum, it’s probably time to pull them out of the rotation.

Putting it simply: it’s hard hiring people that do what we do. You’ve got to take it seriously.

*Hopefully moving downtown will help us fill it (plus don’t you want to work closely with me? Wouldn’t that be awesome?)