Interviewing the “Passé” Way, For a Reason
no-kill-switch.ghost.io
no-kill-switch.ghost.io
Nine times out of ten that stuff is absent and the post is just a bunch of opinion and conjecture.
By the way, when you're doing something nebulous in an interview like seeing "how the candidate thinks" what you're often doing (all too frequently without realizing) is looking for justification for a decision you've already made based on whether or not you like the candidate. The fact that you have them writing code on a whiteboard doesn't instantly make the whole thing an objective process.
EDIT: You can test the above by making a "prediction" about the candidate's performance after the intro and comparing your prediction to your final decision after the interview.
It seems like you might accidentally be testing your ability to predict their ability to solve the whiteboarding problems given their resume.
As an example, at one company we noticed that applicants with a certain level of educational achievement were dramatically less likely to be able to solve the problems we used than candidates with slightly higher or slightly lower levels of academic achievement. So if I made predictions about candidates, that's one factor that would influence my prediction, but it wouldn't necessarily mean that my subconscious bias was causing the candidates not to come up with a BFS.
> not to come up with a BFS
But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;)
> But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;)
I did not say that the interview process at that company was my favorite or was the same as the one in the OP.
That said, my experience as a candidate at FAANG and smaller-but-not-super-small companies has generally been that I must at a minimum solve the problem, and that sometimes I must also solve it exactly the way some rubric says it is to be solved, so that providing an unusual approach that uses half the space and just as much time as the best approach the department has heard of also causes one to fail.
Abso-fucking-lutely, pardon my French.
To be a little more precise: unless you're going into an interview totally unprepared, there is a résumé that you've read, hopefully read carefully. I make a decision, based on said résumé, whether I would like to hire that candidate. Maybe "decision" is too strong a word. Hypothesis. Yes, hypothesis is better.
That means I have some sort of mental model of what the candidate might be like, what they can do and whether and how they fit.
If the person is invited for the interview, the hypothesis is "yes, I would like to hire this person".
The purpose of the interview is to try to disprove the hypothesis. If you fail to disprove the hypothesis, hire the person.
I knew a lot of interviewers at those types of companies who wouldn't bother to read resumes, either. They'd cite "bias" or something.
In principle I like the idea but I think they should ask to also remove the company names and perhaps dates, as it could be straight forward to work out who you are based on companies and dates.
As to how effective to remove bias, it's hard to say as I've not seen any A/B testing done with this, but give the massive push to get minorities on board, I'd hazard a guess that it's not as effective as they had hoped
Not necessarily, just depends on how easy/hard you set the bar for disproving the hypothesis. It also is somewhat inherent in that you really are trying to disprove the hypothesis.
On the other hand, if, after reading the résumé, I do not want to hire this person, why on earth should I go on to interview said person?
The "default to no" part is, IMHO generally correct, because false positives are a lot more damaging/costly than false negatives. My perspective may be warped here, because I have worked for companies that get LOTS and LOTS of applicants. At some the team would screen hundreds of résumés a week, of which maybe 1-2 were somewhat interesting, and that was after the HR screen. Oh, and I also got to clean up after one of the candidates → colleagues I said no to and the rest of the team approved... ¯\_(ツ)_/¯
"A" players want to hire people better then themselves who elevate both themselves and the team.
Not getting into how most "B" players see themselves as "A" players (dunning-kruger?), unconscious biases, or people who are just bad at playing interviewer (esp. people who have done it a certain way for their entire careers and are unwilling to even think that a different process might yield betterresults).
How to you drill down & distinguish?
If I were hiring for a position that required X years of Java experience, and saw a resume that said "X years of Java experience" (or even "4X years") without any further elaboration—no section of actual work experience—I'd be, at best, deeply skeptical.
And if that leaves nobody, you keep looking. One company I was at that was pretty good at hiring would much rather leave positions open than hire "the best of the current lot". Other companies were the other way around, and ended up with much lower quality.
And certainly if "N years of X experience" is all there is it won't be particularly interesting. Pass.
If you have improved faster, there should be work that you've done that you can reference, know-how you've amassed that you can assert you have (and I can somehow check). And if you've done the work of someone with 10 years experience, but you've only been at it for 2, yes, that will be noticeable. Very much so.
So make your resume interesting. Without going beyond what is there. One candidate had as his headline that he was a "Software Architect". Cool! First, very obvious question: "So what's Software Architecture". Stammer...stammer...and then after a while some random buzzwords about "best practices".
Now obviously there can be various different answers, and while I have my preferred and that one is obviously correct (Hah!), you should at least have something reasonable to say there if you make that the headline of your resume.
Like, the "it will be obvious" thing... I'm just not convinced. Sure, if you speak to someone you can tell pretty quickly, but on a resume? What concrete evidence would you expect to see from someone who's only been in work for 2 years? I can think of a lot, but not much that you could convey in that format.
Don't really think so. Don't confuse "plain" with "uninteresting".
I remember coming across my dad's resume at some point. It was plain as heck, but included such choice sentences as "Experience leading a national car manufacturer" (paraphrased). Ahh. Tell. Me. More.
> Do you not worry about identifying that?
Not particularly, no. First, I don't really believe that this is true, second, I worry a lot more about false negatives than I do about false positives. Third, it's really not that hard.
> Sure, if you speak to someone you can tell pretty quickly, but on a resume?
That's why you have the combination: the resume tells me if the person is interesting, the interview tells me if that was actually true.
> I can think of a lot, but not much that you could convey in that format.
Why not? Unless you're mixing up the two (again). I also see that I couldn't convince someone that I am interesting on the resume (in a "beyond doubt" fashion). But that's not the resume. That's the interview. The interview is about triggering interest.
I think you're making this harder than it is.
Heck, just write: "After only two years on the job I was doing the work of people with 10 years seniority". There, done. Interesting? Definitely. True? Well, it better be, and I am going to see if that is true to my satisfaction.
After all, it could be that the people there just sucked.
"Chemistry" is just an excuse to allow unconcious bias to run rampant IMHO. New hires shouldn't need to enforce the existing culture of the team you have by matching it.
They should be adding to it, not neccessarily emulating it.
Which is a good filter, for better or worse.
Think sororities and fraternities recruiting pledges. For better or worse.
I've long accepted that I simply don't fit into most orgs.
"Oh yea, JIRA Agile SOA dynamic typing FTW, woohoo!"
I can say the words. But most people sense on some level that I'm lying.
However, they don't often move efficiently, or even in the right direction.
The trend of what people like to blog or comment is a different thing!
I swear, I was just dealing with this a week ago. “Excuse me, Mr. Interviewer. I can either answer your questions about what’s going on here or attempt to fix the last let of this code. Which is more valuable to you?” Proceeded to use silence to fix code. Puzzle solving uses the uninterrupted brain.
And just the other day, I had the SQL schema question to design a schema … for a calendar! Worst interview question I ever experienced, honestly. Nearly no one designs calendars and they’ve got lots of ways to trip you up because recurring events are exciting. (Also, when I did design something decent with two tables and was asked to query both with a single SQL statement my interviewer didn’t understand UNION but that’s another matter.)
I like take home projects augmented with short exercises to verify that I’m not a plagiarist who’s incompetent at code. If you want to assess my puzzle solving capabilities let me play a Zachtronics game like SpaceChem or the like.
In my most recent round of interviews, I found almost no one expecting me to recall a particular algorithm and implement it for a solution to a problem, but I did find plenty of questions that involved dealing with data structures, and writing my own code and algorithms to solve those problems.
Maybe I've been fortunate with not having been asked questions like "implement the quick sort algorithm"?
That's fine in and of itself, but when I'm having a bit of a time pruning the common-ancestor paths, I want to use all 7 brain-registers for the problem instead of devoting 2-3 for communication, or, worse, having to flush everything from cache to analyze and respond to your "hint".
This sounds a lot like system design or leetcode-esque interview questions, which is the trend among tech companies in the US.
> The problems candidates are facing at my interviews usually have NOTHING in common with the company's domain, BUT they have a super-low entry level (e.g. they are about common problems everyone encounters every day): building up the context takes seconds (literally), so the candidate can focus on tackling the problem, not understanding its basics.
Are they system-design questions? This post could use some examples of interview questions the author has asked.
If you’re going to war and recruiting infantry. Some people can lift 200 pounds easy but can’t run half a marathon. You likely want both types on your team.
Not sure how that relates back to software.
A better analogy: the guy who wins the Nobel prize is not necessarily one who churns out the most papers. You could consider each type a speciality and you want both.
Soldiers are largely cannon fodder. The system is designed so that they can be easily replaced if they die, which they inevitably do in war. I don't want to die at the keyboard, that's not the kind of workplace I want to join.
A truly challenging real-life scenario can fit just fine after some alterations.
I'm intensely suspicious of people who believe that this isn't possible.
One company asked me to find a bug in a library in a language of my choice out of a small list of languages in a bit under an hour. So I pick a language from a list of languages none of which I use regularly, and until the interview I was not sure which of dozens of combinations of tooling will be used by the project. It seemed like a reasonably sized bug that someone who was not worried about time pressure and had worked on a project tthar used the same tooling could reasonably do in the time given. So I failed, and I passed comparably difficult sections at other companies that I did not want to work at as much.
Seems like this is where they went wrong...
I had this happen to me in one interview https://news.ycombinator.com/item?id=13295212 using Python which I didn't know very well. Despite it not working out I thought it was one of the better interviews I've had.
If you give it to somebody you know you'd want to hire and they take 4+ hours to do a 1 hour task that's kind of a red flag. I'll bet your company didn't test their test.
Telling me "I will come in for 8 hours make things you want made, the way you want them, for money, and then go home" is fine by me.
[0] Some of these are bonuses or predictors of general suitability sometimes, but none is a deal-breaker.
I don't know about anyone else, but for me personally, it's a bit difficult to have fun when I'm unemployed and need a paycheck.
You might even say that interviews are testing for how financially secure you are. You can only truly relax during a job interview if you don't actually need the job.