TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: How to not fail on coding interview questions?

206 pointsby evoneutronalmost 7 years ago
I&#x27;m a mid-senior level software engineer with 5+ years of industry experience and making $100,000+. I don&#x27;t consider myself a bad software engineer, and yet I can&#x27;t seem to solve some basic problems on a white-board in 30-60min (i.e. traverse a heap, merge sorted arrays etc).<p>I joined my company as an intern ~5 years ago &amp; when I interviewed for the position I didn&#x27;t have to solve any white-board style interview questions etc., since it was an un-paid internship. After a few months I had demonstrated my ability to write code they made me an offer.<p>When I now casually look around and apply for mid-to-senior level positions I cannot seem to get past phone (coding interview) part, that involves solving some basic algorithm on collabedit. I get nervous and given I need to solve (perhaps a simple) problem in an optimal&#x2F;sub-optimal way in 30 minutes, my brain sort of shuts off and I cannot arrive at a clean solution, let alone solve the problem end-to-end.<p>I&#x27;m respected within the company, if you were to ask any colleague I have worked with whether I can write clean testable code that solves real business problems, everyone would attest that I absolutely can.<p>How do you create that environment of - &quot;Coding under pressure and someone looking at your code while you&#x27;re trying to think of how to solve a problem and your brain is thinking about everything other than a problem itself&quot;???<p>One idea is to just keep applying and failing until I become immune to it. But each failure kind of brings me down, and makes me think that I&#x27;m a bad engineer.<p>Last thing I want to mention is that I don&#x27;t blame the process itself. I think white-board style questions eliminate a lot of bad candidates. I know that the process has to be rigorous because those jobs pay well. But there&#x27;s also extreme examples like the inventor of homebrew that got rejected by google because he couldn&#x27;t reverse a binary tree.

48 comments

