- Schedule a codepad session for 10am on literally the next day after a 7-month road trip where 100% of your brain was focused on learning Spanish.
- Schedule a phone interview an hour later, so that you’re still rattled and trying to solve the problems from #1 in your head while talking to the hiring manager of another company.
- Schedule an onsite with the company you like the most *first*, w/o giving yourself much more time to brush up from the disaster in #1.
- Basically in so many words tell several startups who are trying to do microservices that based on your experience they probably shouldn’t be doing microservices.
- Convince another startup so thoroughly of the importance of DevOps that they decide to go with someone with more DevOps experience.
- Completely nail an onsite interview, then practically on your way out the door, tell the interviewer the only real drawback is the commute — thus leaving a bad taste in everyone’s mouth — George Carlin style. (I’m not gonna link that — either you get the reference or you don’t.)
- Before any of this, pull over and do a skype interview from a McDonald’s parking lot in Primm, Nevada — and another phone interview somewhere outside of Barstow.
You’d think these things would be obvious. But no, I am an experiential learner, which is a nice way of saying I need to learn things the hard way, which is a nice way of saying I am a very poor planner who likes to YOLO things that are way too important to YOLO, which is a nice way of saying I am an idiot, which is what this recursion always boils down to.
In high school, I got lost coming and going to the movie theater on a first date with the best-looking girl I had ever gone out with to that point (or many years after) — because I refused to look at a map or plan out where I was going. On the way back we wound up in some industrial bottoms area as deep fog set in, and of course she became terrified I was going to kill her. Needless to say there was no second date, and I’ve been terrified of first dates ever since.
This feels a little like that.
I’m pretty sure the company in #1 above is still having a good laugh about me. If so, at least I contributed that. They basically shooed me off the stage , Showtime at the Apollo-style. I couldn’t remember indexOf (yeah — don’t turn 40 kids). It just went downhill from there as my brain froze up on what was announced as the super-easy question, and we only have 30 minutes or so left so let’s see how many we can get through. There might as well have been the Jeopardy theme or a big ticking clock playing in the background.
Here’s the problem for anyone who’s interested:
I spent 10 minutes solving the wrong problem. Then I just kept getting syntax errors and going down wrong paths until they shooed me off. Of course I solved it 5 minutes after the interview, when my brain calmed down, and sent an email. I sent a better solution later that night. No replies. And of course I was still thinking about this during the “technical philosophy” interview with a different company mentioned in #2 above.
The concepts are all still there, but the command names, as well as the 100s of acronyms and names of previous projects, seem to be have been pushed out by Spanish words. I’m getting them back, but it trips me up when I’m in the middle of a sentence and I can’t remember the actual name of some tool or project I’m trying to talk intelligently about.
I just heard an old EDM remake of Rocket Man that I haven’t heard for 15 years and immediately said, “That’s Daphne Rubin-Vega”. I saw a picture of an old Camaro on my friend’s FB feed, and immediately knew it was a ’68 by the tail-lights. Nice prioritizing brain! I really needed to keep that information immediately available — over a Javascript command I’ve used approximately 100,000 times. Good song btw.
The subtext, the dark demon hanging out in the shadows causing this panic, is fear that maybe I am too old for this sh*t. I don’t think I am. Just a few years ago I picked up a brand new technology and set of tools, and ran with it to great success. But programming is a young person’s game. If the rest of the hiring world thinks I’m too old, then does that even matter? If I flub a whiteboard will everyone in the room think it’s because I’m older? Are they right? These are not good thoughts to have running through your head when trying to think creatively.
When I’m in a panic, or even not on top of my game, I can’t hear my inner voice. That inner voice which is absolutely essential to stuff like making a funny joke when you’re talking to a girl — or thinking of a creative way to solve a problem. It gets drowned out. I knew the answer to the Netflix interview I flubbed. I just couldn’t hear it above all the noise.
I remember looking at older devs when I first started. The first time they slip up or show any frustration — I’d immediately wonder if they can’t cut it anymore. Oh that’s just cranky old ex-COBOL programmer Bob, struggling with his IDE again. Although I do think the jump from command line development to modern multi-tool GUI development was a much bigger conceptual jump than anyone in my programming generation has had to deal with. Also I still look pretty young, and I’ve always been extremely immature for my age. So I have that going for me.
The bottom line is I’m 99.9% sure I can code as well as I used to, even if it might take me a bit longer to work through a tricky problem. Programming has never been about speed, or you’re doing it very wrong imo. Experience not to go down wrong paths should more than make up for maybe being a tiny bit slower to work through things.
But fitting in with the team is important. A diverse team with people varying ages and life experiences, like the one I worked with for the last 7 years, can easily handle someone in their 40s. On a team where everyone is under 28 and has a recent CS degree, it might be more of a challenge. That’s fair. And of course you’ll never know if that’s the real reason, for obvious lawsuit implications. So the fear is you wind up chasing your tail based on the stated reason(s) you didn’t get the job(s).
Ah well, I’m catching up now by re-watching every FunFunFunction video:
One interview flub after another is being addressed in these videos, and I’m realizing ARGH — I know that. I just needed some prodding to pull it up from the murky depths so I can speak intelligently about it.
I’ve also had some painful revelations about my career arc and continuing to pursue knowledge in my area of expertise. As Mattias (my Javascript hero above) implores at the end of every episode, “Stay curious.”
But first let’s talk about the trigger for these revelations — the modern tech interview. It’s been 8 years since I’ve seriously looked for a job, and things seem to have evolved big time.
All the previous job interviews I’ve ever been on had maybe 1 or 2 whiteboard type questions — mostly just to make sure you weren’t trying to pull some Catch Me If You Can situation on them. Your resume and how well you could talk about the technology seemed to be good enough — which actually is less fair to developers who aren’t blessed with the gift of gab. I’ve known many of those in my day.
Until this job search and one I did a few years ago when I was considering a new job, I had never been face to face on a programming interview and not gotten the job — even jobs I wasn’t remotely qualified for. I don’t want to say I was cocky going into interviews, but here is some actual footage of me walking into the room:
But hoo boy are things different now. Karma could very well be paying me back.
At the beginning of my search an old colleague who works for a FAANG (Facebook, Apple, Amazon, Netflix, Google) reached out to me — did I want to interview? Sure why not. Ok here’s a 1000 word syllabus with links to 4 practice sites for you to start chewing on. Expect to spend about 2 months studying and do a few practice interviews at companies you don’t care about first.
Uhhhh…
Note: this person is one of the sharpest developers I’ve ever met, and a bonafide significant contributor to a major open-source project used by millions — yet still failed the first few interviews — until putting themself through this ad-hoc course.
Gulp.
Apparently some other accomplished developers are a little miffed about this situation:
There has been plenty else written about the craziness of the current tech hiring process, questioning whether or not it actually tests job skills:
… or some combination of “bar trivia” and abstract puzzle solving under pressure:
FWIW — I don’t agree this stuff is bar trivia. I think it’s important. Maybe not to your immediate job, but stuff you should definitely know if you want to be considered anywhere near top of your field. More on that below.
This hiring manager proposes a pair programming session, which I think I like a lot more than the current standard 3 hour grilling:
Maybe it’s a better model for some companies if more jobs were contract to hire and they can hire multiple developers at a time? So they could just take a flier on a few devs and hope one turns into a keeper. I’ve probably been that flier that turned into a keeper several times. Maybe a manager should just go with their gut more often even when a candidate doesn’t ace the whiteboards or check all the boxes?
I wonder if companies fear hiring a bad dev more than the actual damage a bad dev can do — at least at smaller companies where it’s easy to let someone go. The poker analogy is players who have a big hand but fear getting stacked by a monster hand, and thus fail to maximize value the 95% of the time they aren’t up against a monster. Or something like that.
This site offers a CS course for self-taught programmers:
Why learn computer science?
There are 2 types of software engineer: those who understand computer science well enough to do challenging, innovative work, and those who just get by because they’re familiar with a few high level tools.
Both call themselves software engineers, and both tend to earn similar salaries in their early careers. But Type 1 engineers grow in to more fulfilling and well-remunerated work over time, whether that’s valuable commercial work or breakthrough open-source projects, technical leadership or high-quality individual contributions.
Type 1 engineers find ways to learn computer science in depth, whether through conventional means or by relentlessly learning throughout their careers. Type 2 engineers typically stay at the surface, learning specific tools and technologies rather than their underlying foundations, only picking up new skills when the winds of technical fashion change.
Currently, the number of people entering the industry is rapidly increasing, while the number of CS grads is essentially static. This oversupply of Type 2 engineers is starting to reduce their employment opportunities and keep them out of the industry’s more fulfilling work. Whether you’re striving to become a Type 1 engineer or simply looking for more job security, learning computer science is the only reliable path.
I’m not 100% sure I agree with some of those assumptions, especially the bolded. I’d be interested to hear feedback on that from other people in the industry.
I wonder if this current interview evolution maybe is more of Type 1 Engineers self-selecting, and less checking what’s actually needed to do the job? Either way obviously it can’t hurt as a self-taught developer to invest some time and learn what CS grads know (or learned once).
Here’s another take from the pair programming-interview advocate above that most modern software development is just “plumbing”. IE — the kind of work that doesn’t really ever call for deep CS concepts. The McDonald’s skype interview I had was 100% plumbing/gluing together off-the-shelf stuff. I kinda like that as it’s purely focused on what works best to build the product, as opposed to what technology is likely to attract top talent.
Regardless of these arguments — I think most would agree that the modern tech interview is testing something that can show a developer’s ability, but also needs to be studied for, and maybe doesn’t test the skills needed to actually do the job. Maybe smaller companies should look to catch the engineers that fall through the cracks of the FAANGs’ demanding process, instead of try to emulate them?
<unhinged rant>
I swear if you just graduated from college and went on job interviews you would think that creative uses of call and apply, and deep discussions of class-based vs. prototype-based vs. functional vs. whatever other wonky types of inheritance— were the most important things you need to know to be a successful Javascript developer.
I got this one yesterday:
var length = 10;
function fn() {
console.log(this.length);
}var obj = {
length: 5,
method: function(fn) {
fn();
arguments[0]();
}
};obj.method(fn, 1); // what is the output?
Well first of all what environment is this code snippet being run in — because that affects global scope. And second of all — can we just console.log(this) and move on? That takes 100x less effort than trying to wrangle this in your head.
Also I think I found the source for most of my JS interview questions — shhh don’t tell anyone we know.
You know what I haven’t been asked about once? Node. “How many years have you been working with node?” is apparently all the proof needed for node expertise. I’ve had more AWS questions — and I don’t even have AWS on my resume (yet).
</sour grapes>
So that’s the trigger of my revelations — trial by whiteboard fire and fear of more to come. The worst is when you make it through 2 rounds without having to touch the whiteboard, then the last interviewer of the day comes in and starts erasing it, when your brain is already mushy from 2 hours of blibbety-blab. Dun dun DUNNNNNN.
Actually the codepad terrifies me even more, since you actually have to make it work, but it also doesn’t do stuff like highlight out of sync parenthesis or other linting. No one develops like that in 2018 — why do I have to do it in a timed test with maximum pressure? I lean on my linter like a drunk on a bar stool.
As far as deeply thinking about code — my particular situation is I’ve been a node dev for the last 5–6 years — in an environment where 99% of the time node is tapping its fingers waiting for back end services to return. Screaming performance hasn’t been my primary concern.
I’ve done plenty of performance debugging at a macro-level, like middleware timers, but haven’t needed anything at a micro/clever-algorithm level. For me, software architecture stuff like code clarity/guardrails, component scalability and scope flexibility have been pretty much all of my focus during that time.
Here’s specifically what I mean by the bolded techno-gobbledy-gook above, (feel free to skip this part if you aren’t a programmer):
Code clarity/guardrails — because we were working with offshore devs who might not be completely comfortable in closures or middleware, or async programming in general. My biggest concern was them getting into async hell or accidentally setting something in global scope. The latter is easy to do in node, and could easily slip through single-user testing into a multi-user production environment — where it would still be really really weird and hard to replicate to debug. This is what kept me up at night.
Now you might say “Well that’s a BS situation, get more experienced devs.” But that’s the world I lived in. So I made it work — by creating guardrails about where to put business logic, and abstracting away asynchronous behavior to the framework.
I do think there’s something to be said for the exercise of developing a framework that keeps devs out of trouble, while still allowing them 100% freedom to build the feature they’re trying to implement. However, the downside for the feature developers was that they don’t walk away feeling like they really learned node or asynchronous programming. Which bothered me.
The kitchen on a monster node app has room for a chef and maybe an apprentice or two. But everyone can’t be in there. Unfortunately that’s just the nature of the beast, er restaurant. Metaphor stack size exceeded.
Component scalability means that creating components 90–100 cause no more pain to the application than components 10–20. By the end we had some 200 components — which could be a full web page, a server-side rendered HTML snippet, or an AJAX call returning JSON.
To do this I purposely allowed some redundancy, in that each front-end component declared its own back end API calls and back end logic. If we saw the same gnarly API-processing business logic appear in more than one component, we’d just create a utility method. This goes against the standard paradigm of one layer for API services and another layer for front end route handlers (in a many to many relationship). But it worked perfectly for us.
As an aside I’m really not a fan of the multi-layered approach inside a node app. Every route should be its own component imo, with all the business logic easily accessible in that component. This makes it infinitely easier for front-end devs to quickly reason with what the code does, and not have to go digging all over the app into layers of abstraction they aren’t familiar with. With this paradigm you don’t really need a dedicated node dev other than the framework maintainer(s). Front end devs can feel comfortable creating and modifying their own node-side components.
I feel like I spent the first 10 years of my programming career trying to build the perfect abstraction, and the rest since then learning when to back off for the sake of code clarity and future flexibility. IMO nothing is worse to refactor than a big multi-layered abstraction that you suddenly realize doesn’t handle a new use case. I’ve been on projects like that. It’s much easier to develop a simple base with redundancy, then factor out obvious code reuse situations later. Note that a lot of the same concepts of component-driven development, also apply to microservices.
Scope flexibility just means that even with 100+ components, it’s still very simple to implement cross-cutting concerns. I was able to accomplish by driving all configuration from a default properties object, and adding global middleware hooks at every step of the request/response chain, as well as every step of the back end REST api calls chain (which are many to one vs. an individual http request). When a new global or semi-global behavior was needed, I would just add a new default property, then find the appropriate place(s) in the middleware chain to implement it. It put essentially zero risk on breaking existing components, was very simple for me to do, and very simple for other developers to pick up on.
Or since reporting always comes last, we can just snap on a piece of reporting middleware with hooks into the individual reporting components — all of which are superfluous to the actual feature code. Testing worked the same way. Middleware lends itself really nicely to this kind of scope creep imo, hierarchies often don’t.
<<< (end techno-jargon wonkiness) >>>
All of this stuff was planned ahead of time when I designed the framework — knowing our developer situation, the size the site would eventually grow to, and the chaotic nature by which our requirements tended to evolve and mushroom. More accurately, the framework was iterated it into existence over time, but the designed simply and flexible enough to allow that kind of iteration.
The point of all this long-windedness is to hopefully demonstrate that I have been thinking deeply about my job the last 5 years. Which is the good part.
The bad part is I’ve managed to do it without staying current in all the latest and greatest ES6 and beyond features, or even learning a lot of the past latest and greatest features. This boils down to a lack of curiosity plain and simple. I’ve been a Type 2 Engineer.
I just blew an interview with Netflix because I forgot about javascript generators, which I did actually learn about at one time. But I didn’t press through enough to get a deeper understanding. I’m not sure if I ever would have needed generators in my actual job, but if I had, I probably wouldn’t have through to use them. That’s a legitimate knock on me as a lead developer.
I was content to play with the tools I had, as long as I could make them work. I didn’t strive to keep up with possibly better, cleaner solutions or obtain a deeper understanding of the stuff I was using. Or just geek out about Javascript on a regular basis. I had become “The Javascript Guy” at my office and didn’t seek out forums and other sources of staying engaged with my peers. In the poker world we call these “leaks in your game”.
Well that’s not completely true. I did go to and speak at node conferences and meetups, and internal presentations, and I learned a lot creating and releasing my open-source libraries. Which by the way, when did github become completely uncool to use in the hiring process? I seem to have completely missed the “show us your github” train. It came… and went… while I was at the same job.
But I could have done much better.
I also missed a chance to learn more DevOps from the ground up on my side job. I was hired as the node guy, but was constantly kicked out of the kitchen by another dev who wanted to be the node guy, and has known the founder since junior high. IE — I ain’t winning that battle. I could have easily jumped over and become the DevOps guy. But the job environment was extremely dysfunctional, and I didn’t want the stress of fingers pointed at me when things didn’t work. Looking back I probably should have just gutted it out, weathered the sh**storm, and learned a ton in the process.
The lesson here is the next time I want to go on a long road trip w/o a job waiting, I better be 100% current on the latest and greatest job skills and my area of expertise. Whether through side projects or Udemy courses or engagement in stuff like local slack channels — I can never again lose my curiosity. Regardless of whether this stuff is really needed to be a productive developer in a particular job, I should have been doing it.
The good news is I will never forget generators, or the subjects of a bunch of other test questions again. I’ve actually learned a ton of useful stuff from several angles during this process. In the long run I’ll probably be happy I interviewed with so many companies, saw what was out there, what’s in demand, and how they go about hiring.
(I come from the future to say — if you enjoyed this, you can read the conclusion of my job search here.)
…
Wait, hold all that, the perfect job just came in. “Phil” at ZipRecruiter has been working hard for me and finally nailed it. asfasgasgagagagaagasga is right in my wheelhouse. I’m a shoo-in!
