Tech Interview Torture Chamber
mattfriz.com
mattfriz.com
- Stay at my job longer and push for more raises/promotions. So far this has worked well. I may not get more in raw $ amount vs job hopping, but when risk adjusted (the risks of any new job such as bad manager, etc.) it's worked out ok so far. I think some job hopping is still good early career, but at this senior level, job hopping loses most of its advantages. Also, being senior at a company (not just in title, but also tenure), has other benefits such as more influence and connections within the company.
- For future job searches, companies that don't have the algorithm/data structures interview will get a big boost in my list. They will get first attention.
- If I find an interesting job that still has the bullshit process, then my investment in the process will be very low. Basically, one or two evenings refreshing my memory on basic algorithms/data structures and that's it. If the interviewer asks a question expecting me to know some exact algorithm or trick, then they are a very poor interviewer and the problem is them, not me.
So it's not just about skipping companies who ask stupid questions and definitely not about working only one or two evenings on algo stuff. Trust me I've been through this process recently with 15 companies! I worked for a bunch of top companies in the past and I can attest, it is extremely painful. They want robots now and interviewers are lazy and annoying. How naive I was when I carefully selected the only company and job I was interested in at the beginning. Then I went through the process and got smashed in the face. I had to align another 20-30 companies to get at least 10 to 15 tries, then an offer. An offer from choice #15?? That sucks... it's 2017 and things have dramatically changed.
I've been programming for half my life and I'd fall over on that stuff.
At some point interviewers must get it, that these artificial test environments bear no relevance to how we write code in the real world, and putting these false constraints on a candidate just creates stress, and in no way communicates their competence.
Luckily for me (as an interviewer) I do get it. And I suspect that's part of the reason why I've not had a developer leave my company in the 12 years we've been running. I do a first interview, which I keep super chilled and chatty, just trying to get the candidate to relax. I'll focus on projects on their CV, asking high-level questions. Again, no stress. Then if they say anything interesting about a part of a project I may drill down a bit more to make sure they understand the subject they're talking about. Which is slightly more stressful, but if they're competent, they'll know.
I very rarely go into algorithms and data structures. It'll usually be if I'm concerned about a junior dev not having enough CS knowledge.
I then send them an email post interview (if I think I want to see them again for the second interview). The email will have a link to a partially complete project, I ask them to finish it based on a written spec. It shouldn't take more than 45mins - 1hour.
The request in the spec is intentionally a bit obscure. I put at the end of the spec that "If you have any questions or problems, please email me. You won't be marked down for this." The obscureness of the test is to see who emails me to ask for help. That for me is a real positive sign.
So I'm trying to create a real world test:
* A spec to follow
* Programming in a comfortable environment
* Access to dev resource (Google/Stack Overflow/Their friends)
* Access to their boss for advice
And to avoid anybody trying to game it and blag their way with code that they didn't write, I quiz them about their decisions in the second interview.
It works amazingly well. My dev team is something I'm super proud of. A good team of people who collaborate well and believe in the product. No hierarchy or in-fighting. It's a happy place to be. So I endorse this method :)
I keep hearing this, and perhaps I'm not part of the problem. But at a prior company I worked for (which was quite good), our go-to phone screen was "implement min()". This screened an absolutely staggering (to us) fraction of the candidates. I don't see how asking someone who claims to have years of experience in engineering write a for loop is stressful, and anything but real world; I write for loops all the time, and I don't consider that the hard or core part of my job.
(One of our followup questions, usually on-site, amounted to: "can you write a for loop that involves two pointers?"; too many candidates would give them absolutely terrible names like "i" and "j", and not be able to mentally maintain what they actually meant, or were for.)
I like to ask people to "implement reverse()" with similar filter results.
I wonder if there is a cultural component to it, I'm also in the UK.
Also interesting field you are in, that is tangential to something I'm contemplating as a future project :).
I think it's just a weird California thing, kind of like "thinking In-n-Out is better than Five Guys", or "driving your state into bankruptcy".
The rest of what you said, we have no quarrel!
They do have tech interviews, but it wasn't an "Engineering" position (they were for Technical Consultant/Technology Consultant type roles) so maybe that's why they don't drill you in algorithms (you ARE expected to code though).
Full details of the ridiculous charade here https://medium.com/@meowlicious99/my-software-engineer-inter...
Fast forward to the in person meeting, they go through my solution and nitpick random things like "why use NuGet packages" or "why no test cases" (I had written them but they got mysteriously removed from the solution).
Finally the CTO speaks up and asked why I didn't write a GUI, as many other candidates had (mind you this was an application that accepted inputs and ran a calculation). I responded, "it's less effort to write a console application and the assignment said it was acceptable". CTO then snarkily asks me "do you always do the minimum"? I should have snarkily responded "only when I'm asked to code for free".
Thankfully did not get an offer...
I am not BS-ing - I really like console apps. I agree with you that you dodged a bullet there. Any place that lays a false choice trap for you in this manner is not one that deserves the best candidates.
I would have responded "Yes". The less we do, the less scope to go wrong, the less maintenance we have, etc etc.
In fact I don't want to work with anyone who would answer "No" to that.
Oh, upload the resume that you just spent 2 hours tweaking and feel great about? Simple enough you think. No, a parser tries to extract all of the relevant information from the PDF and place it in the appropriate fields with about a -50% success rate. Now it looks like you've had 5 jobs in the past 5 years.
Want to upload a cover letter? Not an option, but you can use this text box widget thing with some basic functionality. Of course, you just can't copy and paste the pre-written cover letter, because the widget completely screws up the formatting and now it's a jumbled mess with no structure between paragraphs. Easy to fix, but still.
I guess the worst part is, there is nothing to indicate that your perfectly formatted resume that you uploaded will ever been seen by someone.
My mistake, that's the second worst part. The worst part is having to create a new account for each of these career "portals".
I loathe the processes that have you upload a resume and then take 30 minutes to fill out forms of information that asks questions that should already be on your resume. It's feels painfully redundant but also makes me worry that they will look at the form data, not my resume/cover letter that I uploaded.
Oh it gets way better than that. How about when you are applying to XXX company through a portal and YYY company also uses the same portal? And how about when it won't allow you to use the same email address, as if that is some highly suspicious activity that should be disallowed?
I figured out later that they use these portals because turnover is so high their recruiters can't keep up with demand for fresh meat. One of them couldn't even retain their internal recruiters, so they outsourced the entire recruiting and vetting process.
Might not be anywhere near 100% overall but when it works it makes for a really lovely experience.
I did exactly this before leaving my previous position. We had a friendly 45min call the next day, just talking about my current situation at the time and he was thrilled I reached out to him directly.
The best company job site I've used would allow me to use my linkedin profile to log in then it would just pull all my resume data from my profile. The only thing I actually had to fill out was just a cover letter. I applied to a bunch of positions within a hour although I never got a call back from them.
Write O(n) algorithm for bus ticket allocation. Use yellow unbalanced binary tree, you have 40 minutes. Then we will run it against exhaustive tests our engineers have been working on for the last couple of weeks. Uhhhh... what's that?... your algorithm melted down... We wish you good luck in your job search, thanks bye!
Luckily I approached these tests while still being employed, otherwise it would be quite soul-sucking experience. Now I just don't take them seriously anymore and feel an urge to troll them somehow.
One interviewer took it personal and hung up on me haha.
I caught the punk red handed asking a question he did not know very well.
Obviously, this piece is satire. When giving interviews, I do whatever I can to make the candidate walk out of there with a smile whether they did well or not. I stand by the idea that it should be possible to entirely assess someone's ability without ripping their guts out or making them sweat.
"Choose the interviewer" is pretty much "choose a random developer working at a San Francisco tech company". There are so many true stereotypes in here I'm hurting from laughter.
I knew the VP of engineering through one of my contacts and sent him an email asking him how a maze solving algorithm relates to web development. To his credit the VP apologized and set up another interview albeit with an even more junior developer who asked about finding loops in a linked list.
sigh
Thankfully I didn't take the job because the company shut down recently.
"Asks brutal tree sorting question"
"Fixes Docker image configurations all day"
In my world (Line of Business/SME) they aren't, I used to know the exact properties of a doubly linked list and all that stuff but I haven't had to think about it for 18 years.
The question I've had the most success with at predicting if someone will be a good dev (in my domain) is some variant of :-
> "I run an electrical testing company, I want a system to manage my engineers, ask me the questions you'd ask a client"
If the response is "How many engineers, how many sites, how quickly are you expanding, do you need this to be available on foo/bar etc" then they are showing the skills they need, it's not about them having good answers but knowing how to ask good questions.
Others I like are "Tell me about the worst bug you ever wrote and how you figured out the fault" and here is some code, what would you do to improve the quality, looking for things like refactoring large methods, consistent comment style, fixing indentation.
That gives me a hugely more useful insight into whether someone will be a good developer over "Explain to me in detail the thing you might have been lucky enough to have boned up on two days ago or might not and will never have to use".
The dirty secret is that (for most of the programmers in my domain) you don't need to be some algorithm wizard who can tell you the O(n) time of the Spasky-Fischer Recursive Tree Search, you need to be able to write clear, concise code that shows intent and is going to maintainable in a year.
Is there a better way to ask this? It would be relatively awkward for the candidate to bring up on their own, so it seems like a good idea to make sure nothing unexpected has occurred since the call was planned.
> Alright, that's enough chit chat. Curtly prod them to submit to the interrogation.
Assuming it's still good to have the call, why would you not just jump in? The call can't last forever, and I'd rather have a solid ~40 minutes of technical content with time for questions than an opening of awkward forced small talk that, especially in the context of technical candidates, there's a good chance neither of us find pleasing.
Anecdotally, I've found that most good candidates will "small talk" about the technical subject matter that gets brought up during the call, if only to appear as a person familiar with it. (Although I do get a little lucky with security related things occurring pretty regularly in the news, so it's easy to reference.)
This is X from company Y. Is this a good time to talk?
Great, so the way this usually goes is I talk about A, we talk a little about B, I'll ask you about C, and if you have any questions D
Sound good?
Collaborative code editors are an unpleasant modern addition to the interview process. Plus I'm usually writing the code in another window before transcribing it to the collaborative window, usually leaving the person on the other end of the call to wonder if I disappeared. I tend to pass these things though.
Speaking from the other end of the phonescreen line and collab editing session, that behavior looks a lot like googling and pasting in the first answer you find on stackoverflow. We use a collaborative environment because I kind of want to see you typing, sorry. I know, it's degrading, but... it's a screen, it's not designed to find out how great you are, just prove you're not going to waste our time.
I prefer when the interviewer reschedules the interview two or three times, calls 15 minutes late, and then asks "Is this still a good time?"
If you can tell the interview isn't going well, why not leave on your terms? "My experience and expertise is in A and B, and it seems the job is more about C and D, maybe this isn't a good fit? Ok thanks, pleasure to meet you, let me know if something comes up related to A and B. Bye".
Only you can keep the other side honest. Do it for your own dignity and for all the others who really need a job and will put up with anything.
When he told me the main value of recursion was avoiding state I disagreed with him [e.g. a chess engine is highly-recursive potentially but shares state]. He kept going with all-or-nothing questions and then responding to my answers with "eh..."
Eventually I said, "Hey can we put this on pause for a second? I'm not sure how you think this interview is going, but for me it's not feeling like it's going so well... I feel like the questions I'm getting asked are really put-you-on-the-spot type questions and then you're disagreeing with my answers but not explicitly so I don't even get a chance to explain my position.
After a while he said "Listen I need you to prove to me why you're better than 9 other candidates," at which point I knew I couldn't work with this person at a personality level. To that I said "Well I need you to prove to me that you're better than 9 other companies." For some reason he kept talking and eventually went to "Can I give you some advice?" I said "Look man, I'm not too sure why we're still talking honestly. I want to be honest, I think at this point it's pretty clear you don't want me to work for you and I don't want to work for you either." He said "You don't want to work for me?" Apparently he couldn't even tell that he had gone so far over the line that I confronted him, something I had never done in an interiew in my entire career before.
"Nooo," I chuckled. In the end, I'm glad I only had this awful experience when I was 30, because if I had been new to engineering at the time I might have blamed myself.
I particularly liked "Startup Engineer Unwittingly Implements Crappier Version of Open Source Project" [0]
I'd add
"Hide the fact you just grabbed this resume off the printer. Make sure to take the first 5-10 minutes reading the resume silently in front of the candidate, then asking the same questions the previous 3 interviewers did about your school and work history"
I personally have been the evil interviewer for some time. I'm giving paper coding tests that make sense to me, and I'm generally very happy with my recruiting. I have never met anyone who slammed the door screaming "I'm too good to take your stupid test". I've passed people who completely screwed the test. I've failed people who nailed it in 5 minutes.
I've taken interviews where I was asked brain teasers, fibonacci things, pointer swapping, class hierarchy things. I've been accepted to some jobs where I failed the tests, I've been thanked to some jobs where I passed the test.
The point is it is NOT about the test.
When I read someone saying "I've taken countless interviews, and I don't get a job", I'm thinking: well, either he's been very unlucky (which happens), or there is something wrong with the guy's attitude.
I don't think the point is the tests described into the article (which I found hilarious, btw). I think the point is about the amount of resources, perceived by the candidate, that the company pours into a totally jammed hiring process.
When I read someone saying "I've taken countless interviews, and I don't get a job", I'm thinking: well, either he's been very unlucky (which happens), or there is something wrong with the guy's attitude.
Yeah, must be their attitude. Not the arbitrary and biased test given by an interviewer who doesn't even realize it's arbitrary or biased or that they're selecting for qualities they personally think are important rather than whether the candidate can actually do the work.
But that explains one or a few failed interviews. Once it becomes a consistent trend you have to start looking at the common denominator.
Oh god, this is giving me flashbacks. In college I phone screened twice with a certain Seattle megacorp and both times the interviewer was completely unintelligible. This was before the popularity of codepair so the interview was completely verbal. I specifically remember that during one interview it took at least 5 minutes for me to tease out that the interviewer was saying the word "millions". Not to mention I took the effort to find a quiet space and locate a headset while the best the interviewers could do was a speakerphone in a wind tunnel.
We got rid of the "Why are manholes round?" questions, now we have live coding tests.
Also, my codebase does have an honest to god tree traversal, on the front end no less. This stuff shouldn't be seen as esoteric trivia.
It's this condescending attitude that ensures that companies only hire recent grads instead of people with actual software development experience. I will write you a depth-first search (assuming that, god forbid, my libraries don't have that functionality for some reason) if it's not a contrived example in an interview. But I have to say, so far, 99% of my pure algorithms code have been contrived interview questions.
If you can't do depth-first search in a stressful interview situation that you sneaked away from your actual job for, you might just be a human being. But either way, if your interview process is only interested in testing my knowledge of trivia, instead of my actual development skills (like how I manage complexity or design systems) then I think I'd rather work for more competent people.
In the end, I now have a continuously A/B-tested scheme that I'm pretty happy with, but still most of it is intuition.
Which is very applicable to the job itself: Intuition is nothing but unconcious and highly multidimensional optimization across the vast range of hard/soft skills required for the job by means of pattern recognition and heuristics.
Everything that has simple measures (automated coding tests, phone screens by nontechnical people,...) can be gamed and produce lots of false positives AND negatives (see the recent Google screening for the GWAN guy).
In the end, I can read much more real-world success from a quick coding challenge that shows me an applicants' thinking, craft, naming, library choice and so on.
I'd consider myself a top 5% interviewer by now, but I have no clue how to automate, scale or replicate this.
> In the end, I can read much more real-world success from a quick coding challenge
The only determinant of on-the-job performance is an on-the-job trial. Quick coding tests can be gamed also.
How (assuming its in person)?
I actually had to laugh out loud at my desk at this. My office is absolutely guilty of terrible markers and lack of erasers.
All in good fun folks. All in good fun.
For some reason I doubt that would work for the Big4+Unicorn interviews - then again, I've never gotten a DP problem from those companies.
I had a good laugh at this. It's too accurate :)
I used to do this, I guess it's time to stop
I've been in a number of offices where the equipment on the desks is shiny, but the bathrooms look like they haven't been maintained or even received a coat of paint in a decade. Tells me a lot more about what goes on under the surface than people want to let on in an interview.
Sadly this quite could almost be pulled right out of a real tech interview we've all had.
They weren't a fan. In the rejection email, they said I wasn't technical enough to fit in. I replied with my offer letter from Google.
Dear god, what? I mean, it's not an operating system, but that's hardly a reasonable interview task.
Besides, radix sorts are generally good for fixed-width data that has a known bound, like integers.
Basically, this is made-up nonsense. It's good made-up nonsense though.
Bonus points for grilling open source developers who wrote some critically important tool your company depends upon, and/or are the person who literally "wrote the book" on the technology you expect them to use.
I don't think it's out of line to expect a senior person to have the breadth of knowledge to be able to work, at a basic level, with basic data structures. To have memorized all the details of stuff they don't use? No. To have a basic knowledge? Yes.
Don't know if you're being sarcastic here, but this is actually true. I've interviewed people who have worked in senior coding positions for years who have struggled to finish fizzbuzz style coding competency checks.
Certifications. Companies are duplicating effort to find the same algorithm masters when we can just have a cert that demonstrates your mastery of algorithms. Have different certs for different specialties. Then actual job interviews can just be a culture check.
And the great thing about certs is that they're relatively low pressure. You can always take it again if you fail or score lower than you feel youre capable.
Hey, but it doesn't end there. You spent all this money and time to hire someone, why treat them nice, give them a desk in a hallway and crappiest laptop you can find. Let's see how they work with that. :)
There are some nice places, thankfully, but this is fairly common theme unfortunately.
I noticed the same thing happened last week with an article about stupid hiring practices. Is some moderator penalizing these things?
No humor allowed on HN I suppose. Their loss.
The prevailing sense is an objection to the submission to process required by candidate; submission to a reductive process designed to break a person down from a holistic human being to a set of scores, attributes or values, upon which a judgement is then passed. It is no exaggeration to say that this is inhumane.
We can change this, but the first thing that has to go is the idea of the 'candidate funnel' (check it out yourself - this idea is so pervase in recruitment, we even build software around it) - which in 2D looks exactly like what it is: a sausage machine.
If you can't find companies like that where you are, consider being somewhere else. There's more to the world than the Silicon Valley treadmill.
Bonus Sparkles for it being in the same state that I currently live in.
I will squee like a schoolgirl with delight if they deliver the above with coherent English of a 3rd grade level or better and I can parse the point of their Email in a single pass.
99% of the interviews I done so far were wtf.
The 2 that were respectful and seeming to correctly check for my abilities to do the job were when applying as a mover and a car mechanic. Lol.
When I refer someone I usually do so because I worked with that person in the past and / or highly believe in their technical ability. I want to work with that person because I believe him/her to be a valuable asset for the company.
It's very frustrating to loose a smart person and possibly friend because of some trick interview question
Is there untrusted senior people? Or trusted non senior?
How is trust defined? Does this become completely political of who likes you?
If I apply for a job, and they have no interest in me, I honestly prefer they don't bother contacting me at all. Generic rejection letters are a waste of both of our time.
Once I've applied for a job, it's out of my mind completely unless they contact me again for an interview. I move on to applying for the next Job - I don't wait around wondering whether they'll get back to me. It's a much better mindset for me personally - I apply for more jobs and rejection doesn't phase me.
YES! One of my pet peeves. The worst, doing a phone screen/interview with someone who sniffs constantly while you're trying to problem solve.
There is a strong correlation between self awareness and intelligence, (I'd google for the white papers for those who will no doubt disagree).
Anyone who chronically sniffs is not very smart and not someone I want to work closely with or at all. How about that as a key indicator, lacks self awareness or consideration of others.
It's not too much of a stretch this could affect cognition the same way pollution does.
> There is a strong correlation between self awareness and intelligence
Does not support this:
> Anyone who chronically sniffs is not very smart
Chronic sniffing isn't necessarily (or even likely) a sign of a lack of self-awareness.
As a representative of the CCC, I'm going to have to ask you to stop being sinusist.
The same logic that states that bad candidates are always floating around applies to companies... companies that always have open positions are not necessarily the best ones, those seem to fill their open positions faster.
>> I have given up entirely on interviewing for SV companies, and work 100% remote now.
i prefer messaging folks on linkedin or finding recruiters.
step 0: send email
step 1: wait for phone call
step 2: interview
step 3: negotiate offer
step 4: get job
All of these other things are on me. References I have to call two or three (or at one company, six) people and ask for the favor of giving a reference - just to apply to a job.
Of course I can fold my arms and refuse to give them, but if we're starting off on that footing, I might as well just break off the interview.
If we're nearing an offer, I have no problem giving references, it's just silly to have to worry about my references getting calls before I've even talked to anyone at the company.
My more minor peeve with interviews is not mentioned as well. That is, scheduling the in-person interview. If a company is flexible, I could take an extended lunch and have an interview wrapped up within a 60-90 minute lunch break (or better yet, go after normal business hours). But companies keep you around for hours, sometimes just sitting there waiting to talk to people. Inevitably one of the main people you were supposed to talk to is unavailable to speak to you that day. It's understandable an in-person interview is during business hours and can be a few hours long, it's more the ones that waste my time for no reason that annoy me.
Good point. Having to always blow a vacation day on an interview seriously limits the number you can do per month/year. Want to do 10 interviews a month? You've blown half the month right there.
Probably I wouldn't want to hire someone who does 10 interviews per month.
Anyway, speaking from my experience in software development, most people I hired (and me, my friends) interviewed with 1-3 companies before choosing a new job. Once or twice I met people who bragged about "having 17 offers on the table, so you need to hurry with yours" - they weren't the people I would like to work with.
Realistically you will be asked to work after normal business hours now and then (and, in our industry, many times a year), so you'd think they wouldn't mind scheduling the one interview you'll do with them whenever the hell you can fit it in!
Source: I'm a former recruiter
the right way seems to be to give a heads up, early on, that references will be needed and be explicit about when they will be contacted. this ensures that the process doesn't block for a couple of days on the candidate contacting their references.
Strangely enough, whenever a company gets past that point in the interview process, most of them don't even bother asking.
Think about it from the other perspective, you want to do an interview after normal business hours. This means that a recruiter, several engineers and a culture interviewer have to also be present after work hours. Now scale this up to a few dozen candidates; I wouldn't want to work in a place that does this on the regular.
Well no, there doesn't have to be that many people in the interview, especially the first one. I've never heard of recruiters being there for the interview at all.
> I wouldn't want to work in a place that does this on the regular.
Depends, some might allow the interviewers to start late or to take an time in lieu after several interviews.
I'd prefer more interviews to be after hours, otherwise it's too hard to look for jobs when you already have one.
The recruiter's job is to make sure the candidate gets to the right office room in time; makes sure that if an engineer drops out that there is someone else to pick up the slack. Also, if the candidate has a public freakout or decides to get nosy and peek at someone's computers, it is their job to be nice and navigate the candidate to a more appropriate scenario.
> Depends, some might allow the interviewers to start late
My point is this doesn't scale beyond a certain point. I have complete sympathy for job seekers but I think you are underestimating the amount of grievance that can builds up when one is forced to interview you. As a potential interviewee, I'd bite the bullet, do enough preliminary talks/coffees to figure out if this is what I really want and then go interview at a time that is mutually convenient.
Once, I had a friend and former employer call me and ask if I was looking for a job. I told him no, I wasn't.
Turns out, the recruiter was using "checking my references" simply as a pretext to call my former managers to ask if they were hiring.
I know a company (profitable, no-VC, small private hw/sw business) that has been practicing that for years. The scheme is quite simple: they "rent" people at bodyshops in Russia (it's relatively cheap there), work with them for some time and then offer them relocation to the HQ, paying some penalty to the bodyshop.
Another well-known company has different version of this: they just hire everyone after very basic sanity check. It's pretty easy to get in, but at the same time it's even easier to be fired. Turnover at the company is horrible, but there's very strong core of managers/designers/devs, that survived all battles.
My point is there's no way you can find out for sure the candidate is good for a) company b) project c) codebase d) team etc etc, unless he's clearly crazy/arrogant/stinks or whatever. So maybe that "gradual hire" is the answer.
P.S.: Being at the other side of hiring process sucks too. May be even worse.
I think this method would highly select candidates that didn't have better options. The reason it works in your first example is that the person being gradually hired is employed by another firm that offers them stability and benefits in the meantime.
I've been successful with this process all sorts of environments, even in unionized civil service gigs.
Careful not to presume or disseminate the idea that all candidates/hires are men.
Also, many European languages have gendered grammar, which means that it is hard for English second-speakers to speak about someone in a gender-neutral way (for example, it would not be syntactically possible to create such sentences in Slavic languages).
Unfortunate.