Admittedly, I've been quiet lately...too quiet. That's because I'm taking the plunge and looking for work in the California Bay Area!
For me, a UI developer, the North Carolina Triangle Area, while a hotbed of awesome tech and startups, is still too data-centric. I don't mind data -- data is good, but I want great interaction and visualization to back it up. To be fair, I did tell someone my line of reasoning and they offered to hook me up with several places that offered that if I'd stay in town.
But our minds (my wife's and mine) are made up! I think I'm making the right decision. Looking on Meetup.com, I see 20 times the interesting meetups in the Bay Area than in the Triangle. Browsing Craigslist, I see 2 RTP area jobs per day in the internet engineering section, whereas in the Bay, I see 20 per day.
These are the things I justify the decision with, as right or as wrong as they may be.
So as a result, we are selling our house, moving (probably) to the Bay Area, and I'm finding a new job. As anyone in this nerve-racking situation would do, I jumped in immediately to search for jobs from afar -- and that's how I've come to learn the ways of Silicon Valley style job hunting. I think I finally have a decent feel for it, though I've done a lot of stumbling.
I'm of the opinion that my resume is fairly strong, so getting callbacks hasn't been a huge issue -- but they do take a while. Most have taken around 2 weeks for a response from the time of submitting online. Submitting online is a huge hassle but one you just put up with. You're subscribing to any number of recruitment sites to submit your resume and cover letter. Brassring.com comes to mind. Or if the company is big enough, they have their own internal submission tools. Either way you're entering in your information over and over and over again. Even when linking your profile with LinkedIn, you generally have to enter it somewhere else for each job.
Annoying, yes. End of the world, no.
The Recruiter #
Next you talk with a recruiter. I've actually enjoyed talking with the recruiters -- you get to brag a little, and it's their job to stroke your ego and reel you in. The bigger companies have whole recruiting departments. In one case, I was passed through 4 different people before I landed on the one that could help me out.
I think the only way you'll screw things up at this stage of the game is to start swearing profusely or making death threats. Of course, I've passed with flying colors -- making 0 death threats. I haven't even WANTED to drop the f-bomb; they have simply been pleasant people to talk with. When you pass this phase, it becomes their job to schedule a tech interview.
Prior to my first ever failed Silicon Valley style tech interview, which was with Google, I didn't know what I was getting into. The recruiter basically said, "You know the drill." I thought to myself, "Sure, I know the drill. We'll get technical and maybe throw in some questions to prove my domain knowledge." Nope, I was unprepared for this next world of hurt.
The Initial Tech Screen #
So, I had an appointment at a specific time. I was also passed a Google Doc link so the interviewer and I could share a screen and collaborate via code. That was new to me, but I rolled with it, unsure of what would happen.
Since I WAS unsure, I reached out to one of my wife's friends who worked at Google to learn what to expect. He told me to read the book Programming Interviews Exposed.
I picked it up on my Kindle -- but I was already at t-minus 2 days until my tech screen, so I skimmed. While I skimmed, I recognized that it was a pretty decent book, but I didn't think it was AT ALL applicable to my situation. After all, I was a UI programmer going for a Javascript role for god's sake. I thought that as long as I could express some domain knowledge and maybe explain what my jQuery was doing under the hood, I'd be set.
The book covered sorting, trees, binary trees, graphs, implementing linked lists, Big-O analysis, and more. I must say that I brushed it all off before my first interview. Those are concepts I really haven't discussed or seen since my college courses (13 years ago), and especially given the discussion on pointers in the linked lists and graphs, I really thought I'd be more preparing for a C++ interview with this book....not a Javascript/HTML one!
I was wrong, so wrong. Try giving a friend or loved one a call RIGHT NOW and explain how to do a breadth-first search on the phone without first refreshing your memory. It didn't work for me. BIG FAIL for me in fact. In fact, the breadth-first search problem is a great example of what to expect on a couple different levels.
For me, being asked that proved that not all code you'll be writing in the interview has a sexy, elegant solution when you're on the phone with your interviewer. For those that don't know breadth-first search, you're basically taking a tree like an XML file or any other nested structure. Instead of searching the root, then the child, then the child of the child, you're searching the root, then all the 2nd level, then all the 3rd level. The solution here is to push all the child nodes into a stack and shift off the first one with the important thing being that you need a list/array to store things in memory.
I didn't even want to go there for that question and other questions in the interview. I thought there had to be some easy, recursive solution that spanned like 3 lines of code. Why would they ask something overly complicated and unelegant over the phone?
Well, they do. They want to see error checking. They want to see the solution as messy as it may be.
In the end, that book proved to be the perfect preparation guide, which I was able to absorb for my subsequent interviews.
One other thing this book teaches is that it's OK to stumble if you don't know the solution to a problem that the interviewer asks. It's necessary to just keep talking to them. Don't choke, just keep talking. Tell them why you are going down a path to solve the problem and what you are thinking on the fly. If you don't solve it, they may give you some hints. Even if you think you fail at solving the problems, they may be impressed with your problem-solving process and still continue on to the next round of interviews.
My first interview with Google? I did NONE of that. And you know what else? I never got called back. After that bomb of an interview, I was able to have some really good ones based on what I learned.
The Domain Knowledge Interview #
After all that, I've had some good interviews -- but my best ones have been when the interviewer asked for domain knowledge. You know, that interview where it's not like an interview, but you just nerd out and talk about what you do at your job and what you like or dislike. Those are the ones that have made me feel like a real person, not a piece of meat, and it's shown.
Even my Google interview might not have been my worst. That was probably the one when the interviewer was a guy less than 1 year out of college. I don't say his age to be dismissive. I have no doubt he is very smart, but he didn't have much experience giving a tech interview -- which meant he picked random problems out of a data structures and algorithms book. But I kept talking and giving him my thought process, despite getting every question potentially wrong. To my surprise, I got a callback for a second interview after that debacle, which was more of a tech conversation that went quite well.
Next Up: The On-Site Interview #
Right now, I have a few on-site interviews lined up. The kind where you get flown out like royalty and put up in a hotel room. My initial reaction to getting asked out for them was that they must really be formalities, and if a company drops that kind of money on me, it's mostly a sure bet I'll need to screw up pretty bad to get rejected. But given how wrong I was before, I'm not taking any chances! Prepare for the worst is what I'll do!
HTML/Javascript is Weird to Interview for #
As a final thought, I want to talk about how weird it is going for a front-end job these days that focuses on HTML/CSS/Javascript. Even the domain knowledge interview is a disaster. There is little chance you'll talk about the same frameworks in most of the interviews given there are so many popular ones (especially MVC style). To top that off, you really do feel like an idiot if they ask native Javascript questions. No, I am not a jQuery scripter that copies and pastes. However, because I use jQuery a lot, I sometimes forget the exact native Javascript syntax . See the problem? To prove you're a bad-ass Javascripter, you must recite things you never use in your day-to-day life.
I also got a rather nice interviewer once who unfortunately didn't really know a thing about Javascript/UI. I ended up switching gears to talk about Java and back-end stuff. Front-enders are in demand, and as a result, you might be interviewed by someone sorely needing a front-ender...to the point where they have none to interview you properly!