I agree that technical interviews are broken, but not in the way that the author describes. I think the interviews should retain the algorithmic questions, but do away with language gotchas and design patterns etc. More emphasis should be added on the following topics: distributed systems issues, traits of modern hardware (cache efficiency, concurrency issues). There needs to be a part about mathematical competency introduced as well. Knowledge of basic probability, statistics and linear algebra should become part and parcel of the engineering interview process.
The Terrible Technical Interview
41–50 of 236 posts
Re: The Terrible Technical Interview
#42In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on. If the CV and body of work look interesting, we go on to a phone screen - general questions, clarifying points on the CV, explaining the job, answering questions. For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typica…
Wow, this is my worst nightmare. I freeze anytime a co worker is near my desk because I worry they will judge how I type and get around the IDE. Of course that just makes the vicious cycle worse.
LOL, been there, done that, and I work at the same place as foz :)
Re: The Terrible Technical Interview
#43I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…
Although I believe everything you say, I'd like to provide a counterpoint. I think I'm a pretty good programmer and I've got a reasonable body of work on GitHub to back it up, but I've often failed technical interviews because I go to pieces under the pressure and my brain just stops working. I've been a dev for > 15 years but if anything I've got worse at interviewing over time. I only apply for positions that I gen…
Personally, I think (or at least hope!) that I'm pretty good at differentiating between nervousness vs. simply not having an answer. With the MVC example that I gave earlier, sometimes people fumble along and provide a lot of information even though they can't pull it together in any coherent way. Other times, they flat-out shrug and tell me that they don't know. Protip: I recommend saying something and at least making an attempt at the former.
I like to ask people about side projects, and what is the latest interesting thing that they've been learning in their own time. However, my issue with the "Your-GitHub-Is-Your-Resume" nonsense is that it falls apart past the age of 30. Before I got married and had kids, I used to spend almost every waking moment of personal time (and about half of my employer's time, to be honest) working on areas of personal interest. I wrote a handful of minor open source frameworks that are too obsolete to be worth mentioning, a set of Java bindings to the wxWidget library, authored a book, and served as technical reviewer for a stack of other books.
Then I got married, and became a father.
Now, quite frankly, I don't do that anymore. I just can't. It isn't a matter of passion, it's a matter of physics. My GitHub account includes some small personal apps that I tinker with from time to time (e.g. a diet and exercise tracking application), but I would be MORTIFIED if someone thought that was a representative sample for job application purposes. It's a fairly trivial web app, that I could just as well have written 10 years ago.
In fact, the type of work that you do later in your career really doesn't lend itself to showcasing in a small GitHub portfolio. You work on Node.js websites, with whichever client-side data binding framework is popular this week? Awesome, GitHub would be perfect for showcasing an example of that. But your most recent projects include integrating a dozen microservices with an AMQP broker and Apache Camel, or using Spark to crawl a mass of data in a Cassandra cluster? Large scale development just doesn't lend itself as well to representation in a personal GitHub portfolio.
So side projects may be a useful screening tool with junior level candidates for web developer positions, but I think it's a naive suggestion for more senior level candidates in more complex domains.
The notion of having an on-site coding exercise is better in my opinion, but that's not a panacea either. Anything worthwhile would probably take a matter of hours, turning your on-site interview into an all day affair for which the candidate would have to take a full day of PTO from their current job. There is NO WAY that I would submit to something like that unless I was already very far into the recruiting process with a particular company, and very much interested in working there already. You're not going to reach that point unless you already have technical screening tools in an earlier stage of the process, so there you are right back at the original problem.
I do agree with the article, as well as many of the comments here, that "whiteboard exercises" are a fairly pointless tool (e.g. "write a recursive function to traverse this tree", or "walk me through your process for guessing how many golf balls could fit in an airplane"). Even though my company does a bit of that too, I grumble about it and refuse to incorporate any of that into my stage of the process. However, almost all of the alternatives that I've heard suggested seem to be proposed by very young junior-level devs, who lack perspective on what their career path and mindset are going to look like 10 years down the line.
Re: The Terrible Technical Interview
#44I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…
Having performed a thousand interviews by now, I am awestruck by how poor the software development talent pool is.
My experience: exactly the opposite.
Re: The Terrible Technical Interview
#45If your only goal is to measure the ability to code, then doing a whiteboard interview isn't the best way to do that IMO. But what about positions where you will be expected to give presentations, do pair-programming, or mentor junior developers? I think whiteboard interviews can be a measure of your ability to take technical concepts and illustrate/explain them clearly to a team. I used to really hate whiteboards, b…
If you want to measure giving a public presentation....have them give a public presentation. If you want to measure their ability to pair program ... pair program with them. If you want to measure their ability to mentor ... have them teach you something they know. I want to know how you do X, and measuring X is easy, so please do Y as a proxy is never a good approach. I have never, in my 25+ year career, ever had to…
Finding out how someone reacts to being told they are wrong when they know that they are right is a totally valid interview technique.
Furthermore, I think past basic fizzbuzz questions, complex interview questions are good, but someone failing to get an objectively correct solution to an objectively difficult problem is just one signal among many. The goal of asking the questions should be to gather lots of other signals about how you approach writing software, not to pronounce you right or wrong.
Re: The Terrible Technical Interview
#46I think this would be a fair and effective interview system:
1) College graduate: Keep the traditional algorithm programming tech interview. But allow the use of a laptop (no whiteboard)
2) 2 - 7 years engineer: Require a github side project or give a home coding test. Interview will focus on discussing the project implementation. Also ask them to add a simple feature.
3) 7 - 15 years engineer: Ask them to come to the office and show them some bad code from the company source control. Ask them to explain why it's bad and to refactor it to something better.
4) Express route: Instant offer, no interview. Only "interview" is by a VP and it's more about trying to convince the candidate to join the company instead of the other way around.
The first 3 scale according to typical life situation and industry experience. The amount of free tend tends to decrease from college graduation to 30's and beyond. For example, a college graduate has lots of free time. Someone in their 20's has less, but still a significant amount. 30's and beyond tend to have little free time due to family responsibilities.
But the interview styles also match what they should know by that point. A college graduate doesn't know anything about real industry coding so the typical algorithm coding interview is ok. Someone with 2 - 7 years experience should be good at writing lots of code. But they don't yet have the experience to know that sometimes deleting code is better than adding more. They also don't have enough experience yet to read code well and refactor, their "code smell" sense is not yet developed and they think adding more code is the solution to everything. An industry veteran of 7 - 15 years should be able to read code well, spot all the issues, and be able to refactor into something better. These skills can only be gained after years of experience.
So the 3 interview styles scale well according to the free time they are likely to have and testing whether they've really grown as an engineer. The last one, the "express route" is reserved only by referral from the company's best engineers. For example, if the company has this tech ladder:
junior engineer, engineer I, engineer II, senior engineer, senior engineer II, principal engineer:
Then only senior engineer II or above AND being at the company for at least 3 years would be allowed to make ONE express route referral per year. The reason is that an engineer has to be in the industry for a while to meet other good engineers. And 3 years is enough to learn the company culture. This express route system effectively would give a competitive advantage over other companies. For example, imagine a very good engineer who is already employed. They are busy and don't want to go through any kind of interview process. But if they are given an instant offer, that greatly reduces the barriers for them and they are much more likely to seriously consider switching to the company. The main idea here is that good engineers have a lot of options but not much free time to interview, your good engineers should know a few in other companies, so the express route is a way to get more good engineers who would usually not consider moving because they don't want to spend time interviewing.
Re: The Terrible Technical Interview
#47I usually countered FizzBuzz question with an offer to show of the source code of a small project I wrote while studying. While some didn't care, most interviewers were actually happy about it and let me do it. I tell them about the problems I had and how I approached them, usually leading to a question from me on how the company had similar problems and how they solve them. In my experience this "opens up" the interviewer(s) to talk a bit more honestly about development practices in the company.
On test projects. I generally expect that companies (after a pre screening) put similar efforts in me as I put in them. If you let me do a two day project, I'd expect that one person (preferable my future boss or a future colleague) to show me a "company fitting" solution and take the time to discus my work and theirs. If you're not willing to spend that time I'll most likely think you don't respect my time. Which is a factor in choosing a company. I understand you are busy, I hope you understand that I’m too.
Edit: not a native speaker, sorry for bad english
Re: The Terrible Technical Interview
#48I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…
> "I see that you've spent X years using Subversion for source control. What are your opinions on trunk-first development vs. branch-first development?" Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. A quick Google search ("trunk-first vs branch-first svn") suggests that you're not using common terminology. After thinking about it for a minute or two, what I _thin…
In an actual interview, I would only pull out that specific example for a candidate who's worked with CVS and Subversion almost exclusively. The actual question is also a bit more verbose:
Have you worked for a company that strives to do as much development as possible in 'trunk', creating a release branch near deployment time for production bugfixes? Have you worked for a company that preferred to branch at the outset of new development, merging back to 'trunk' periodically? What did you find to be the strengths and weaknesses of each approach?
Their answer lets me read between the lines and gleen much more information about their work history. Have they worked in settings where multiple work streams were in development simultaneously? Do they have substantial experience in collaborating without trampling on shared resources? If so, then they usually mention the different pain points in merging. I don't consider there to be a "right" or "wrong" answer to this question, and not having a clever answer certainly doesn't disqualify someone from being a strong programmer. But it does help to level-set, and identify candidates who think like team leads or might be well suited for responsibly beyond raw coding.
However, I don't want too much text between parentheses that are injected into a long sentence. So you get "trunk-first vs. branch-first". :)
Re: The Terrible Technical Interview
#49In my experience, a lot of companies are combining _all_ these things. So you're expected to do a phone interview, a test project/coding test, a whiteboard test, and the management brown-nosing at the end of it where you get to pitch that you've studied a hard technical skill your whole career just because you're so passionate about getting woken up at 3AM on PagerDuty to build _their_ vision, and definitely not beca…
> I'm convinced one huge reason all this happens is to discourage job-hopping, because in this market, liquidity would probably help salaries move up faster. Walk yourself through that for a second. You're saying a company that's hiring would intentionally make the process difficult for applicants in order to help their competitors retain their employees ? That doesn't make sense. Even if they conspired with said com…
Raising salaries increase cost of doing business for everyone in the sector--increased competition may only result in decreased realized revenue, and often may just result in further investment in the sector.
To use a crude analogy:
Burger King and Starbucks don't mind if a KFC or whatever opens across the street, because while the newcomer is "competition", it isn't a big deal, and may even bring in more customers overall (because now that area is a "food zone").
They will, however, all fight tooth-and-nail to fight raising the minimum wage, because that results in higher costs for everyone.
Re: The Terrible Technical Interview
#50I am a self taught PHP programmer. Been working in tech as a freelancer since early 2000s. Built real applications.
I thought I was pretty good so a few years ago I moved to Silicon Valley to get a startup job. Boy was I wrong. Even though I had created real applications and knew MVC, etc. etc. I was basically told I was worthless because I didn't know algorithms, unit testing, etc. etc.
So I moved back home (Tel Aviv) and started my own company (lead gen market). Programmed everything myself. Last year I did over $2 mil (70% margins) and this year I am on track for $3.5-$4 mil in revs.
The technical interview was the best thing ever for me because if I had passed I wouldn't be where I am today.