The author hasn't had the more dynamic interactive form of tech interview that I (as a platform dev) am used to.<p>> Coding is solving problems. A big part of that is looking stuff up. Like, seriously, the most important skill a developer can have it knowing how to research solutions to problems. Specifically…<p><pre><code> Breaking problems into parts
Identifying what to search for
Knowing how to sort good info from junk
</code></pre>
Rather than have them Google things, there's an open dialog with the interviewer where the candidate thinks out loud and the interviewer gives the 'search results' for them to use now, later, or not.<p>The interview is not about 'if' the candidate can solve the problem. Even it they don't the result can be positive. It's about how they think, break things down, compose the parts into a solution. No one should care if you memorized the syntax of anything.
Posts like this pop up pretty frequently. The format is usually…<p>> I hate tech interviews, they’re a poor proxy for real work.<p>> Here are some ways they’re silly (some examples follow).<p>> A good interview would not have these bad features, maybe someone should do that.<p>What I’ve observed in 12 years of practice is —<p>It works; things go south quickly if you don’t do rigorous technical interviewing.<p>There is huge variance between interviewers, in both accuracy and bedside manner.<p>The most effective signal by far (close to 100%) is: someone I already trust technically who has worked with them says they’re good, and is willing to stake their reputation on it. I enthusiastically skip the more tedious parts of interviewing in these cases.<p>Interesting things I’ve seen, experienced, or practiced:<p>Long trial contracts to hire, no exceptions. Buys you accuracy at the cost of reduced candidate pool.<p>Willingness to fire quickly (first 30 days) — in practice similar to above. This is often advocated for but rarely implemented.<p>De-emphasize interview, heavily game-plan and weigh reference calls; do a lot of them (5+). This works if you have the technique to blow past the boilerplate endorsements.
Probably very controversial opinion, but so far, my favorite type of interviews have actually been take-home problems.<p>Of course, it sucks if you've invested time into those, and get ghosted afterwards - but luckily I have yet to experience that.<p>Some people excel on taking test, some people excel on projects, others in both - I've personally never been the type to perform well on banging out code on whiteboards, but I will perform well on projects.<p>edit: Let me expand a bit on this<p>All my take-home problems have been very reasonable. Usually they've been more big-picture / architecture oriented, and not some specific implementation - some coding, some presentation, usually takes 2-6 hours to complete, depending on how much you put into it.<p>It is of course unfortunate if someone decides to code up something for a whole weekend, like 20-30 hours, only to get ghosted or similar. I guess it comes down to identifying free work from actual interview problems.
Hold on, how are they “fundamentally broken” if the author is happy with the format with just a slight tweak (allowing use of Google, which many places do already)?<p>I see that phrase a lot and it’s often deployed without a great deal of thought, which is a good indicator that what I’m about to read is a pretty low-effort article, blog post or tweet.
This is one of my favourite tweets: <a href="https://twitter.com/mxcl/status/608682016205344768" rel="nofollow">https://twitter.com/mxcl/status/608682016205344768</a><p>I've seen some rather complex problems being asked in interviews. I've always wondered why my credentials don't seem to matter when it comes to programming skills. I have a masters degree where i did some very tricky algorithms and I even open-sourced it for all to see. But every time I've been looking for a job, i have to rehearse some leetcode problems so that i can put on a good show for 45 minutes.<p>I get that deep-dives matter a lot and i can respect some of those exercises. These are crucial for senior positions since ideas are more important than code. Then I really get the life story kind of interviews because relating to coworkers and culture fit are hugely important.<p>It's just the dang leetcode that ticks us all off isn't it?
The tech interview process is different for every company but it's definitely not broken.<p>As a CTO, one of the things I look for is experience. You can look up all the "basic shit" you want but if we're talking about a specific problem, I want you to be able to give/walk me through a solution even if we don't finish the problem. If I'm interviewing a senior engineer, I want you to be able to show your seniority one way or another, if we talk about architecting something, I want you to be able to talk about why we want to solve it this way, pros-cons etc. Experience also shows me that it wouldn't take you a long time to solve the problem, and in our industry, at least my experience in startups, speed is key.
If the title was a comment, it would be breaking the site guidelines.<p>More importantly, it's throwing out absolute opinions on why interviews are broken without demonstrating a real problem. There have been hundreds of articles saying hiring/interviews are broken because <logic/opinion>, and almost none that point to data showing that companies are not able to hire developers, nor that developers are statistically unable to get jobs.<p>Interviews can be difficult and frustrating for both sides, but that doesn't mean they're not working. Despite the fact that the article is correct that looking things up is routine in a dev job, I still may prefer to hire the candidate who doesn't need to during my interview question that was specifically designed to not really need to.<p>I don't know how often coding challenges disallow using the internet, but the last time I interviewed it was allowed. I've seen lots of companies allow use of any language, and spend your time searching the internet if you want.
> I understand why interviewers do this. They want to get a sense for what candidates actually know versus what they’ve copy/pasted from the web.<p>Bad assumption. If you really did understand why , you wouldn’t say it’s stupid (unless for clickbait).
One thing I rarely see talked about is that the people doing tech interviews just plain suck at interviewing. Everyone assumes intent; that interviews go a certain way because someone has decided they should go that way. While that is quite possibly true at FANG, in my experience it's not the case elsewhere.<p>Interviews at most companies amount to "hey, who wants to/can interview someone next week?" Some people volunteer, and then they wing it. They might do a FANG-style interview because that's what they think they're supposed to do. They might parrot whatever the interview process was when they were hired. They usually just wing it, making up questions as they go.<p>It's not normally intentional or nefarious. Good engineers don't often make good interviewers. Sometimes they don't want to be doing the interview, and are simply trying to bumble through it. Usually, they have the best intentions, but they don't know what they're doing. No one's prepared them; they haven't prepared themselves (and likely don't know how to). Everyone usually has good intentions. They want to give the candidate a fair shake; they don't want to make the wrong decision; they want to find a good coworker; they want to do their employer a solid by finding the best employee.<p>I know I suck at interviewing, despite doing it dozens of times. I've had a few regrets about people I've hired, but not many. Whatever failures my process has, I don't think they're too egregious. I've been on my own to figure out what works and what doesn't.
Just ask them to articulate technical concepts, so you can know whether they are full of sh*r not.<p>People who can hold targeted low-level technical conversations are generally well equipped to do the work you are expecting him/her to do.<p>What's wrong with this approach?
I'm lead dev on a rather large frontend project, and I still feel like I'd struggle in a frontend-focused interview today. Underappreciated by many I think is the ability to solve problems. I solve them (almost) every day, but sometimes it's easy, and sometimes it's really tough. But eventually, if you know how to ask the right questions, you'll get to a workable answer. That kind of real-world experience doesn't seem to surface well in a typical interviewer/interviewee type setting.
I see posts like this all the time on HN and I really wonder if there's an alternate world of really stupid interview practices out there that I've just been lucky enough to avoid.<p>In this case: I've never heard of, participated in or administered a programming interview where the candidate couldn't Google things.<p>I remember when I interviewed at Braintree, I spent a good chunk of the pairing interview searching for Linux command syntax because I was new to using it. I got the job and spent 7 years there.
As others have mentioned, this is more a sign of bad interviewers than a bad format. Of the companies I've worked at, at least one has allowed googling during the interview, and most de-emphasize all the stuff you have to look up in order to focus on the problem-break-down part of the question.<p>I think there's too much imitation without understanding in interviewing. Candidates hear questions, and then go on to repeat them when it's their turn to be interviewers, without really understanding what's behind the question. These new interviewers then approach the interview as if they were administering a coding test, whereas what they ought to be doing is facilitating a conversation using the question as a starting prompt.<p>The other problem that I see sometimes with interviewing is interviewers asking obscure questions. Really good candidates aren't solving the problem on the spot - they've come across problems like the one the interviewer asks, and are using approaches they've already validated in their life experience. When an interviewer asks an obscure question, they are not helping to facilitate a conversation as to whether the candidate can handle the typical things that would come his or her way.
I find that pair programming with the candidate on their laptop, using their preferred tools works well.<p>It takes time and in many ways it requires more energy from me than if I were to just sit and observe. However, it gives a better feel for how the person goes about solving problems from the abstract, architectural stuff to the nitty gritty. I love it when pairing with a fellow vim-user as I will inevitably learn some new trick.
After convincing the boss to fire a guy who laughed at me using vim saying it was really old and then proceeded to push broken code to production at 4am, trying to blame it on me when the logs were really not in his favour, I ended up in the position of doing the hiring for a guy to replace this yahoo. I live in a country where people's resumes fit in a damn manila envelope because there's just SO MUCH emphasis on degrees and stuff like that, and while the education here is pretty good (A lot of focus on hardware in the compsci curriculum here actually), really all I wanted after rejecting a bunch of prospects for technobabbling bullshit at me with their huge, multi page resumes i barely read was someone to tell me humbly enough that he'd just have to google the solution to the really damn easy fizzbuzz i was presenting them. You know how hard it was to find that in a braindrain situation? My boss thought I was being too mean, but really I just can't work with dishonest people. It's the most important thing to me that I actually like my coworkers for being good people. A coding interview of the MOST BASIC kind can act as a sort of filter for this.<p>Like sheesh, I'm not looking for this:<p><a href="https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition" rel="nofollow">https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...</a><p>All I want is to know if you know how to work with a modulo operators or not in an honest way, if you know basic third grade level integer division with remainders. If you give me bullshit instead of that, chances are you're not going to get hired. A probationary period for a couple of weeks after on the job after that to see how good you actually are, paid, with the knowledge that if you're just a terrible programmer you don't make it past that.
One of the companies I interviewed with did what he described and it was nice. I thought the cool thing was that in the second interview they wanted me to walk them through some of my thought process for why I did/searched for certain things.<p>I didn't end up taking the job, but boy was it a breath of fresh air compared to some of the other interviews I've done.
Point of the interview should be to asses knowledge and thinking process, and many other things. Definitely, it is not easy, as in one hour someone needs to assess that person is not faking his entire working history, and that has acceptable skills for the certain role.<p>One of the good interviews I had was with few people DB/Architecture/Testing/Coding at the end they had combined overview. Usually when I am interviewing I would allow everything, as I am more interested in thinking process of attempting to solve something than actually giving me some clever solution in extra limited time.<p>For me it is interesting that many companies have decoupled skills vs. money paid for those skills expectation, and often they would like to have star workaholic developers but only if they could pay them as McDonald employees. What I am trying to say, don't have an interview like you trying to employee in Google if you are are not prepared to pay those people like the Google.
Looking up things isn't solving problems. Sometimes you need to look up things to solve problems but they are fundamentally unrelated. Coding interviews generally require 0 background (other than base CS principles) so you shouldn't need to look up anything. I've never had someone ask me for correct syntax in an interview setting.
As a job searcher, I want to be able to spend as little time as possible on the interview process for one company. I don't mind researching the company or talking about their specific process, but I want to minimize the amount of time I have to take to prove my competence to them, because that's something that should transfer well between the different roles I'm pursuing.<p>I understand that not everyone has an OSS portfolio, but it's better than having 5 different companies give me a unique take-home project, and then having another 3 companies give me an algorithms assessment. If everything was "let's take a look at one repo you've spent <10 hours on" or "let's do leetcode problems" that would be preferable to the current state of affairs, because as it stands I have the worst of both worlds.
Our tech interviews focus on watching you work the way you actually work: Google allowed, your IDE of choice, your boilerplate project templates, etc. Yes, you still have to show progress against a problem in 30-60m -- but sometimes rapid prototyping is important to the job!
They are missing the point.<p>Coding interview has very little to do with Code!<p>I hire a lot of developers and the code interview is a pivotal point in the process. This is where I find out how you collaborate, take new ideas and incorporate them, deal with changing requirements, handle criticism etc.<p>Of course I am validating you actually know how to code but I am really looking for the rest other skills because this is what will make you a valuable integral part of the development environment here.<p>Trying to throw a 'stump the jock' type of question at a developer is worthless and only proves to show how well they memorize things.<p>Throwing them a difficult problem that requires them to research, ask questions, collaborate will show how well they will grow and take on new challenges they are uncomfortable with.
I disagree that coding challenges are stupid, I actually find them having some of the best signal-to-noise ratio of any step in the interview. Maybe it depends a lot on what type of coding problem it is?<p>One important aspect of doing the coding interview well is to make it generic enough and not look for a specific exact solution, so things like "write a function for a movie theater ticket dispenser" vs "write the most efficient string reversal" function.<p>I am also totally fine if a candidate needs to look something up, but I don't think it is unreasonable to expect candidates to be able to work though a general coding exercise without needing to stop and google things frequently. Especially if they can pick their own preferred language!
Some context, first: I work on infrastructure software. I'll try to define it so it's not so vague: software that is core to the company's platform that has strict performance, stability, and FMEA guarantees. Often the skillset we look for is niche, you need systems skills (broad spectrum, both OS and network) as well as software skills (preferred polyglot; "languages are tools" kind of people).<p>On one hand, I deplore the runaway game that software has let algorithmic knowledge play on our minds. People destroy themselves preparing for interviews at large firms on exciting teams, only to get blown away because someone threw them a curveball in algorithm or systems design knowledge. On the other hand, I've watched developers copy solutions on one screen and transpose them on another. I've hired engineers only to find out they <i>only</i> know the kind of information we would ask in an interview and how to bullshit.<p>College will never provide my team the guarantees we need to make a hire, that much is well-accepted. Being from a "top tier" company is no guarantee either. What I do think is worthwhile is investing in two things simultaneously:<p>1. An apprenticeship program. I entered software (and mathematics in general) without a degree. These subjects can be learned with self-discipline and having a career that gradually increases in complexity is a perfect aid to this learning process. In my path, it produced a generalist software engineer with a specialty in systems engineering. In another, it could produce a web backend software engineer, a frontend engineer, an infrastructure engineer, etc...<p>2. A certification exam. I mean something orthogonal to Professional Engineering or the Bar exam. Something entirely divorced from colleges that can prove you can negotiate algorithms and data structures. I believe people who are keen enough to figure this out once can figure it out again when the time is needed, however, in most cases your brains will be put to more abstract talents that are non-numerical in nature. Reserving your sanity for then, rather than depleting it all throughout the interviewing process over the course of your career seems to me to be the optimal choice.
The problem result is not the goal of the exercise, I don't care if you solve it, but rather how you approach it.<p>Note that I don't use puzzle problems, but more open-ended ones that elicit discussion and architectural approaches rather than simple coding.<p>When I'm interviewing I'm google for all intents and purposes.<p>I want to see how you interact, what you're thinking and how it would be like working with you as a team member.<p>I look for potential and red flags. I try to find out two main things:<p>- will you be good for the team?<p>- will the team be good for you?<p>It's a two way relationship we're trying to build here.<p>Interviewing is a lot like speed dating, we're trying to find a long term partner in a very small amount of time.
This is a bad take. Coding interviews help you see <i>how</i> someone solves a problem. And good coding interviews let you search for whatever you want except for "how to do this problem in x language."
I like the idea of letting the candidate do whatever they would if they were actually coding. I even think it could be interesting (in the initial part of the process) to ask the candidate what question they would like to be asked, and let them implement that.<p>Few things to point out though:<p>1. you can ask the interviewer questions<p>2. the problems are usually simple enough that you don't need to google them, and should have prepared for them in the first place<p>3. you should be somewhat efficient (being able to do basic stuff without googling) in at least one language, since you can choose the language for the interview do that
When I interview using coding problems, you just need to know very basic Java or python to solve the problem.<p>We also nudge interviewees in the right direction to make sure they don't get stuck, which would be in no ones interest.<p>There is also no hard requirement that you need to solve the problem completely. If you talk to someone for 45 minutes about a coding problem you will get a good sense of their performance, even if they don't solve the problem.<p>Coding interviews are great (except making the intervieww very nervous), but you have to be mindful as an interviewer.
There is a limit to the proposed approach. Most interviews I conduct (algorithms) include puzzle-like problems. So if you just Google them - you would find a complete answer. In that case, what's left for the interviewee to solve?
(Whether algorithm questions should be a part of the interview cycle is a different matter.)
Poorly written blog post. What an elaborate way to say "let me google". Except for hackerank type of interview, I've always been able to google or ask interviewers to help me out.<p>Just have some communication skill and communicate in the interviews, they want to test that in you too, rightfully so.
I much prefer interview styles where the candidate and the interviewer just talk about a technical solution they've solved in detail (challenges, architectural decisions, etc...). It'll become evident fairly quickly if the candidate doesn't know what they're talking about.
Where are you interviewing that they don't let you google stuff? I've gotten to the point that I don't even ask anymore, I just open a new tab and explain what I'm looking for. If the interviewer takes issue with it that's a big red flag for me.
I find the 'take home exercise' to be tolerable. I hate the live coding things. Those are awful.<p>Even the take home things are not fantastic, though - if you already have a job, a family and other stuff going on, "just 4 hours" is kind of a PITA.
I want to take one of these interviews just to look the interviewer in the eyes and ask one question.<p>Since I'm not allowed to google stuff now, would that mean I won't be allowed to do that while working for your company as well?
> I understand why interviewers do this. They want to get a sense for what candidates actually know versus what they’ve copy/pasted from the web. But this process is stupid for a variety of reasons.<p>That's not how I understand them. I always saw them as a way to see if the candidate is ready to invest a certain amount of time and energy. A bit like "if you can grind leetcode and pass the X interview, you can probably contribute to our codebase".