jaredklewisalmost 7 years ago
I honestly feel you’ll get horrible advice from HN. Many here feel too strongly about the process itself to give objective advice, as almost everyone here has probably been screwed over for no good reason at least once.<p>What’s your goal? I assume, get a new, higher paying job. What’s the barrier? Interview style coding problems, apparently.<p>So, things that will help you achieve your goal (IMHO):<p>- Buying and reading cracking the coding interview<p>- practice solving problems on sites like hacker rank and leet code<p>- when you practice, try simulating interview conditions. Use pen and paper or a whiteboard if your interviews will involve that<p>The more familiar and mundane the problems become, the less likely you are to feel nervous with an audience. Just practice the problems until it is like tying your shoes.<p>If asked to tie your shoe with someone watching, would you be so nervous as to be unable? If so you may have some serious anxiety issue you might want to work on before starting a job search.<p>Things that definitely won’t help you achieve your goal:<p>- ruminating on life’s injustices<p>- ruminating on your own shortcomings<p>- comparing your self with others<p>- ruminating on the decidedly capricious and error prone hiring practices of Silicon Valley companies.<p>Life is not fair and there is a time and place to think about those things. But doing so is counter productive to your goal, so I wouldn’t recommend it at the moment.
评论 #17340610 未加载
dalyalmost 7 years ago
BALL-PITS and CLOWN NOSES<p>I worked with a guy, Bob, in our college computer room. Bob had returned to get his BS after many years in industry. He had great stories. He also had great advice. He taught me that you can learn a lot about how a company will treat their employees by paying attention to the way they treat you during the interview. He suggested several sign that indicated it was best to just &quot;walk away&quot;.<p>If you go into a restaurant for a professional lunch meeting and they have a ball-pit &#x2F; swing set &#x2F;etc. it might not be the most professional place to hold the meeting. Just walk away.<p>If you go to a 5 star restaurant and they want you to wear a clown nose (Everybody Does It!) Just walk away.<p>The big scam is &quot;We hire the best and the brightest&quot;. &quot;We mandate a whiteboard test (Everybody Does It)&quot;. It is my opinion (based on experience) that companies that insist on a whiteboard test, despite years of programming on your resume and open source code, are either Ball-Pit companies (who don&#x27;t know what it means to be a professional) or Clown-Nose companies (who know what it means to be a professional but still treat you like a commodity). Just walk away.<p>I understand why Google does it. I&#x27;ve even interviewed there. They get thousands of resumes (which they never read, at least nobody did at my interviews). They have to weed out the &quot;learn coding in 6 weeks&quot; crowd. But you&#x27;re a professional. You should expect to be treated like one. You don&#x27;t ask your surgeon to cut up hams in an interview. You don&#x27;t ask your builder to nail two boards together. Professional accountants are not interviewd by bank tellers and ask to count change.<p>Google, like Microsoft before it (remember the &quot;why are manholes round? quizes?&quot;), have combined the marketing claim &quot;We hire the best and brightest&quot; with the ball-pit mentality of whiteboarding. Google HR (sorry, People Resource?) SHOULD be embarrassed but apparently they, and upper management, LIKE ball-pits.<p>A real professional interview involves a discussion about what the company does, what it current problems are (aka why are they hiring), and a discussion of if you, as a professional, have the skills to solve the problem. What do they need? How can you contribute?<p>We, as professionals, should consider whiteboarding as an insult.<p>Just walk away.
评论 #17335875 未加载
评论 #17335527 未加载
评论 #17337641 未加载
评论 #17339539 未加载
评论 #17336673 未加载
评论 #17359895 未加载
评论 #17337306 未加载
joshuakcockrellalmost 7 years ago
&gt; But each failure kind of brings me down, and makes me think that I&#x27;m a bad engineer<p>First off, you are not a bad engineer for failing a technical interview. Over the past 3 years, I&#x27;ve applied for hundreds of roles across dozens of companies. I&#x27;ve been through dozens of interviews and I&#x27;ve got offers from (or worked at) Uber, Twitter, Microsoft, Tesla, etc. The side of the story I don&#x27;t focus on is that I&#x27;ve had over 200+ rejections. Some after first rounds, some just after they look at my resume. Rejection is part of the game but you just need to push through it. Here&#x27;s my advice.<p>- As other comments have said, it&#x27;s definitely a numbers game. Some days you just don&#x27;t mesh with your interviewer, others you know the answer to their coding question before they&#x27;ve even finished asking it. Just apply over and over if you want the best odds. You can&#x27;t get too emotionally attached to any single interview opportunity. I&#x27;ve had to apply for ~50 roles for each offer I get. That&#x27;s just the way it works.<p>- Practice a ton. It sounds like you are more worried about coding under pressure and thinking through the answer while you are in the middle of trying to explain your thought process to the person interviewing you. I recommend pramp.com You interview someone for 30 minutes over the webcam and then they interview you for 30 minutes. It&#x27;s super convenient and gets you very comfortable thinking through problems on spot with someone else watching you. I normally do ~10 pramp.com interviews while I&#x27;m preparing for an upcoming interview. In person interviews with friends is good too but less convenient than just signing up online for a time slot.<p>Just remember that bad interviews don&#x27;t make you a bad engineer. At the end of the day, no one will remember dozens of rejections, but they will remember the job you eventually land. Keep interviewing till you get an offer that you&#x27;re excited about. Good luck!
评论 #17334148 未加载
评论 #17334109 未加载
koala_manalmost 7 years ago
&gt;there&#x27;s also extreme examples like the inventor of homebrew that got rejected by google because he couldn&#x27;t reverse a binary tree.<p>HN has rehashed this debate plenty, but I don&#x27;t think you should necessarily see this as an example of a dramatic failure of the Google SWE interview process.<p>Homebrew became a success due to great vision and execution, not because it solved a challenging technical problem. Howell seems like a great guy who would probably make a great senior developer, founder or PM at any company that aims to solve customer needs.<p>Google&#x27;s focus, however, is on hiring SWEs that can solve uniquely complex and difficult technical problems. The merits of such a narrow focus is obviously up for debate, but if that is to be your goal, this hiring decision aligns with it.
评论 #17334179 未加载
评论 #17334186 未加载
评论 #17334136 未加载
评论 #17335864 未加载
评论 #17337781 未加载
评论 #17334152 未加载
评论 #17334169 未加载
smnscualmost 7 years ago
I really enjoyed practicing on Pramp [1]. I ran through their whole batch of problems (roughly 40) so I can&#x27;t schedule more interviews, but it helped me a lot to work on the soft skills required for FAMG type interviews. Unfortunately I still didn&#x27;t pass the Google interview (had on-sites in Zurich) even though I was very well prepared. I also maintain (sort of lol) a list of interview preparation resources [2], although I find [3] to be even better.<p>PS: I also failed much easier interviews at CrowdStrike and SourceGraph so maybe I just suck at being interviewed in a way that&#x27;s not clear to me. It really takes a toll on your confidence though.<p>1 - <a href="https:&#x2F;&#x2F;www.pramp.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.pramp.com&#x2F;</a><p>2 - <a href="https:&#x2F;&#x2F;github.com&#x2F;andreis&#x2F;interview" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;andreis&#x2F;interview</a><p>3 - <a href="https:&#x2F;&#x2F;github.com&#x2F;jwasham&#x2F;coding-interview-university" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jwasham&#x2F;coding-interview-university</a>
评论 #17336656 未加载
togusa2017almost 7 years ago
Before this discussion starts between how the interview process sucks. Here is my 2 cents:<p>1. Pick up leetcode (or whatever rocks ur boat).<p>2. Do a lot easy questions and understand the pattern.<p>3. Do medium level questions and understand the pattern.<p>4 If you are aiming for Big 4 do Hard.<p>Coding interviews is all about finding the pattern and applying it. Only way to be good at it is practice. Don&#x27;t give interviews without some practice.
评论 #17333971 未加载
stuxnet79almost 7 years ago
It&#x27;s all supply and demand. The expectations from employers as to what a &#x27;qualified&#x27; engineer is likely to demonstrate within a 30 min to 1 hour timespan has increased. To get access to the plum jobs you have to be able to pass the gauntlet of interviews and this is something that&#x27;s not particularly easy if you don&#x27;t know the &#x27;game&#x27;. First thing to realize is that you don&#x27;t have to be a genius to pass these interviews, however it does require consistent practice and you will have to be dedicated enough to rearrange your life such that you are able to get in some practice on a regular schedule. Of course how feasible this is depends on your life situation. It is easier for younger engineers to dedicate their evenings and weekends to grinding Leetcode than older candidates.<p>My unsolicited advice is to:<p>A. Come to terms with the fact that there has been a shift in expectations from employers. Understand that to get the really plum jobs it will require a lot of dedication to get to where you need to be interview performance wise.<p>B. If you are really rusty, start off with Firecode.io. It provides a more structured approach to studying these interview questions. Once you feel comfortable with the questions there then you can go for Leetcode.<p>C. Go to interviewing.io and pramp and practice with actual engineers. This will allow you to work on your communication skills. A big part of interviews is just basic communication. You could be rock solid with your algorithms but if you still can&#x27;t communicate what you are thinking to interviewers in an effective manner you still won&#x27;t pass the screen.<p>D. It&#x27;s not a particularly popular corner of the internet but reddit.com&#x2F;r&#x2F;cscareerquestions has a lot of good advice on how you can improve your interview skills. It&#x27;s also a good place to get a sense of how interviews are structured, how people typically prepare, expectations etc. It&#x27;s skewed towards getting jobs at the FAANG type of companies but the good advice you will get in the sub is pretty solid and will help regardless of the direction you want to go.<p>Overall, try not to be too hard on yourself. Technical interviews are an inherently noisy screening tool, and a lot of great engineers fall through the cracks. Preparing for these interviews just like you would prepare for any other important assessment will help you in being more competitive.
评论 #17334556 未加载
neverminderalmost 7 years ago
Apply to companies that don&#x27;t do whiteboarding&#x2F;phoneboarding. I don&#x27;t know, maybe this is a US thing, or the Big Four thing, but down here in London I am yet to encounter a company that does whiteboarding.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;poteto&#x2F;hiring-without-whiteboards" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;poteto&#x2F;hiring-without-whiteboards</a>
评论 #17334535 未加载
评论 #17334490 未加载
评论 #17334145 未加载
mratzloffalmost 7 years ago
I&#x27;m one of the most low-key, relaxed people you might meet, which makes my test anxiety worse: since I&#x27;ve learned strategies to mask my anxiety around whiteboard coding, I just look incompetent when my mind goes blank and I can&#x27;t think clearly.<p>Contrast this to my daily work, which is often highly technical and high pressure in a wide variety of areas.<p>The tech interview is broken. The problem is that there aren&#x27;t many good ideas to replace it. Every large company is focused on eliminating personal bias, easing the process of training new interviewers, and improving repeatability. Pass&#x2F;fail-type challenges (or perhaps a simple grading system) are the easiest way to achieve those things.<p>Additionally, companies like Google and Facebook can absorb large numbers of junior candidates directly from schools. Most of these exams are geared toward those fresh from an academic setting.<p>Small companies adopt these techniques because they also want &quot;the best&quot; without actually considering their real needs. As a result, a cargo cult has arisen around making the technical interview increasingly long and baroque.<p>Here is some practical advice:<p>1. Talk to your doctor about your situation and tell them you&#x27;ve heard beta blockers[0] help stop the flight-or-fight response.<p>2. As others have said, practice over the course of months. Do the same problems again and again. If you can&#x27;t solve these toy problems without pressure, you definitely won&#x27;t solve them with pressure.<p>3. Ask the company ahead of time for a take-home as an alternative. Explain the situation.<p>Ultimately this situation won&#x27;t change until engineers in decision-making positions force it to change. Interviewers also need to be trained on how to recognize test anxiety and what strategies they can employ to ease that.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Beta_blocker" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Beta_blocker</a>
KirinDavealmost 7 years ago
Hi. I also feel this way when I&#x27;m interviewing, so please know that you&#x27;re not alone. Interview Anxiety afflicts a lot of us and it makes us perform much worse in interviews. The way that interviews are structured tend to hurt people as well, often deliberately trying to create a sense of inferiority in applicants to help close deals and negotiate rates. It&#x27;s an act, usually an intentional one!<p>One of the most effective ways I&#x27;ve found to deal with this is be open. Say, &quot;Yeah, I suffer a bit from anxiety and interviews in particular are difficult. Do you have a take home interview? I can easily commit to git in near real time if you want a blockchain-quality log of my process, and I&#x27;m happy to review it with an engineer.&quot; I have gotten a surprising number of takes on this (and in general I annihilate these).<p>As a bolster to your confidence, try not to take these too seriously as an indicator of your personal skill. Having worked a bit on my current and past employer&#x27;s interview process, tbh an awful lot of orgs have questions that are more like riddles than actual coding exercises; they often have a simple solution you have to &quot;know&quot; otherwise the problem is excruciating and every solution is obviously bad. Examples of this include &quot;chocolate bar&quot; division problems, skyline problems, or rainfall problems. All of them are bad examples.<p>We also enjoy a sellers market for many tech skills right now. In such a market, interviews can also be information for you to save your time not proceeding. This feels very strange for people normalized to the creepy feudal culture of tech where you align yourself with a company body and soul and only state laws allows you to escape their clutches, but it&#x27;s pretty powerful. If an interview seems deliberately excruciating, just say, &quot;I&#x27;ve seen all I need to see. Thanks for your time, but I don&#x27;t think you&#x27;re a good fit for what I&#x27;m looking for in an employer.&quot;<p>Finally, it&#x27;s also worth remembering that just modest reading in PL, CS and database literature written in the last 10 years often gives you ammunition to completely break down these questions. The folks that structure and ask these only seldom actually their theoretical basis. I&#x27;ve managed to break out of ugly and tedious interview questions by flipping the conversation to something I <i>do</i> know well and am confident speaking to, like modern O(n) sorts (discrimination, american flag), wavelet trees, recursion schemes, CRDTs and strategies for gossip protocols. Appeal to their greed and interest and show them that you DO know things, you just may not know THIS thing RIGHT NOW.
hal9000xpalmost 7 years ago
Here are my advices on how to train yourself for algorithm&#x2F;data structures interviews:<p>1. Others already recommended to practice solving problems on LeetCode;<p>2. While solving these problems don&#x27;t spend too much time if you got stuck, look for answer or discussion after hour or two;<p>3. If you feel weak on some topic (e.g. dynamic programming), try to read up related material, lecture notes, familiarize yourself with classical problems on this topic;<p>4. Even if you solved problem, look for other answers. You often be surprised how much shorter and concise solution can be;<p>5. Read some books on algorithms like Skiena or Papadimitriou. I don&#x27;t recommend you to read Knuth or CLRS unless you have strong math background. Skiena or Papadimitriou are much easier to read for beginner. Also, separately, I do recommend the book - Programming Pearls by Bentley;<p>6. Once you practised for two months or more, start taking mock interviews on Gainlo;<p>7. Enjoy algorithms and solving programming puzzles. Enjoying algorithms is a must because if you really want to master it to the Google interview level, it may take years;
atak1almost 7 years ago
Coding interviews is a performance-based art, so treat it as such. The best way to prepare for an on-stage performance? 1 Memorize your lines until you can&#x27;t forget, 2 practice with fellow actors, and then 3 practice with real interviews. 1+2 is practice. For step 3, concentrate on improv &amp; how to compensate for when you&#x27;re not at your best (aka you didn&#x27;t get great sleep so you forgot a line - what do you do?)<p>Same for coding interviews. Practice, then interview. 5-10 years down the line, every time you&#x27;re looking to switch jobs, it gets easier, and you get the insights from the past experiences.<p>NB<p>The phone screen isn&#x27;t easier than on-site; it can often be harder, and often is the same level of difficulty, with more pressure.<p>NB 2<p>If you&#x27;re mid-level they&#x27;ll ask a few systems design questions. Make sure for the systems you&#x27;ve built, you know at a high level how each individual component was built and what abstraction it stands for.<p>Good luck! And ping me at my tw email (check profile) if you want to follow up
tzsalmost 7 years ago
Several people have mentioned practicing on LeetCode problems. I&#x27;ve been doing LeetCode problems recently as exercises to refresh skills in languages I use infrequently but don&#x27;t want to forget too much of.<p>Here&#x27;s a tip that they either don&#x27;t tell you, or that I managed to overlook. You are allowed to mutate inputs.<p>I had assumed that inputs were read-only, and spent about three months trying to solve &quot;Given an array of N integers, find the smallest positive integer that is not in the array, in O(N) time and O(1) space&quot;. (It wasn&#x27;t three months of constantly working on it...it was more for three months it was one of my &quot;something to think about while falling asleep in bed or while sitting at a red light&quot; problems).<p>I then came across a site that talked about the problem and mentioned doing it in O(1) space involved overwriting the input. It was only a couple minutes to solve after that.<p>Possibly interesting variant of that problem: Can you still solve it in O(N) time and O(1) space if when your code returns the answer the input must be unchanged? You can still mutate the input while your code is running, but you have to undo any changes you make before returning.<p>I&#x27;m pretty sure that the answer to this is &quot;no&quot; in the general case, but if you are allowed to limit the size of the input so that N is not a significant fraction of MAXINT on your machine you can do it.
评论 #17336405 未加载
评论 #17337074 未加载
评论 #17341370 未加载
评论 #17337735 未加载
annon6182018almost 7 years ago
Posting as annon for obvious reasons.<p>I was in exactly the same situation you describe about 4 months ago. 5+ year work experience, making 100k+ and joined my company after an internship. Additionally, as an electrical engineer by training, I had little formal training in algorithms and data structures.<p>Here are some things that worked for me:<p>1. Interviewcake.com - worth every cent I paid for the annual subscription. It is an excellent resource - even better than the book “cracking the coding interview” in my experience.<p>2. Donald Knuth’s Art of Computer Programming - as a person without a formal training in algorithms and data structures, the classic text by Cormen et al was pretty poor. Knuth’s AOCP had much better treatment for multiple topics and really helped me understand what’s going on. (See the treatment on hash tables in both works for an example on the difference in quality)<p>3. Whiteboarding tips - (here is where my recent interviewers might be able to identify me) - You have to remember how whiteboards are more versatile than text editors. Use the whiteboard to draw things, make notes for yourself, analyze the question. I followed a process of writing and underlining these headings:<p>i. Problem : Reverse alphabets in a word stored as a linked list ii. Test cases: h-e-l-l-o iii. Algorithm: &lt;write down pseudo code&gt; iv. Final code<p>This might seem like a lot more work at first, but an organized approach like this really helped me complete complex challenges within 45 mins. Give this a try. It really helps<p>4. Resume polishing - Some former colleagues were very helpful in reviewing my resume and providing feedback. I saw a dramatic increase in the number of calls I received after revamping my resume.<p>5. Practice white boarding - Book a conference room for a weekend and practice solving 10 to 15 hard problems with a timer in the conference room. It makes an incredibly huge difference.<p>I am happy to say that with these, I went from being completely unprepared for interviews to multiple fantastic job offers in the past 4 months.
soreallyalmost 7 years ago
I&#x27;ve gone through about 6 coding interviews in my life and I failed one. I&#x27;ve given hundreds of interviews, many at some of the biggest companies.<p>Here&#x27;s the thing. There aren&#x27;t that many different kinds of problems that you&#x27;ll be asked to solve. The recipe for 80%+ of the interview problems I ever see is this:<p>1. You have a data structure (tree&#x2F;array&#x2F;matrix&#x2F;graph&#x2F;string) that may have some special properties (sorted? directed? etc?)<p>2. You solve one of a few classes of problems: * Find an optimal &lt;blah&gt; (shortest path, highest value node, longest subsequence, etc) * Mutate the output in some interesting way based on the values<p>3. You do that using some other data structure (Queue, Stack, Hash, Heap) or technique (dynamic programming, recursion, etc) for efficiency.<p>There&#x27;s probably also a brute force solution you should be able to implement and that shouldn&#x27;t take too long to do.<p>My point is, these interviews should be easy for a good candidate because the fundamental problem space for a typical question isn&#x27;t huge and there&#x27;s tons of places to practice online. For most interview problems, you should be able to say &quot;Oh! I recognize the general shape, I can apply a few primitive patterns together and get a solution that&#x27;s basically correct, and maybe I&#x27;ll have to tweak it a bit to optimize it later&quot;.<p>Instead, I tend to get candidates with 15 years of experience who think they&#x27;re so hot but somehow can&#x27;t implement a trivial depth-first search. I don&#x27;t want to spend the whole interview on trivial coding problems. I want you to finish that part in 15 minutes so we can spend the rest of the time on interesting topics and technologies.
nunezalmost 7 years ago
Right, so most of the problems in coding interviews that I&#x27;ve done are closer to CS111 trivia or ACM contest prep than an interview of your real-world abilities. Therefore, the best way to practice for that problem set is to practice doing problems like that problem set. There are plenty of resources online to help prepare for that.<p>That said, a surprising number of problems in life tend to reduce or closely resemble a fundamental data structure or computer science problem. (A lot of problems tend to approximate to graphs.) Additionally, even though most languages have support for fundamental data structures or algorithms in their standard libraries, knowing the performance implication of a double-for loop or understanding when to use a binary search tree compared to a B-Tree or RB Tree can make huge performance differences that real users care about.<p>This is where the value of the coding trivia interview sort-of comes in. It is the clearest indicator of ones skills in CS primitives you can have, and it does a good job in setting a quality bar within an engineering organization (at least everyone knows how to do these).<p>I personally think that more comprehensive and system-level interview questions are more valuable in assessing the technical abilities of a candidate in toto. In asking something like &quot;How would you design an app like Instagram,&quot; you get a clearer sense of how the candidate thinks, how they approach problems, how much of their CS fundamentals they&#x27;ve retained, and, to some degree, what they&#x27;re like to work with. It also allows more flexibility than the trivia-style interview. If you want to assess coding ability, you can ask them to write their idea of a feed algorithm. Conversely, if you want to assess their abilities as a lead, you can ask them about maintaining the system and finding the right team to build an app like this.
stevenwooalmost 7 years ago
Even before stackoverflow was available, my ability to solve a problem on the spot was probably not that great so my success in passing technical interviews seems like a lot of luck in hindsight - in my actual work I had to solve similar issues in successful technical interviews, and this is over four different industries&#x2F;positions. This is versus unsuccessful ones where I haven&#x27;t looked at the thing in question in years or <i>ever</i> so I am pretty much going in cold on the question. I&#x27;ve seen some people talking about going through every question on leetcode or hackerrank and being able to recall a solution instantly to prep for a Google style interview so you have to ask yourself if you think it&#x27;s worth that kind of effort. Don&#x27;t take your lack of success now as a very good measure of your ability, it sounds like your company might not hire you if you applied to it even though you are really good at your job.
kenshialmost 7 years ago
- Practice a lot.<p>- For that authentic whiteboard performance feeling ask a friend to play the role of an interviewer.<p>- Maybe set up a local meet up to help people practice this interview skill
评论 #17333951 未加载
partycoderalmost 7 years ago
You have entered the world of &quot;competitive programming&quot;. Companies have started to incorporate competitive programming problems into their interview processes. They&#x27;re hard, and often don&#x27;t overlap a lot with what you may do at work, but there&#x27;s not much you can do about it other than to prepare.<p>A good book is &quot;Competitive programmer&#x27;s handbook&quot;, available for free in <a href="https:&#x2F;&#x2F;cses.fi&#x2F;book.html" rel="nofollow">https:&#x2F;&#x2F;cses.fi&#x2F;book.html</a>. This book is programmer to programmer advice that will take you very very far into these kinds of problems, and gets to the point really fast. The code examples are clean and well formatted. For interviews, it gives you about 70% of the competence you would get from reading much longer books like Skiena&#x27;s or Sedgewick&#x27;s.<p>My approach to these interviews is:<p>- Read the requirements very well. Try to read between the lines as much as you can.<p>- Ask if there are follow up questions or if the exercise has multiple parts. This helps you plan your time.<p>- If you do not have an ideal approach, try a bruteforce approach first.<p>- Try to narrow down candidate solutions: what happens if I use an array? a list? a tree (binary search, trie, heap, etc)? a stack? a queue? a graph? a combination of them?<p>You can practice on sites like Leetcode, Hackerearth and so on so forth. If you want to try something harder, you&#x27;ve got this (not for the faint of heart): <a href="https:&#x2F;&#x2F;techdevguide.withgoogle.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;techdevguide.withgoogle.com&#x2F;</a><p>But first, try to implement common data structures from scratch and get a better intuition about them. Remember to try recursive and iterative versions of operations. You can output Graphviz data and use that to debug.<p>Finally, even if you fail an interview, many companies will let you reapply after some period of time. I failed an interview a few years ago and I still get contacted by that same company today. It&#x27;s not a life sentence.
lsaacalmost 7 years ago
In the same boat as you here.<p>As everyone here says, you have to practice.<p>Then, when you&#x27;re finally fairly good at coding challenge questions, you&#x27;ll discover that you also have to be good at system design questions which is a different beast altogether. And then you&#x27;ll learn that instead&#x2F;addition to the above, company X actually wants you to complete a take-home exercise, and company Y won&#x27;t consider you because they do Python while you have Java.<p>It becomes very hard to know what to focus on when you don&#x27;t have your eyes set on a particular company.
评论 #17335931 未加载
gregorygocalmost 7 years ago
If you don&#x27;t have problems with sharpness of your mind, you might want focus on stress handling. I&#x27;d start with the attitude. Why stress out when you have a 6 figure salary?
im_down_w_otpalmost 7 years ago
The problem is, while possible that &quot;white-board style questions eliminate a lot of bad candidates&quot;, it&#x27;s a terrible and empirically unsubstantiated methodology of assessment given the purported goals most companies claim to have in hiring people.<p>In the event that it works at all, it does so by accident, not by design. Which is often evident in how hit-or-miss hiring someone is in most companies even after they&#x27;ve managed to make it through all these silly contrived crucibles.<p>To a certain extent it&#x27;s a cargo culting problem. Insofar as companies like Google do it, and Google appears successful, and so other companies (failing to do any meaningful analysis or meta-analysis of their own) decide to model Google on the basis that surely their company will be successful just like Google. The problem, taking Google as the example, is that Google has AdWords. Which is for all intents and purposes a money printing machine. Google can be basically terrible at almost everything they do and still appear wildly successful so long as they don&#x27;t disturb their money printer. As a result it&#x27;s very difficult to just pattern-match to what Google does and evaluate either its benefit or its appropriateness in any context.<p>The other part of it is inertial. Often the wheel of hiring in a company started this way for lack of any better ideas, and then as the company grew it became proportionally more biased toward people who made it through a process like that, and then it becomes generationally perpetuated. The unfortunate side-effect of this is that biasing the employee population this way makes the job, for a new executive or manager, of changing these ineffective (and sometimes toxic) strategies extra difficult while trying to maintain team cohesion. Because it has a lasting cultural fingerprint.<p>Honestly, it&#x27;s really a shame. I&#x27;m sorry you&#x27;re having to go through it. My capacity to try to interact and change this weird marketplace phenomenon extends only about as far as the company for which I&#x27;m the Engineering hiring manager. My hope for you, and for others, is that you either find a place to work which doesn&#x27;t do things this way, and&#x2F;or you otherwise advance far enough in your career that nobody bothers to foist these silly ceremonies on you. Because your involvement in their pursuits is seen as a priori beneficial or existential.
thisisitalmost 7 years ago
I can understand your situation because I was in your shoes once. I joined a place as an intern and stayed there for 6 years. Once I tried getting another offer, I realized I was a bad SWE by other company&#x27;s standard. And I failed interviews after interviews. Around 25 interviews but finally nailed one which led me to path which turned my life around.<p>So, how did I get the last interview? Once I realized that I wasn&#x27;t doing great, I started writing down all the interviews questions. The aim was to understand what was I doing wrong. But in doing so, I started to see a pattern, most interviews tend to follow a singular script. For example transverse a heat map, merge sorted array etc. And I trained on all those questions. Now this wasn&#x27;t a perfect solution because I still failed 10+ interviews but over time I got better. And then around the 25th one I finally nailed one as all the questions were repeated.<p>Nowadays there might be a better options to do this like books&#x2F;sites which throw tons of whiteboard interviews at you. So try those and best of luck.
paultalmost 7 years ago
Does anybody know what the interviews at the FANGs are like for non-SWE roles? What are the interview questions for a front end developer? Do they still make you reverse binary trees?
评论 #17334820 未加载
cornellwrightalmost 7 years ago
A lot of people recommended practicing coding problems. Along with this, I would add practice talking to people you don&#x27;t know.<p>Go to networking events and meet-ups. Offer to give mock interviews to people more junior than you. Have coffee with founders to give them feedback on their ideas. Anything that puts you in unstructured conversation with strangers will make you more comfortable and confident in an interview. You get better at reading people and start to see things from both sides.<p>Being a software engineer often mainly only requires communicating with a mostly unchanging group of people. Interviewing well requires being able to communicate efficiently with someone you just met. During an interview if you can direct less time and mental energy at just communicating you&#x27;ll have more for demonstrating that you&#x27;ll be able to do the job.
ashwinajalmost 7 years ago
This was told to me by someone who recently got into Google:<p>&quot;It is irrelevant whether you can come up a solution all by yourself. Being able to understand and remember the optimal solutions for those questions is the key. All the interviewer is looking for is whether you can write those optimal solutions literally on the whiteboard.&quot;<p>We can debate (and people have here) about whether it makes sense and the like, but this is the reality. Make this process as mechanical as possible, everyone knows it&#x27;s a stupid game and yet we all play along.<p><a href="https:&#x2F;&#x2F;translate.google.com&#x2F;translate?hl=en&amp;sl=zh-CN&amp;u=http:&#x2F;&#x2F;www.cnblogs.com&#x2F;grandyang&#x2F;p&#x2F;4606334.html&amp;prev=search" rel="nofollow">https:&#x2F;&#x2F;translate.google.com&#x2F;translate?hl=en&amp;sl=zh-CN&amp;u=http...</a>
Cofikealmost 7 years ago
I would say the biggest thing you can do is practice on Leetcode. You need to be see the different patterns that are used to solve certain classes of problems (tree problems, dynamic programming, array focused problems). There are common data structures that pop up in almost all of the questions (hashmap, linked lists, tree, bst, etc). It&#x27;s just a matter of exposure but focus on the underlying pattern&#x2F;technique used to solve the problem and understand how and why it&#x27;s being used as opposed to rote memorization.<p>The alternative is finding companies that do not ask these types of interview questions. The only big company I know that doesn&#x27;t ask those types of questions is Stripe but I&#x27;m sure there are plenty of others though they may not be 100% what you are looking for.
eksemplaralmost 7 years ago
I haven’t programmed much since I stepped into management 15 years ago, and while I’m not sure I could do still do Dijkstra I can still do all those silly text-book examples on a whiteboard if you gave me the business logic. From x-sort to linked lists and trees.<p>If they don’t give you the business logic, then you’ll need to practice, practice, practice, but you honestly should be able of reasoning you through a piece of businesslogic and turning it into pseudo code.<p>Aside from that, it’s a terrible test for hiring people exactly because you, can, memorize it through practice. But American hiring processes are funny like that.
koala_manalmost 7 years ago
What&#x27;s the pain point? The stress of being observed? Getting started? The difficulty of the problems themselves?<p>How long would it take you to merge two sorted arrays on a computer without internet access and no one looking?
评论 #17334581 未加载
评论 #17333960 未加载
Maroalmost 7 years ago
I feel you, I also get stressed out during interviews and perform worse than normally; it was the same for me during oral exams at Uni.<p>At one point I interviewed at a couple big ones and got into FB, where I also did a fair amount of interviewing. My tips:<p>1. Accept it&#x27;s a numbers game; apply to N, and you&#x27;ll get an offer from one. I got rejected by Google and Spotify, got an offer from FB. Some people do better and get more offers, but I know I&#x27;m a nervous type during interviews and under-perform. It&#x27;s okay, it&#x27;s a First World Problem, just apply to more companies. I think most people I know who work at G&#x2F;FB&#x2F;Spotify got rejected be a few others.<p>2. Practice a lot. There are 100s of questions available online. If you&#x27;re smart, you will pick up the patterns &#x2F; tricks you can use to solve the coding questions. Eg. when the obvious solution is O(n^2), usually there is a more efficient one involving using a hashmap to do a lookup.<p>If you think the problems you find online are too hard or stupid (eg. &quot;who cares about implementing an LRU cache&quot;), then read up on core CS topics to appreciate the subject matter.<p>If you think it&#x27;s not worth to invest the time to beef up for it, then (i) it is, you can learn a lot at the big ones (ii) you can see how hiring candidates who think it&#x27;s worth it is better for the company.<p>3. Think of it as a good thing. You brush up on your core skills (LRU cache), and it probably forces&#x2F;incentivizes you to look at some recent developments in your sub-field so you feel prepared and can comment on it if it comes up. Although I don&#x27;t enjoy the interview itself, I find the preparation to be a very fun time, reminds me of the good old days at University; a good break from the usual crunch of the job, which usually leads to rusting of core skills and specializes you in the tools the team&#x2F;company happens to use.<p>4. At the big companies, on the initial loops where you solve the shortish interviewing questions, usually they just want you to solve the problem, not talk too much. I found some candidates think they have to talk a lot and relate the problem to their work, but that&#x27;s not the case. Don&#x27;t say &quot;At work I&#x27;d just use a library for this.&quot; That&#x27;s obvious, that&#x27;s not the point of the interview. In the initial screens the interviewer just wants you to supply a solution, explain it, and move on. So just do that. Be efficient.<p>5. Getting rejected feels like shit but doesn&#x27;t say much about you. It just means you had a bad day, or you were nervous. Or maybe the interviewer actually did a good job of assessing your skills, and you&#x27;re not a good fit for the team&#x2F;org that was hiring. I&#x27;ve seen lots of people get rejected from FB where I thought any smaller company would _kill_ to get them onboard, but FB didn&#x27;t accept them for some weird reason, which at a high level is sth like &quot;Would they be successful here at this role X, in team Y or Z, _given how this role works here_? Maybe, but the hiring manager isn&#x27;t convinced enough&quot;. It&#x27;s a bit frustrating, but it works for the company: the people who get through the filter are very smart&amp;good, work together very well and efficiently, altogether create products Bs of people use (good for everybody), creates Bs of revenues and Bs of profits. So it works, it&#x27;s not going to change. Play the game.
chrisbennetalmost 7 years ago
Sometimes it&#x27;s not the white board part of the interview that is the problem but the anxiety and general anger the w.b. interview generates. It&#x27;s a little like getting groped by TSA at the airport.<p>It would go a long way towards making the experience better if the interviewer&#x2F;TSA guy stated right at the beginning said <i>&quot;I realize this experience is degrading and it sucks to be treated like a liar&#x2F;terrorist but I&#x27;ll try to make it as pleasant as possible. &quot;</i> ?<p>A part of the reason we have this current interview process is because there are people out there who can really &quot;sell&quot; themselves and have bogus resumes so they have to screen these guys out i.e. &quot;this is why we can&#x27;t have nice things&quot;.
评论 #17342191 未加载
techjuicealmost 7 years ago
Best thing you can do is to enhance your skills in data structures and algorithms so you have a strong base in them. The interviews normally start here for most of these companies because their software deals with a large amount of data structures and&#x2F;or algorithms and is essential to understand to be a productive contributor there.<p>If your previous work did not actually require you to know them, they probably where not building algorithms from scratch or optimizing parsing&#x2F;processing of data very much. As without the essential basics of data structures and algorithms it is very hard to build scalable applications that rely on them.<p>As you grow in your career you will have to learn things outside of your base knowledge as you move up the ranks on the technical skills ladder. This will be standard requirements for senior level positions which you are probably seeing now. At the junior and mid level you are normally not responsible for building the core pieces of data processing software engines or massively scalable applications that run custom in house algorithms.<p>If you go through some of the below resources they should help fill that skills gap and make you an overall stronger engineer so you can feel confident applying for senior level positions.<p>I would recommend taking the following course: <a href="https:&#x2F;&#x2F;www.coursera.org&#x2F;specializations&#x2F;data-structures-algorithms" rel="nofollow">https:&#x2F;&#x2F;www.coursera.org&#x2F;specializations&#x2F;data-structures-alg...</a> <a href="https:&#x2F;&#x2F;www.edx.org&#x2F;course&#x2F;algorithms-and-data-structures" rel="nofollow">https:&#x2F;&#x2F;www.edx.org&#x2F;course&#x2F;algorithms-and-data-structures</a> <a href="https:&#x2F;&#x2F;in.udacity.com&#x2F;course&#x2F;data-structures-and-algorithms-foundation-nanodegree--nd004-indsa" rel="nofollow">https:&#x2F;&#x2F;in.udacity.com&#x2F;course&#x2F;data-structures-and-algorithms...</a><p>and reading the following book: <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Introduction-Algorithms-Press-Thomas-Cormen-ebook&#x2F;dp&#x2F;B007CNRCAO" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Introduction-Algorithms-Press-Thomas-...</a>
bradstewartalmost 7 years ago
Practice. I have a very similar reaction to those types of interview questions. Your day-to-day engineering work is entirely different, so it&#x27;s no surprise you get stuck on those questions. This programming interview book [0] really helped me.<p>While I don&#x27;t agree with this type of interview, it is the reality we live in.<p>Disclaimer: The book was written by a professor of mine in college. [0] <a href="https:&#x2F;&#x2F;elementsofprogramminginterviews.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;elementsofprogramminginterviews.com&#x2F;</a>
throwaway080383almost 7 years ago
&quot;But each failure kind of brings me down, and makes me think that I&#x27;m a bad engineer.&quot;<p>You&#x27;re not. I do these type of interviews and there are plenty of times where a person doesn&#x27;t pass but I can tell it&#x27;s just because they need to prepare more. I think your strategy of applying and failing is good, but I would also supplement it with practicing these type of interviews (e.g. get a whiteboard, go to leetcode or wherever, pull up a random question and pretend like you&#x27;re in the interview).
jeffrallenalmost 7 years ago
Try practising speaking your ideas and approach out loud. This may do two things, which reinforce each other: giving yourself momentum and positive vibes as you say things you know are right and leading you forward towards the answer, and building a clearer idea of your skills and manner in the minds of the interviewer. In effect, you are trying to turn the liability of the audience into an asset.
randopalmost 7 years ago
You are not alone on this one. I myself have also been through this experience.<p>Have you considered a different option ? How about building your own start-up to serve real business needs? Or working on open source projects. There are a lot of opportunities to look forward into.<p>Why keep banging your head multiple times on something, when you can use that energy on other meaningful ways.
评论 #17336366 未加载
tananaevalmost 7 years ago
One thing people often don&#x27;t realise about interviews at Google and other companies with similar interview standards. You can&#x27;t casually apply for those. You have to prepare a lot. At least for a month (probably much more) before the interview you have to practice coding questions on Leetcode or similar resources.
smt88almost 7 years ago
My company doesn&#x27;t use this for interviews for many reasons. It&#x27;s absolute nonsense.<p>Email me at the link on my profile if you&#x27;d like a list of our open positions.
AlexCoventryalmost 7 years ago
Would you get different results if you were in a room by yourself, under exam conditions? Maybe some companies would let you test that way.
paktek123almost 7 years ago
Having gone through the same situation, I&#x27;d advise practice and you&#x27;ll eventually catch on. Hackerrank is a good place to start.
avipalmost 7 years ago
Practice, practice, practice. Then practice more. It sucks, but until we get to set the rules - just practice &#x27;till you good.
foobawalmost 7 years ago
Solve 150+ random leetcode questions. Play a video on YouTube of someone watching you and &quot;taking notes.&quot;
justaaronalmost 7 years ago
Consider freelancing or going into business for yourself.
linouk23almost 7 years ago
Practice on interviewing.io
评论 #17334227 未加载
ninjakeyboardalmost 7 years ago
Interviewing is its own skill!! To get into eg Google you have to go through the rites of passage of learning to interview. That&#x27;s not true of all positions. I give take-away assignments now. I want to see you can turn in good code. That&#x27;s all I really care about. How you get there doesn&#x27;t matter, your decisions do.<p>The Golden Rule: When in doubt, use a hashmap. Almost all code challenges are about finding an algorithm or datastructure to fit the problem&#x2F;solution. Many of them are solvable efficiently via a hashmap.<p>Preparation<p>- Practice on a whiteboard<p>- Do mock interviews with the most skilled people you can find and get feedback! This is critical to glean any information about how you&#x27;re actually doing! I could volunteer to do that for you remotely if you like. Send me your contact info. I&#x27;m a distributed systems guy but could walk you through some problems and tell you how you&#x27;re doing with whatever you&#x27;re using for tech very likely still. Drop a note on how to connect if you&#x27;re comfortable.<p>- Take an algorithms course before you interview. (The princeton sedgewick one is great and easy to grokk. see coursera: <a href="https:&#x2F;&#x2F;www.coursera.org&#x2F;learn&#x2F;algorithms-part1" rel="nofollow">https:&#x2F;&#x2F;www.coursera.org&#x2F;learn&#x2F;algorithms-part1</a>)<p>During:<p>- Write tests for your code during the interview to demonstrate production quality code.<p>Especially if interviewing for eg Google. They don&#x27;t give super tricky problems in every interviews (eg during phone screen) - focus on writing good code that is tested and will compile and run after the interview, not writing mediocre code fast.<p>- It&#x27;s okay to incrementally improve your solution. Talk through your thinking. Start at the naive solution and then work toward optimal. Eg give two lists, find any number from list a sums to any number from list b. To start, you could write a couple quick tests on the board to make sure you understand the problem. Then you could reason about solutions - say you could use nested for loops. That&#x27;s O(n squared) which isn&#x27;t suitable as a solution. So you ask if the data is sorted. If they say no, you can sort lists, iterate through one and binary search on the larger list to get to an asymptotically linearithmic solution. That&#x27;s suitable so you write that fairly swiftly. To improve you discover you only need to sort one list so you change the solution to only sort the larger one and iterate through the smaller. If there is extra time you might start to reason about how you can move toward a linear solution. Remember I said the golden rule is use a hashmap? Why don&#x27;t you make a hashmap out of one of the lists and iterate through the other one to find values in the map? Don&#x27;t just sit there and take it away to the corner and try to solve it.<p>God Mode: - WAYYYY before you take the interview: Stop using an IDE at work if you&#x27;re working in a statically typed language. Use emacs, or vscode or whatever you fancy. Moving to emacs made my brain learn the qualities of the language at an intimate level faster than anything else. You check the docs if you forget the api until you stop forgetting the API. It slows you down a bit at first so it&#x27;s an investment but whatever - tack 25% on your estimates for a few weeks. You can revert to the IDE for larger refactoring work.
mlthoughts2018almost 7 years ago
Just be fine with failing a bunch until you find a company not using such obviously bad interview techniques.<p>Don’t waste time on leetcode &#x2F; HackerRank &#x2F; etc. It’s not useful. Practice programming by writing code you enjoy, solving problems you are interested in. You’ll be naturally productive at what you enjoy, and just build on that.<p>Anybody giving advice that comes from the point of view that these interview techniques have any legitimacy is probably just someone who happens to randomly be good at or enjoys interview trivia, and so their opinion is clouded by a selection bias effect. This is especially true on Hacker News.<p>They do well on interviews, not because their study methods work better and not because they are better at engineering or more effective in a job. They are not. They just benefit randomly from a system set up to reward traits they happen to have already and find easy. Their ideas worked <i>for them</i> but are very unlikely to work for you.<p>Seriously, just do a lot of interviews, fail a lot, and be fine with it. It’s easier said than done, but it’s necessary for you to weed out the places with foolish interview practices and find the ones which are more holistic, human productivity focused, flexible, etc.<p>I happen to be good at quickly working through algorithms, mostly in machine learning and search data structures, but in general software too.<p>If anyone tries to hire me <i>because</i> of that quick “see how you think” whiteboard nonsense, I just walk away. They are doing it wrong; life’s too short.
samueldavidalmost 7 years ago
you don&#x27;t want to blame the process, yet you admit it brings you down every time you fail and makes you doubt of the already proven ability you have as an engineer, and the process is ok?
评论 #17334219 未加载
chrisjshullalmost 7 years ago
Shameless plug: <a href="https:&#x2F;&#x2F;chrisjshull.com&#x2F;agent&#x2F;" rel="nofollow">https:&#x2F;&#x2F;chrisjshull.com&#x2F;agent&#x2F;</a>
评论 #17333903 未加载
评论 #17333983 未加载