A Sr. SW Engineer Has Been Interviewing for Six Weeks Now - Here Are His Thoughts on the Experience
The vast majority of my posts are my own observations about the market and how that impacts the careers of software engineers. On the very occasional basis, however, I get members of the community who reach out to me and ask if their words can be published in my blog. This particular post is another example of that.
I think very highly of this gentleman and he has some very keen observations on his recent interviewing experiences which, by the way, have not been successful. At the time of this post, he'd been on the market for close to six weeks and had yet to land a job. I feel his frustration in his words below. I don't have the exact number but I believe he's done more than ten technical interviews and assessments. That is a lot of time on his end and big investment in his daily focus. I imagine there have been many hours when he's needed to sequester from the rest of his family while he's prepared for these interviews. And of course when he is doing live interviews, the house needed to be absolutely quiet. It's always interesting when individuals document experiences where success has not been realized. In a tip of the hat to this engineer, his tone is not one where he places all of the blame on the company. He shares his recent interviewing experiences and then finishes his thoughts out in a way that has us looking at a bigger picture.
This individual is a great engineer and to be clear, he's had a very successful career. He documented his thoughts and then asked me to publish them. Given the stage he is in his career and having to abruptly enter a job market that is cooling, did he enter a system that did not properly vet him? Or was it something as simple as him being a bit rusty? Whatever the case may be, his words below are very reflective of his experience. For anyone else that is currently on an active job search, please sit down and read his words carefully. One take away is that if you have recently been impacted by layoffs, take some time to brush up technically so that you are prepared for the steady stream of code assessments and live coding interviews you're going to be asked to do.
Here you go,
It's time to change the tech interview.
I got laid off from a tech company a week or so ago and have started to interview and it's been nothing short of surreal. After doing a couple of them, I met up with a few other long time programmers for coffee and we discussed tech interviews. When I brought it up, everyone groaned because we all hate them, and, jokes of ritualized abuse aside, we all know that, unless you're hiring a new college graduate, they're unhelpful.
One of the first screenings I had asked me: I pass an object to a method and it was changed inside the method, would it still be changed on return? It's a simple question but it tells you very little about the interviewee other than if he happened to remember the answer. Honestly, I blew the question. Not only because I'd forgotten that language's pass by reference/pass by value rules (something I stubbornly insisted to the group laughing at me that I could Google in twenty seconds), but also because in my head I went somewhere else: why would anyone change an object's internal structure in a method? I can imagine a few scenarios where you would want to do that but not many and as I stumbled to justify my (wrong) answer I was also thinking how much more would have been revealed to my interviewer if we had a discussion as to when changing the internal structure of an object in a method was an ideal case. It's such a better and more revealing question.
And we've all encountered these questions in tech interviews: please write code that merges two linked lists, read a file and find the average x for each line, write code that walks a binary tree in a certain order. Maybe I have been lucky in my career, but the last time I actually had to use a binary tree traversal since college was in a previous tech screening.
I submit to you that these questions we put to candidates don't do your company any good and they may in fact drive you toward mediocrity. That's probably too strong but you really learn very little about their potential other than they can code under pressure or have seen that particular question before. And for those of us that have stage fright/social anxiety it's the worst (and thank the world we don't have to do it at a white board any more).
What's the alternative? Ask questions that reveal how they think.
One of the best interview strategies I've been through was when the screener asked me to design a basic User system. We broke the problem into objects like a simple user data, phone number object, country, passwords, etc. We discussed if we really need a first, last, middle and relationship (sr/jr) names in our objects (after much discussion, we decided we didn't). He saw how I approached a larger problem, heard me talking about the trade offs in designing something one way or another. It wasn’t a long interview but he said that after he started using it he rarely went wrong with his hiring.
Recommended by LinkedIn
I had another interviewer ask me an obscure question in one interview and then turn around and ask the same question in a second interview (back in the day when you phone screened then brought someone onsite). After I was hired I asked him why he did it and he told me that he knew from my resume I could code, but he wanted to know if I was curious and genuinely interested in learning new things. Was I the kind of person who, on his own time, thought about why things were a certain way? Would I take the time to look up the answer to that question especially after he asked it in a throw-away manner. Later, he told me that anyone who answered the question the second time he asked gets hired and so far he added he'd only gotten stellar employees.
So why do we ask fourteen-year code veterans if this method could be overridden or is this sorting method the best choice? I think we do it because it's easy, because everyone else does it and, let's face it, the tech lead asking the questions is super busy and has other things they need to be doing. And that is where your company could miss out on an amazing programmer. Asking algorithms or simple coding questions only gets you employees who have read a bunch of the tech screening books (a quick search on Amazon revealed 101 of them), someone who prepared for the code challenge or someone right out of school.
There was one naysayer in our coffee programmer discussion. He insisted that those kinds of questions did reveal a candidate's thinking and maybe I was a bit touchy because I'd blown the interview? It was a valid response and he's not wrong (but I still wanted to spill my coffee into his lap). However it makes you wonder: if you only get an hour to decide if you are going to offer someone more money in a year than my dad used to make in five is it the best way? Are we really searching for someone with a bright, curious and open mind? Someone transformative? Is your current approach going to find them or are you just going to get the kind of person who does well under pressure?
We all know that in two years the candidate you hire most likely will have moved on from what you brought them in to do. And you want that. You want them to use their talents to make your organization grow, be successful and be the envy of other companies as you roll around in bathtubs full of cash. But will your new candidates adapt, thrive and step into new roles easily or are they going to be at another technical screening writing binary tree traversal and link list merge code?
I really enjoyed reading this. I'm not even technical and I was able to take away quite a bit from his words. If you are about to embark on an active job search perhaps give this a deep read and maybe you can gain some insight into what companies are going to be looking for in your technical answers and general responses.
Thanks,
Mark Cunningham
Technical Recruiter
512-699-5719
Data Dude
2yOh man, I spend so much of my week conducting interviews now, and I give a thumbs to a small fraction of candidates. I'm preparing for another interview today when I saw this, basically only reason I'm on this is to look at candidate histories. We're hiring super aggressively and I hope so much we start getting better candidates. I actually read this guy's feedback, the passing by reference or copy thing on function semantics would have honestly been an out for me if I was interviewing that guy. I mean what language? If it's one he's been engineering code in for years, it should be he knows this in detail. He was considering the tradeoffs, but didn't mention them. Well, the tradeoffs are around performance and also it can come down to code security, like writing foundationally sound APIs that can't be exploited as zero-day surface area. It says a lot about whether he's ever done any rigorous training around generating secure code. If it's a language he's used and claims any proficiency in, he absolutely should have known this, it's foundational to generating high quality code and if you don't understand why it says what you don't know. Typically pass by reference is done because it's cheaper, but trade off is safety.
Vice President of Engineering | Driving Innovation & Efficiency | SaaS & Cybersecurity Expert
2yCompletely agree. Hiring for senior talent has been broken in most places for a while now. These questions are fine for someone just out of college, as they don't have any real experience to ask about. Culture > Intellect > Skill. You should interview in that order, and the amount of time you spend on each of those is proportional to their import (so, spend most of your time on culture). But at some point you want to understand their skills: ask them about things they have DONE. Not some hypothetical. Pick a skill of theirs that you want, dig into what they have done. Do they understand it? Can they explain it well? Can they talk about tradeoffs they faced. Just talk to them about what they have done.
Accomplished Engineering servant leader with cross-functional Executive experience.
2yAs someone who has been on both sides of this process, I can tell you that tech hiring is completely broken. IMO, the biggest reason is that technical hiring is run by technical people who have a preference for solving problems with technology and algorithms as well as maintaining some high barrier to entry that they themselves think they crossed to land their current role. Hiring is a people problem that requires psychology to determine whether or not someone will be a good teammate. Of course, there are technical skills that need vetting, but there are more effective strategies than the old CS puzzles we've always used. I implore everyone who has a role in technical hiring to take a step back and ask the same questions we ask about building features: Why? Why are we doing this? What are we trying to accomplish? Does this approach accomplish the goal? How can we do it better?