As a senior engineer who already has a good job, here's how I've adapted to the stupid tech interview and plan on doing for future jobs:
- 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.
I like your first point, though your 2nd and 3rd points tell me you haven't applied for a while :) They've all adopted the google model, small or big companies it doesn't matter. You start with a 45 minute technical phone screen (algorithm/data structures), sometimes a second tech phone screen, an onsite of at least 5 hours with at least 3 to 4 45-minute technical screens (algo/data structures) as if it wasn't enough... let's repeat the same exercise 10 times to make sure you'll fail at least once... Finally, an additional "culture fit" 45 minute chat with a director or VP at the end of the onsite. An additional home assignment is given to you when they have too many candidates to chose from.
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 3/4 of my life and I'd fall over on that stuff. I'm a CTO of 12 years and I'd fall over on that stuff. I have a successful open-source project [1] which is all algorithms and data-structures, 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 :)
> these artificial test environments bear no relevance to how we write code in the real world
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 think implementing min is slightly different to remembering the rotation algorithm for an AVL tree (for example). But still, my point wasn't to not test, it was to allow the candidate all of the tools of their trade whilst being tested. 'Air coding' (a phrase I use for white-board/paper/verbal coding) is not a good indicator in my humble opinion.
I've been on both ends recently. It makes no sense. I had one start up invest in 4 phone screens before deciding to pass on me. I was stunned they passed because I aced all of their phone screens (which were not trivial btw). As an interviewer, I have been giving candidates questions slightly above fizbuzz and they keep failing! And this is candidates who have written multiple years of professional programming experience on their resume. I think there are a lot of low quality software devs out there. In an attempt to filter them, people are putting insanely high bars - makes no sense!
I see that you're located in the UK. In Europe the hiring process is much different than in the San Francisco Bay Area for instance. Here it's crazy, we don't hire software engineers, we hire "developers" instead, which tells you what people are looking for. We love hackathons and we believe developers dream about code all night long. Since people are coming from Asia, India, Eastern Europe, etc. the environment is interesting. People think differently in general about software development. It's all about hacking rather than designing or thinking high level. Being smart here means being able to crack tough algorithm problems. This is a very old school way of thinking, it reminds me google back in 2000-2005.
I guess it depends on the position, but it's not all of them - I know for a fact that at least a few large SF-based companies haven't adopted the algorithms/data structures bullshit.
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).
Where do you live? I started a new job a year ago and took my time looking. I spent a good 6 months interviewing at probably 20+ places and none of those places had a lame tech interview... None of them. They were small to mid-sized companies all over the country (I was considering remote work as well). So I think you are overstating it a bit.
If you have a job with decent pay, sane management, and reasonably good co-workers, do not casually walk away from it. I've been too many places that didn't have one or more of those. All three in one place... well, think twice before leaving that.
Agreed, and I think this is a lesson learned far too late in life. I had a job early in my career that gave me immense satisfaction which I gave up to live a life in a bigger city and a bigger salary. If I could talk to my younger self, I would tell myself to stay put for as long as possible. Sanity at your job is worth its weight in gold. Fortunately after many years and a few more job changes, I've found a spot that gives me the same satisfaction again. Sure, I may not make the huge salaries as some of my friends do, but the pay I have is decent by any measure and comes with great benefits and a high quality of life. I plan on riding this one out until I retire and that feels pretty good.
I am in the same boat, I have over a decade of experience doing all sort of thing. But I was recently rejected by netflix because I used java 7 instead of java 8 in their coding interview because 'it shows them that I don't keep up with latest tech'.
I once had to do a take home project... the spec said I could write either a console application or a GUI.
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".
My response to the 'why not GUI' question would have been different: 'console applications are more versatile, easier to run across multiple platforms, and can be invoked by build and automation tools. I also feel that they might be friendlier from an accessibility point of view than GUIs.'
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.
If it was a company that does a lot of contracting, then doing the minimum (to spec) is pretty much required. Do anything more than what the customer asked for and you are wasting resources.
I think that situation calls for the candidate to preemptively make the decision that it's not a good fit. Who wants to work for a place that is obviously willing to waste your time and then insult you for it?
"Do you want your employees to divert their time to building functionality that you explicitly identified as unimportant in the requirements-gathering phase??"
Heh I've been applying to some gigs recently and those job application pages! They can be infuriatinggggg.
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".
> The worst part is having to create a new account for each of these career "portals".
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 really wish the standard was to just ask you to upload your resume and cover letter as a PDF. Dont have any auto extraction. Then have some forms to fill out for basic info that shouldn't take more then 5 minutes.
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.
But then they can't just do a quick search for the specific skills or sort by years of experience, making the recruiter's job longer and more expensive. I keep a text only copy of my resume specifically for pasting into job applications since my resume never gets parsed correctly.
I've actually gotten to the point where I just skip applying to jobs when I'm redirected to one of those portals. Fuck 'em. The only exception is when I think it's a company I really, really want to work for, and there aren't many of those any more.
If you really [think that you] want to work somewhere, and this is what I've done in the past, you can just look up their recruiters on linkedin or something and cold call them - most recruiters or HR departments are overjoyed at this kind of personal attention, and can even get you some perks and recognition along the way. Plus you just send a nice email (your cover letter essentially, but not as forced) and attach a resume formatted as you please.
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.
And each one wants you to create an account and a password, each with different requirements for # of letters, digits, and special characters. Because, you know, people are always trying to break into these sites to post fake resumes.
Exactly my theory, especially after having worked for two companies where their process included the shitty portals.
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.
I think most of these start out as as management having to justify sharepoint licenses. I wonder how many of the "can't find qualified people" companies are doing this? It's amazing the steps some employers will take to limit the employee pool.
I use two columns to list my duties and assignments at previous jobs to reduce page length as handing out a one sheet at job fairs works really nice. The parsers always end up collating the lines together into a jumbled mess. I just now keep a copy for humans to look at and a text file copy for me to copy text from.
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.
My experience with initial stage of recruitment to Amazon, Google, and other "we can afford false negatives" jokers.
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.
During the part where I get to ask them questions I always ask about their current project and whats it built in. Even at the big guys they always reply with the same frameworks everyone else uses etc. Then I say something like oh so your project is using framework x so you're not coding your own libraries from scratch using graphs etc.
One interviewer took it personal and hung up on me haha.
One time i coxed the interviewer to show me the solution on the whiteboard when i could not figure it out. I kid you not he could not do it and got confused like i did.
I caught the punk red handed asking a question he did not know very well.
Depending on how early into the interview process it was, that guy just might have been looking to see how you arrived at a solution no matter how correct it was. I would rather see someone's problem solving skills than how many whiteboard problem solutions they can memorize. Even in school, I've had plenty of professors that would give partial credit for exams that may not have the right answer but the steps to arriving at a solution or deriving a formula to come up with the solution were on track.
I did this to the recruiter who did a phone screen for a position for Google. She was being super aggressive and borderline abusive in her questioning, so I rapidly lost interest in ever working there. And when I got the opportunity to ask her questions I turned all her questions around on her and asked her for solutions. She admitted she didn't know any of the answers. I didn't get a call back, but I kept my dignity. I pity people who work at Google now.
And yet so many ask for a chemical description of condensation from hydrogen and oxygen gases right down to the quark level, complete with working example.
Author here. I'm both pleased and dismayed to see this is as relevant as it was when I wrote it a year ago.
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.
As someone who only recently went through about 25 interviews this article gave me a bittersweet laugh. I wish more people understood how awful the torture chamber interview process is for everyone involved. Maybe the industry will catch up one day.
I am rolling on the floor laughing at this. Thank you for writing it.
"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.
The one I love is when they ask questions that are completely unrelated to what the position is for. e.g. I applied to a startup company that sold used cars online for a senior web dev position. Their junior dev asked me about a maze solving algorithm.
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.
This happens a lot in data science too. Interviewers will ask the most esoteric and difficult questions they can come up with, and then half the time, if you get the job, you discover you're doing nothing but linear or logistic regression.
I agree with this mostly, but I've also heard that algorithms questions can be a good proxy for actual software engineering skills. I've never validated this claim but I'm curious if anyone has any research on either side of the argument.
> but I've also heard that algorithms questions can be a good proxy for actual software engineering skills.
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.
This is anecdotal but in my experience a better signal is whether the candidate codes with best practices in mind. Give a moderate complexity design problem and watch for use of best practices/design patterns (good commenting, SRP, DRY, DI, IOC, etc). That tells me the code that person will write can be understood and maintained by someone else. After all the person who wrote the code is not necessarily the person who's going to maintain and enhance it for the lifetime of the application.
> Always start off by asking the candidate, "Is this still a good time?"
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.)
I love that. Or when they audibly sigh, tap their pen on their desk, or stare out the window. These actions say, "I have more important things to be doing," and that's how you know the company is doing big, important things.
I agree. Phone tech interviews are usually low level screens to see if the candidate has the minimum technical chops to come on board. Short and sweet is what I prefer, especially since I'm usually doing the phone interview on a lunch break and would like to have some time to actually wolf down my lunch.
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.
"I'm usually writing the code in another window before transcribing it to the collaborative window"
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.
Uh, yeah, that's some bullshit, buddy. You know what we're doing? Constructing and testing our code! A lot of those collaborative editors lack the ability to run code, which makes them only good for displaying final results. Plus, we all have editors we're familiar and productive using, why wouldn't we use what works for us? Plus, copying and pasting in from Stack Overflow is an issue? Come ON, buddy, that's just a sign of a good developer. A good developer does as little reinventing of the wheel as possible. If you want to make things more challenging then just increase the difficulty level of your questions so that more Stack Overflow code will need to be found and cobbled together. But yeah, if I got shit for not literally typing live into the crappy cooperative code editor, I'd politely thank you for the opportunity and end the interview. Senior-level people don't have a lot of patience for that kind of crap, particularly the truly good senior people.
Demonstrates why it is a crap way of testing people. (I often look up answers on Stack Overflow to save time/ thinking. I also answer a fair few questions on Stack overflow as well).
It is on everyone who is not in a desperate job seeking situation to push back on any practice you deem wrong. Expect a respectful and fair treatment throughout and when you're being manipulated, take the initiative.
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.
This is actually something I did one time, and I'm glad I did. I was enduring a scala phone-screen and the interviewer kept asking questions of the form "What's the #1 reason people use recursion?" "What are the 3 common examples of monads?"
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 regret not doing this the few times lines were crossed (on one interview someone ridiculed me for not being able to answer a ridiculous math question because I went to a top CS program).
I disagree. There's always jobs for valuable candidates. It's average to below-average candidates who find any market challenging. I believe in always having standards, and if you run across this kind of bullshit, set them straight and move on. The reason this kind of crap persists is because too many people put up with it.
Wow, what slick organized company is this where each onsite interviewer has read the resume ahead of time and has a copy in-hand?
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"
This is starting to be a bit annoying... I think we read enough about painful interviews. If anyone has a better way, please share... But it'd be nice to skip the ranting...
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'm giving paper coding tests that make sense to me, and I'm generally very happy with my recruiting. [...] I've passed people who completely screwed the test. I've failed people who nailed it in 5 minutes.
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.
Coming from the other side of the process, even if a question may be arbitrary (Although, I'd argue a lot aren't) it can still be helpful in evaluating a candidate's thought process. Additionally, using the same questions on multiple candidates is a good way to actually cut bias out of the system as you have a lot more data points to evaluate responses against.
Why so defensive? This is actually a very close representation of Google hiring funnel.
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.
> Speaks with an accent so thick you could spread it on toast
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.
I remember a phone screen where it sounded like the interviewer was calling from their hands-free headset in a moving convertible car. I pretty much could not understand a word of what was said. Asked if this was a good time, but he wanted to continue. It was a senior exec-y guy so cruising down the 101 was probably the only chance he had to talk. Company not interested after that call.
Having gone through about a hundred interviews on the employer side and a dozen on the employee side myself, I think I can drill down the essence of the problem to: "Everything that can be standardized is a bad predictor of hiring success."
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.
That favours people with high charizma and pleasant personality (not same as pleasant to work with) regardless of skills or work ethics. Compared to those, whiteboard or live coding is improvement.
Why have only one option that caters to those that can memorize algorithms? Have multiple types of interviews instead of forcing everyone to take the same type.
You can tailor the whiteboard problems to be something more than just memorizing algorithms. My company I'm at now whiteboarded with me bugs they found on my personal website.
Always this "memorizing algorithms" strawman. If you can't code basic list/tree/graph algorithms on the fly then there are serious holes in your programming ability. This has nothing to do with memorization.
But its not about the list/tree/graph algorithms, its about having the mental flexibility to code the algorithms on the fly. If you can't do a depth-first search on a tree after being given the definition and time to think about it then you may lack the mental flexibility to do arbitrary algorithms in any domain. Intelligence is unspecific to domain, and so showing intelligence in one domain correlates with outcomes in other domains. The list/tree/graph algorithms are just a microcosm of programming skill in general.
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.
> If you can't do a depth-first search on a tree after being given the definition and time to think about it then you may lack the mental flexibility to do arbitrary algorithms in any domain.
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.
The best interview I have had in recent times, I took my laptop along with me and showed some code I had been working on. The interviewer asked me questions about it, and I explained why I did it that way. He asked me to add a it of functionality to it and I did it there and then. That's real work that I had been doing, so I was familiar with it, he got to see me code. No stress for me, and I am pretty sure he god a better idea of my ability to code than any of the other nonsense methods described.
One thing I found out from interviewing a lot (for junior-ish positions) was that dynamic programming questions are actually your friend. Since it's a "hard topic" they give you a relatively easy one that can be solved using brute force recursion with memoization slapped on top so it takes like 5-10 mins and looks super impressive.
> When the candidate eventually offers a solution and asks for validation, fan the flames of their inner doubt by being non-committal and hesitant. "Yeah, that's sort of right, I guess that's good enough. Uh oh, looks like we're out of time! Do you have any questions?"
> Everyone that interacts with the candidate must offer a beverage or a trip to the bathroom as many times as possible throughout the day. Bladder manipulation is a powerful interrogation tactic.
Don't stop this. It's essentially harmless and in the case of certain people, welcome. You want your interviewers to think have empathy for your candidates. Interviewing is already stressful and a full bladder or dry throat makes it worse.
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.
This was the one that stuck out to me, though my take based on the tone of the article is that it's an easy way to pretend that you care, even if you don't. If you do have a caring process, this fits in just fine ("you doing ok? need anything?"). But if it's the only kind words you hear in the process it's sure to be weird.
Put water bottles on the interview table and offer the bathroom at the end of a stage of the interview, not as a "how ya doin', need anything?" introduction.
> "I see your background is in artificial intelligence, you've written your own compiler, and you maintain an open source project - how nice. Now implement radix sort using only red-black trees."
Sadly this quite could almost be pulled right out of a real tech interview we've all had.
I failed a technical interview recently. I was asked to write a rule engine, so I opened up Google and read about all the best ways about doing that for about 15 minutes of the interview.
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.
My understanding (somewhat limited), is that you would never want to use a radix sort with red-black trees, as a tree should already have some sorting to it as is. Otherwise, why not just used a linked list?
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.
Don't forget to treat everyone the same on the technical questions, whether they are a new grad with no professional experience or a 20 year veteran with a proven (and easily verifiable via references) track record of success. Make sure they all run the gauntlet!
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.
> Don't forget to treat everyone the same on the technical questions, whether they are a new grad with no professional experience or a 20 year veteran with a proven (and easily verifiable via references) track record of success.
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.
It needs to be a different style of grilling, based in their career. I don't remember how to write a bubble sort anymore, let alone other algorithms, those memories have been replaced by much more relevant information.
I am, almost, a 20 year industry veteran. I have no problem being asked to run the gauntlet. I'm happy for a chance to demonstrate my skills. Candidates that expect some sort of preferential treatment due to the number of years they have been working arouse my suspicions.
But don't expect a senior dev to have red-black trees memorized. A senior dev's answer will be "Use the library implementation. If there isn't one, look for one online I can use. If there isn't even one of those, look it up in Knuth." With no apology whatsoever for not knowing how to do it off the top of their head, because they know they don't need to do that.
I don't expect anyone to have red-black trees memorized. But I do expect an engineer at any level to be able to, say, rebalance a binary tree through brute force.
I have to admit, my initial reaction was about the same as yours. But after a minute or two of thought, I did know how to do it, even though I haven't ever (directly) used a binary tree in 30 years as a professional software engineer.
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.
This is so painful to read after having recently gone through the gauntlet of Bay Area tech interviews myself. It seems like all the companies follow this exact same pattern of how interviews are conducted and few stray from the standard, not realizing how intimidating the entire process can be for the uninitiated. It's easy to say "the interview process is broken", but how do we fix it?
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.
You can actually waterboard me during the interview, while asking to describe an implementation of recursive quicksort in the newest CSS framework du jour - and as long as at the other end there's a personal office with doors that close waiting for me, I'll send my resume in a heartbeat.
The internet is not short of open letters from developers despairing of the broken recruitment process.
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.
Indeed, I'm in the Midwest and my equivalent San Francisco salary is $240k, straight salary before bonus. The tech is old and shitty, but a lot of companies are in a position to modernize or die. Senior devs are in high demand.
If I found out that my recruitment agency had been treating my candidates this way, I would take them to task and then fire them. That's my reputation they are squandering.
Frankly, all a tech recruiter needs to do to earn a gold star from me is to spell my name right and have a job req that would at least, theoretically, be in the same building as the job that I am actually qualified to do.
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.
I learned to hang up dryly after 1 notification the interviewers were going to far, or leave a room after reading the technical tests and seeing it was crap. Now I feel better.
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.
One thing I always thought would be interesting (but no idea if viable): allow trusted engineers / seniors who have been in the company for a certain time to vouch and directly push a referral through to the final interview stage. Something like a joker. You could also link the referrals performance to the engineer directly and limit the joker to one per year or something like that.
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
I've done a lot of interviewing and do hit a lot of these but it's kind of the unfortunate 'state of the art' for figuring out whether to hire someone. For example, phone screens are often less than a hour (because most applying to us are likely already working somewhere else) but we need as much data as possible. They're done from a script because we want a consistent metric to iterate on and it's really important we get a good read because on-site interviews are incredibly expensive, especially for a smaller company. It'd be great to just call up and chat about personal projects or whatever but it's just too inconsistent and subjective.
Don't give them any updates for weeks, if at all. Who will appreciate hearing back from your company more: Joe Shmoe, or Joe Solitary Confinement?
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.
These take home projects are a bit inconsiderate to a candidates time. I've done a few and if you don't watch your time. You could be spending 5-6 hours just trying to please people
Yes, I did one for a crappy company three weeks back. Still haven't heard a word from them after the following face to face interview. Fair enough if you didn't want me, but I spend a day of my weekend doing that shit for you.
> Mildly ill; interminably coughs, sniffs, or sneezes
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.
I swear I saw a paper on here a couple months back about some weird negative correlation between intelligence and tendency to breath through the mouth rather than nostrils. Like, somebody had managed to provide evidence that mouth-breathers are stupid.
Do major tech companies ever consider randomly pulling an employee from another department not well known and subjecting them to the interview process as a QA sanity check?
Dont forget the recruiters with their standard template of tech/behavioral questions at the start of every round.
"How do you find the inode of a file" or "Can you calculate 2^23 without using a calculator" or "tell me what drove you to apply to our beloved unicorn. What makes you worthy ?"
>> I have given up entirely on interviewing for SV companies, and work 100% remote now.
Most of the people that I know that work remotely have preferred to work for SV companies, because they pay substantially more. What has your experience been?
Unfortunately, the companies that DO have a better process maybe have better retention and thus don't need to hire so much?
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.
due to timing constraints I had to most recently end my search at google's host-matching stage, I do wish the process didn't feel so one-sided. oh well, perhaps next time.
Surprised I don't see my main pet peeve - early reference check. Before I even talk to anyone I'm asked to provide three phone numbers of three former managers. So I have to call them up, make sure the number is still working, and ask for the favor that they can give me a reference in case anyone reads my application.
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.
> That is, scheduling the in-person interview. If a company is flexible, I could take an extended lunch and have an interview (or better yet, go after normal business hours).
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.
I assumed someone habitually goes to 10 interviews a month, even if they have a job. I want an employee who works, not is constantly looking for some new gig.
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.
How many applicants do you interview per position? I assume it's more than 3. Why wouldn't it be fair for a job seeker to consider just as many possibilities as you do?
Not sure if any of that makes sense. If a candidates wants a job they need to interview. Not all interviews result in offers. My experience has been it's about 10% or so, depending on how good/bad the market is. So to get 1-3 offers you probably need to interview at 10-30 companies. What are you expecting?
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!
I got mad props when I wrote a simple scraper for one of the resume sites we were using that pulled reference info off resumes (oil and gas engineers like to put who they know on their resume) and stuck it into a spreadsheet. Happily, solving problems in that manner made me realize I love programming and led to me switching careers from that nightmare :)
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.
> This means that a recruiter, several engineers and a culture interviewer have to also be present after work hours
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.
> 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.
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.
My resume states point blank that references will not be provided until after the prospective employer agrees in principle that I meet the technical job requirements. I send out a lot of resumes, and I am more protective of my references time than I am of my own. I don't want people wasting their time with useless phone calls because of me.
Strangely enough, whenever a company gets past that point in the interview process, most of them don't even bother asking.
> Surprised I don't see my main pet peeve - early reference check.
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.
The problem isn't your references blocking the process, it's that your references have to be bothered even if the company will have no interest in you, and that you have to go chasing them up every time you make a speculative application
Strongly agree with this - as someone else wrote, I respect my references' time (and patience) much more than my own in this situation. I've come to regard early reference checks as a "no go" and have broken off with potential employers over them.
I would say that the alternative to that crappy process is something like "gradual hiring" (sorry, I'm the guy whose accent can be spread on bread) - you just start working with a guy, giving him basic isolated tasks, and as he successfully progresses with his work, task are getting more and more complicated (salary, permissions as well). After few months of such freelance-ish work you can know for sure that this dude is compatible with the team, able to solve problems, able to learn. And only then he becomes an employee with offer, benefits and SO.
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.
'gradual hire' sounds great in theory, but it is going to be a pretty unattractive option for a lot of developers. One problem is the lack of certainty - why would I get 'gradually' hired somewhere if I have other options where I can get a permanent job right away? The bigger problem is the lack of benefits, which presumably includes health care. In the US, at least, this would make it pretty difficult - buying insurance on your own can be very expensive and going without it is risky/costly, so it would be a pretty big problem for a lot of people, especially those with health problems or a family.
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.
Well, there can be options, like "we're paying you a decent salary, and compensate insurance, but we can stop working with you within one day".
The most important difference here is that company don't risk much. And the candidate don't need to quit his current job: just do some tasks 1-2 hours a day, for example, so it's not just "gradual hiring", but "gradual quit" as well.
That's an unacceptable offer for a lot of higher-tier developers. Literally un-acceptable - I'd never get poached by a contract-to-hire, especially one with no benefits. And even if I was forced to accept such a situation, I'd continue to send out resumes and take interviews while on contract-to-hire.
Agree, I wouldn't do that either. For those russian guys it's bit different though, as they are already hired, with decent salaries and benefits (for Russia). Moving to HQ is just a big (and questionable?) bonus.
Agreed, it'd be tough to leave a company where things are going well to become a contractor at a no-name company. I also think I'd be much less willing to make a jump unless I had met a number of the current employees and founders and felt it would be a culture fit.
> you just start working with a guy, giving him basic isolated tasks, and as he successfully progresses with his work, task are getting more and more complicated (salary, permissions as well). After few months of such freelance-ish work you can know for sure that this dude is compatible with the team, able to solve problems, able to learn. And only then he becomes an employee with offer, benefits and SO.
Careful not to presume or disseminate the idea that all candidates/hires are men.
Would you have made the same comment if GP had qualified everything with "she"?
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).
It's an interesting thought experiment, if the original poster had qualified every statement in a different way...
"you just start working with a white person, giving the white person basic isolated tasks, and as the white person successfully progresses with their work, task are getting more and more complicated (salary, permissions as well). After few months of such freelance-ish work you can know for sure that this white person is compatible with the team, able to solve problems, able to learn. And only then the white person becomes an employee with offer, benefits and SO."
Now, I'd like to declare right up front I don't think the original poster was trying to exclude women. I think the original poster just wasn't thinking about their writing at all.
I think that's all the parent post was getting at--people should think more when they write, and make sure they think about what they're saying.
I feel sorry for your illness, really. "Bad english - fine, controversial hiring practices - fine, but he's using 'heavily gendered language' - alarm, take your pitchforks!"
I read through maybe 10 paragraphs, but the author's toxic style was just too much for me. Spoiler alert: this person sounds like someone I would never hire on attitude alone, which reeks of "entitled, sarcastic brat".
Alright. The article feels like light-hearted satire to me, and is the funniest thing I've read in a while. I'm surprised to see you associate it with entitlement and toxicity. I guess we have different types of humor. :)
- 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.