Hiring Without Whiteboards

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with<p>2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we&#x27;ve implemented. We ask for 100 lines of code and not more than 2 hours. They take as much calendar time in days as they need, most have full time jobs, and let us know when you&#x27;re done. The candidate then comes back, typically in 2 to 7 days and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not to criticize their style and approach.<p>3. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It&#x27;s a check point to look for concerning weaknesses, as well as get buy in from the broader organization.<p>We like this approach because it allows the candidate to code in a much more natural environment. They can take the time they need and comfortably solve. No one spends their professional career coding on a white board. This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.

I interviewed with one of the companies on that list a few years back (noredink). They gave a timed hackerrank style coding question as round one (so I guess technically not a whiteboard). I passed that, then I had an interview with an actual person.<p>He asked me vague question, like what is architecture, I started to reply with what design tradeoffs I made on the app I was working on. He literally laughed at me, and said that is not architecture. I was shocked that someone would laugh at a candidate but said ok, what does architecture mean to you? He responded, I ask the questions here not you. I immediately ended the interview. Worst interview I have ever had. Every time I see that company brought up, I think back to that experience.

This is a great list. Thanks for sharing it.<p>I actually had the pleasure of interviewing at one of these companies before. They had a take-home project, which was to choose and implement and couple enhancements to a toy app. In the subsequent conversations, we discussed how I approached the problem, details of my design, technical tradeoffs, etc -- all the sorts of things you would expect a professional sw engineer to be able to do on the job. It was challenging but fair, and I was struck by how reasonable the process was. It left a wonderful impression on me.<p>Take-home projects are not a perfect solution to the interview problem. A major issue is that they require candidates to have free time outside of work to complete them. Personally, though, I&#x27;d much rather spend a few hours per application working on projects than countless hours prepping for stressful whiteboarding puzzles. As a developer who prefers to digest problems slowly, I look forward to the demise of on-the-spot whiteboarding interviews.<p>If you work at a company that subjects candidates to such high-stress algorithmic riddles, and you have the ability to make your process more sane, please consider following the lead of cos on this list.

This is yet another tech interview discussion, so I&#x27;d like to highlight a subthread from the one earlier this month:<p>&gt; I&#x27;m actually a little scared to leave my current FAANG gig for that exact reason tbh. I&#x27;m fairly certain I wouldn&#x27;t make it back in the door without more leetcode grinding + repeated loops than I&#x27;m willing to do at this point in my career.<p>&gt;&gt; I&#x27;m in a similar position - a tech lead role at a Big N - and have recently been doing some interviews for senior roles at FAANG. The most frustrating thing is knowing I can&#x27;t really leverage anything I&#x27;ve learned over the past 7 years of my career in the interview, at least at the early stages.<p>&gt;&gt;&gt; I feel extremely little of what I&#x27;m doing in my real, actual, job, helps me in advancing in my career. Unless maybe if I choose to stay at my current company until retirement lol. Otherwise, why bother doing anything more than the bare minimum to get by at work? It would be a far better investment of time and effort to grind leetcode and practice for interviews, instead of going above and beyond to excel at my job. At least until I get into an &quot;endgame company&quot; where I feel it&#x27;s worth staying long term.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23848717" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23848717</a><p>Even as we debate the validity of the metrics measured by technical interviews, it&#x27;s also worth considering the metrics used to measure engineer worth in the industry at large. This existentialist &quot;fear and loathing in FAANG&quot; discussion was quite illuminating, and a little sad.

The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it&#x27;s a horrible system except for all the others.<p>Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you&#x27;ll get a lot more of them than full in-person interviews.<p>Pair programming? That&#x27;s basically white boarding with a better white board or, in the remote interview world, just regular white boarding. Sure the problem is more real world, in theory, but then you get issues of knowing the same frameworks, etc. So to do well you need to spend a lot of time beforehand studying their specific frameworks and code bases if they ask you to do an issue on their open source project.

No one enjoys whiteboard interviews but it&#x27;s not clear that these companies have better alternatives. Many of them do take home projects which are time consuming. I&#x27;d prefer the employer look at my GitHub profile as there&#x27;s plenty of code there already. Furthermore, I&#x27;m not a fan of &quot;interviews&quot; in general, I find that more information is transmitted by eating lunch with the team and talking like normal people.

Here we go again perpetuating the stereotype of the whiney privileged engineer put in a position of mild discomfort by the villainous abusive white board interview boogeyman. I don’t mind whiteboard interview exercises. They’re not great, but they often give a very good and reasonable signal that often has a high corollary to work performance. I think there’s bigger fish to fry in refining fair and objective interview processes, I’ll never understand the perpetual moaning around this aspect of technical interviews.

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process.<p>One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal was that I basically had 6 months to prove myself, and if everyone felt like it was working out (myself included) this would be bumped into full-time with benefits. The crazy thing is, I was actually the one who decided I did not want to continue after the 6 months was out while they wanted me to stay very badly. I think this can be a really useful checkpoint tool for both sides.<p>Anyone can misrepresent themselves in an interview and dupe a room full of people for a day or 2. No one can keep up an act for 3-6 months continuously when working with complex code tasks. You will get found out before the term is up, assuming everyone is using this process as an evaluation tool and following up on it regularly.

One thing I&#x27;ve been wondering lately about <i>take-home tasks</i> is how everybody complains about time estimates, and yet here&#x27;s a bunch of &quot;small projects&quot; which someone pretends to have very precisely estimated.<p>Unfortunately, most companies fail to honestly estimate the cost of the tasks they assign for these processes. Many of them because they just don&#x27;t take into account numerous small tasks that the candidate will need to deal with.<p>I&#x27;ve seen a lot of these tasks ask for setup instructions, <i>good</i> unit tests, explaining any decisions you make, etc. In case there&#x27;s any visual user interface (e.g. some web component) they also ask for it to be <i>nice</i>, as in &quot;we don&#x27;t want a designer but we need you to make it somewhat nice&quot;. And then they&#x27;ll say it should take just a couple of hours.<p>I&#x27;ve also seen a fair number of others casually say their task should <i>only</i> take about 8 hours. And I can do that on my free time on five consecutive days, after having worked already 8 hours each day. Sure thing.

Oh God, here we go again.<p>Coding on a whiteboard in an interview is not &quot;broken&quot;. What <i>is</i> &quot;broken&quot; however is making the problem the candidate needs to solve &quot;hard&quot;. I can&#x27;t stress this enough: a whiteboard coding test is nothing more than a <i>negative filter</i>. It&#x27;s to filter out people who can&#x27;t turn a <i>simple</i> idea into code as these people exist.<p>This is why FizzBuzz was such a simple problem.<p>But interviewers fall into the trap of thinking &quot;this problem is too easy&quot; and make it hard (eg figuring out a problem is g union-find on the spot and then implementing it) or, worse, they make it a crap shoot of whether you know the &quot;trick&quot; or not (eg reversing bits in O(log n) or the tortoise and the hare). This actually makes the test <i>completely useless</i>.<p>A negative filter is simply a filter whereby if you fail it, you almost certainly aren&#x27;t a great hire but the reverse doesn&#x27;t apply: there should be no A+ on a whiteboard coding test. It&#x27;s straight pass&#x2F;fail and an easy pass at that.<p>I realize some people have anxiety about doing this. Having helped or coached a bunch of people in the past about this, I can say that mock interviews and practice help the vast majority of these people. Some may be helped by doing this on a laptop in a shared doc instead, which is fine.<p>A few will struggle with the anxiety of that, even with coaching and practice. While I feel bad for those people, I do wonder if a reasonable-sized organization, which will generally require a certain level of communication skills and presentation ability, is the right place for you.

The issue with LeetCode style interview is that almost EVERYONE can solve those questions after studying a couple weeks&#x2F;months.<p>The only thing that LeetCode questions predict is if the candidate has been training for LeetCode questions.<p>The fact that Google, Facebook etc still use it as a gatekeeping mechanism makes me believe they want to find cogs that will specifically spend hours studying for it. Making sure that those engineers will be ready to execute their mindless coding tasks at the company.

I live in Sweden and we seem to have a very different interview culture. I&#x27;ve never heard of whiteboards or trivia questions, here.<p>I&#x27;ve only gone to four interviews (across eight years), and been lucky to get an offer each time (three of which I&#x27;ve accepted). They have all been primarily discussions about personal experience, hobby projects, personal interests, would-be responsibilities, benefits, and company culture.<p>At one place (Ghost Games, an EA studio and the only company which wasn&#x27;t purely Swedish) I had to complete a code assignment (create a clone of a classic arcade game in C++) ahead of the interview.

Another tech interview thread. For the side that supports these types of interviews, I&#x27;ve never gotten a good answer to a simple question: in the year 2020, why are we expecting people to write compilable code on a whiteboard? It&#x27;s just stupid at this point. Even a laptop that boots into some micro linux distro and has nothing but nano open would be better. Or just a fresh install windows laptop with nothing but notepad.exe open. Or a chromebook that is open to a HTML page that has nothing but a textarea element.<p>I&#x27;m not including a compiler or having build tools or an IDE. Just a basic simple text editing area that allows the basic functions of typing in text and editing it.<p>I&#x27;m against these leetcode interviews. But if you did nothing else but change this one thing, just stop expecting people to write code on a whiteboard or paper&#x2F;pencil and allow them to write code the way it&#x27;s actually done (a computing device with a keyboard and text edit area), that would be such a huge improvement. Writing code on a whiteboard or paper doesn&#x27;t test anything. Think about how limited it is and how different it is (for example, you can&#x27;t just press an up arrow and add a newline, have to find an eraser and start over).<p>It&#x27;s yet another useless skill to learn just for interviews (writing compilable code on a whiteboard&#x2F;paper) which also encourages rote memorization (because you have to get it right on the first try since editing the text is so painful and difficult).<p>I hope people start pushing back on this. The reaction should be, wow you care so little about your interview process that you can&#x27;t get a $200 chromebook in here?

One of the most telling questions I ask when interviewing is “what was your favorite or most complicated project you’ve worked on and how did you solve the problems you encountered?” I don’t need the interviewee to show me a perfect implementation of a red&#x2F;black tree. Hell, I don’t remember it. But I want to know what they found challenging and how they went about solving it. Often times they will give me all the technical details I would have asked for, but in context. I don’t care that you know the exact name of that one function in PHP but if you mention it off hand in relevant context, I will place that much more trust in the fact that you actually used it instead of memorizing it.<p>Other questions I ask are things like do you work on your own projects and tell me a bit about the tech behind them, what’s your favorite pieces of open source or free software (I work with almost exclusively FOSS stuff though my own work is not FOSS), what do you do for fun, and if we were talking on the phone and I had never made tea, walk me through the process (this is a fun one). Then take them out to lunch if possible and watch how they treat service workers. I think this has so far worked well for everyone involved. At least as far as I know nobody I says yay to has been a bad hire.

Personally, the anxiety of whiteboard “coding as performance art” makes my brain freeze. I see it as a broken process. It certainly selects against me.<p>I think you can learn more useful stuff about a programmer by showing them a function prototype and asking how to black-box test it. Then show them complete code, and ask them to white-box test it. Test cases or a test plan, depending on scale. Then a discussion of test tools they have used.<p>The people who can produce quality code for your organization will show up pretty fast.

If I were a large company with money I would simply ask all qualified applicants if they would be willing to work on a small part of a real project as a contractor with the possibility of getting hired. Applicants get paid for their time, productivity is achieved, jobs might be offered, everybody is happy.

Companies like google and facebook are paying 200k for entry level engineers. They aren&#x27;t going to have any issues getting people to apply even with the whiteboard interviews.

I prefer the take home text. Less stress and I can really show what I know. Sure it&#x27;s time consuming, but I always try to have fun with it. If I get a take home test, and it&#x27;s writing some code, I know I have a shoe in the door.<p>I interviewed at one of these companies in the list. I&#x27;m nobody special, did the test, did the interviews which were more about doing the work and how it gets done and I how I think about it, and they made me a really good offer which I accepted.

What you really want to know is whether the take-home assignment really decides anything, or whether it&#x27;s subjectively evaluated. Is there a rubric? Or is it the basis of an interview? A lot of take-home assignments are cargo culted; the people offering them don&#x27;t have much faith in them, and still select candidates based on interviews and resume screens (or &quot;pair programming&quot; projects that are really just multi-hour or multi-day interviews).<p>I have a hard time believing that this many firms have take-home assignments that really matter, and aren&#x27;t just another hoop candidates (or, maybe, disfavored candidates) are forced to jump through.

Identifying top tier tech talent is not that hard. Identifying yourself as a non top tier employer and setting your hiring bar appropriately - that is hard.<p>If you’re only hiring candidates who can pass Google interviews, what are you offering that Google doesn’t? (Hint: “we give you a 10 hour take home, then ghost you” is not a competitive advantage.)

I agree that the cliché whiteboard interview is just awful – I&#x27;ve had my share of terrible ones. However, there is one form of whiteboard interview that I really like – it&#x27;s where the interview is about system design and architecture rather than coding problem nonsense.<p>I think the first time I saw this was at Google, where the question was pretty much &quot;We are going to design Google Maps from scratch – what does it look like?&quot;. The interview is about evaluating the candidate&#x27;s ability to ask sensible questions when designing a system, checking that they know how to analyse tradeoffs, and understand where they need to think about issues like performance or scaling.<p>I liked it so much that I&#x27;ve built it into our own recruitment process for our most recent role – it&#x27;s a process that we go through a lot, even when making changes to existing systems. We do it as a one-hour long collaborative system design process with a short specification for a system that we want to build. We let the candidate lead the design, and help by providing feedback, discussing any ambiguities, and asking questions about specific areas of concern. It&#x27;s been really interesting to see how different candidates have approached the process.<p>(Anecdotally, the biggest indicator of a good candidate so far has been the use of abstraction rather than concrete technologies - i.e. &quot;I would have a queueing system here and an object store there&quot; rather than &quot;I would have Kafka here and push to S3 there&quot;).

I think the problem is similar to the problems in systems engineering, where techniques and processes can de-rail real engineering progress. This has been observed back in 1969 by Robert Frosch, who served as NASA administrator:<p>&quot;I can best describe the spirit of what I have in mind by thinking of a music student who writes a concerto by consulting a checklist of the characteristics of the concerto form, being careful to see that all of the canons of the form are observed, but having no flair for the subject, as opposed to someone who just knows roughly what a concerto is like, but has a real feeling for music. The results become obvious upon hearing them. The prescription of technique cannot be a substitute for talent and capability, but that is precisely how we have tried to use technique.&quot;<p>- <a href="http:&#x2F;&#x2F;origins.sese.asu.edu&#x2F;ses405&#x2F;Additional%20Reading&#x2F;Frosch%20on%20System%20Engineering.pdf" rel="nofollow">http:&#x2F;&#x2F;origins.sese.asu.edu&#x2F;ses405&#x2F;Additional%20Reading&#x2F;Fros...</a><p>Current technical interview processes with its whiteboards and technical questions will undoubtedly lead to hiring the first type of music student.

I am probably one of the very few who prefers whiteboard problems compared to knowledge based problems. In my career spanking over 12 years, I have worked on ASP.NET, Silverlight, Blackberry, Android, Node.js, HTML&#x2F;js&#x2F;css, Xamarin, .NET Core, Code generation, Java microservices , Native Windows and AWS services.<p>The result of working on so many things is that I am not an expert in any of those topics. While I do well in generic system design interviews, I lack depth in literally every single thing that I have worked on. So inspite of having more than a decade of experience, I don&#x27;t satisfy the criteria for companies who ask for &#x27;x&#x27; years of experience in &#x27;y&#x27;. So whiteboard and algorithm problems work well for me, because there&#x27;s not really much to learn and memorize in those topics.

This seems to promote Google Docs &gt; whiteboard, what? At least you can brainstorm or draw diagrams on a whiteboard.<p>IMHO the worst of these options is coderpad&#x2F;hackerrank&#x2F;etc. - it&#x27;s robotic, discourages pseudocode, and perpetuates the idea that rote memorization is required to pass an interview.

To a large degree, these look like no-name companies who probably have to resort to this kind of thing to make up for worse pay and benefits as compared to FAANG.

A thought I had recently was to shift from having candidates write code to have them review code. I&#x27;m sure it&#x27;s not an original thought, but it comes with a few advantages. 1. Reading someone else&#x27;s code is usually harder than writing your own and in most projects you spend more time reading code. You&#x27;re seeing how they&#x27;d handle the more common work. 2. You can still pick how deep you want to go in the interview. Like some of the algo problems where interviewers keep adding new requirements, you can discuss API design, performance trade-offs, other code qualities. 3. You get to see how respectfully they can discuss a future colleague&#x27;s work and how well they can communicate their own ideas.

As somebody who has been interviewing recently, the format I&#x27;ve preferred is from TestDome. I&#x27;ve never used leetcode or others but I imagine they&#x27;re similar. I had 4 coding problems for which I had to pass a set of test cases which were explained from a high level. The first 3 were fairly easy and had time limits of 10 minutes or so. The last one was more involved from a design and functionality perspective and had a limit of 45 minutes. Then, it was followed up by a conversation with a developer where we discussed the problems and approaches. The time commitment was finite and reasonable, and the opportunity to explain my code was appreciated.

The best interview test I&#x27;ve done was a take-home test with a fixed time window. I was given a working development environment with an existing app and asked to fix some tests, implement new tests and then implement a few new features with tests.<p>It was good because:<p>1. There was no faffing about to set up the environment 2. There was some small, easy wins at the beginning which got me engaged and thinking about the task. 3. It was fixed time - I had to specify when I would start and then the test was emailed to me 15 minutes before that time. I then had 4 hours to return it via email.<p>This solved most of the problems I&#x27;ve seen with take-home tests - namely that they take far too long and ask the candidate to do all sorts of pointless admin tasks before they can start coding. Unless the candidate happens to be super familiar the exact environment of the test (including setting up a new project - how often do most people start new projects?), you&#x27;re either making them waste hours of time before they can start, or disregarding good candidates.<p>Ultimately you want to find candidates who can solve problems and understand software architecture. Unless you&#x27;re interviewing for a devops position, making them spend hours setting up a build environment seems like testing for the wrong thing.

I haven&#x27;t seen portfolios mentioned yet, but that&#x27;s another option. Pros: do it once, use it at multiple interviews. Cons: more difficult to make sure it&#x27;s original work, difficult to come up with ideas. I did CV screening and very few people had anything, it&#x27;s not like a portfolio project needs to take more than 2-3 hours to create.<p>Portfolios are a common requirement in other fields where creating a portfolio is even part of the educational process.

I just started working at a company that didn&#x27;t do any whiteboarding or technical challenges. As far as interviewing me goes, they broke all the &quot;rules&quot; that I used to follow when interviewing candidates at my old job.<p>So far, so good. They seem to have an attitude of seeing the best in everyone, and everyone seems talented. Maybe I can learn a thing or two from them!

Maybe we should give options to candidates. If I were to hire software engineers, I would offer every option to them:<p>1. Whiteboard interview<p>2. Opensource contributions<p>3. Take-home assignment<p>4. Becoming contractors for a short period<p>5. Etc<p>So if they fail whiteboard interview, they can redeem themselves with their opensource contributions. If they don&#x27;t have opensource contributions, then they can take home our assignments. And so on.<p>So it&#x27;s fair (I think).

A. this is a good list. B. Lets not forget that whiteboarding is not all evil. If used correctly, it can filter out a lot of people that don&#x27;t have good CS fundamentals. By fundamentals, I don&#x27;t mean inverting a binary tree. At the end of the day, as a technical manager, the goal is to hire smart+hard working people.

Here is how to do a tech interview that (I think) will work for everyone. I am sharing in the hope that this will become the standard, it was certainly the most pleasant technical interview that i have had, and somewhere where our industry is badly broken.<p>I was asked to bring in my laptop with some of my own code - I had a side project at the time, so no problem. We talked about the code, decisions I had made. I was asked to implement a simple feature. I did.<p>No time consuming take home exercise. No whiteboard riddles. No need to have a github full of work (lets face it most peoples work is in house and not easy to show off). Code I was familiar with, so less stress. The only downside would be not having code available, but then it will be the equivalent effort of a take home exercise to produce something.

Programmers change jobs very frequently. They come and go. So why are we so obsessed with &quot;getting it right&quot;, as if hiring a programmer were like signing a 30 year mortgage?<p>Hiring is a crapshoot. You&#x27;ll make bad hires. That&#x27;s an unavoidable fact of life. Professional sports teams spend millions of dollars on talent evaluation and still get it completely wrong all the time.<p>No, a bad programming hire is _not_ devastating to your company. You&#x27;ll live. A bad CEO hire could be devastating, but you can&#x27;t do a whiteboard or a take-home test for that.<p>&quot;The perfect hiring process&quot; is classic premature optimization.

I once applied for a company here in São Paulo where after the technical interview (no whiteboard) I talked on-site with the CTO and he passively-agressively asked a bunch of random questions and tried very hard to be a dick about it (&quot;oh, you consider yourself a good self-learner? French? I bet you couldn&#x27;t read some news in French if I opened any here right now. JUST KIDDING&quot;)<p>At the end of this 40 minute nightmare I had a bizarre homework to do at home that involved writing a list of uses to a paperclip.<p>They took a month to send me an email saying I wasn&#x27;t accepted.

Can someone explain to me why isn&#x27;t it ever part of the discourse to talk about certifications?<p>Most of the software engineers are certified right from the start when they graduate in university. All these people hold a certification in their hand, namely their diploma which proves that they are actually deemed suitable to hold any software engineering job in the industry.<p>The whole hiring process could be replaced with a timely renewal of accreditation. Then anyone who passed accreditation could be deemed as passed the technical interview. And then case closed.

When there are hundreds of applicants for 1 role of which the top 10 are all equally qualified, no interview process will seem fair.<p>So how do we break the tie?<p>Whiteboard? No whiteboard? Pair programming?<p>If we accept that after a certain point the process is random, why not simply break ties with first come first serve?<p>In the final few rounds, is a candidate who can solve the exotic DP problem just because he&#x27;s seen it before really any better than the others?

I feel a better title could be &quot;Hiring without CS trivia&quot;. Whiteboard is the most powerful tool I know to brainstorm high-level ideas quickly, such as timelines, diagrams, mock-ups, etc. What sucks is when the whiteboard is used as IDE and the candidate as a compiler.

It’s a funny cultural thing. Here is a caricature:<p>Hiring managers have a real problem to solve: “how do I hire?”. They don’t have the time to conduct actual experiments and work out what actually relates to better hiring. So they trivialise the solution into some assumption about how the information captured in an interview generalises to overall suitability. They then proceed to defend the process and it’s results as if it was state of the art because bad hiring = bad management in the politics game.<p>To me it feels obvious that whiteboards, pair programming , take home tasks, panel interviews , etc are all subject to being highly flakey and highly presumptive not least because repeatable processes are just hard to enforce and train people on.<p>What really works is survival. Practically every company has a probationary period but it’s rare that once you’re in you’ll get bounced out in my experience. IMO bite the bullet, over hire and then collect the cream based on evaluation of the total output and the teams impressions in the probationary period ...

Best way to avoid this BS is to be introduced by an established insider to help bypass this.

I don&#x27;t fully agree with the part of the title that reads<p>Companies that don&#x27;t have a broken hiring process<p>Only because they don&#x27;t currently do whiteboards. I feel like interviews in general is a tough problem

I&#x27;m absolutely fine with whiteboards. What I&#x27;m not ok with is take home assignments. You are expected to work for free for 2-3 days on some project that will help no one.

If you can&#x27;t explain your thought process on a whiteboard you don&#x27;t know what you are talking about.<p>Literally no company wants you to make actual production code on a whiteboard.

I interviewed with crowdstrike recently and the interview was a whiteboard system design interview followed by 4 whiteboard lc easy problems.<p>So I&#x27;m not sure how accurate this list is.

Is it simply a coincidence that people don&#x27;t like whiteboard interviews <i>and</i> believe they don&#x27;t work? Seems pretty convenient to me.

Just curious, does work at these companies require any algorithm design skills or is it usual web&#x2F;app&#x2F;database development work?

Are the STEM fields the only ones with asinine interview processes?<p>What does an interview as an accountant, sales or manager look like?

They need to take Netflix off the list. All they do are algorithmic whiteboard interview questions.

By no means an exhaustive list, so really just promoted listings.

Thanks for this list. I&#x27;m going to need a new job soon.

When the bar is low and interviews are easy, the bar is not only low for you, but also for your coworkers.<p>If the interview bar is too low, you will be exchanging hours of frustration by months to years of frustration.

We need a similar list for companies without Agile.

what&#x27;s FB doing on this list?

Adding my own personal experience.<p>At the end of last year I wanted to change jobs but I was paranoid about my raw algorithm knowledge. I&#x27;ve been a consultant for over 15 years. The last company I worked at for a decade. I&#x27;ve developed software given a specification, worked with teams to design applications, lead teams, presented to management of companies, and even was part owner in a company -- but I never was good at rote memorization.<p>I know my limitations and I know how to find answers.<p>So, for 4 months I practiced online programming problems, read interview books, and had my wife quiz me nightly. The nightly quizzes were whiteboard answers and I had to explain the solution enough that my wife understood.<p>In the end, I was interviewed at 4 companies: Daugherty Consulting, Google, Amazon, and Target. (For Google this was my second interview in two years. The first interview was a shock, I froze during the preliminary interview, and for two years contemplated if I&#x27;d ever quit my job.)<p>Daugherty never had me do whiteboard programming but did ask me some algorithmic questions. These were much easier to answer verbally. In the end I was told I didn&#x27;t have enough experience in consulting working with large companies. (This was a bit of a shock but whatever.)<p>With Google, I never got past the first round. I felt very good with my solution coding in a Google Doc, but, they had wanted me to implement the Python bisect_left function. Instead I just used it to solve the problem.<p>At Amazon I made it onsite, but again, I failed to whiteboard a hashing function to their satisfaction. They told me it could have been overlooked if my architecture skills were stronger. They did complement me highly on my communication skills, which I appreciated. (I had worked for two weeks rewriting my accomplishments journal using the STAR[1] format.)<p>Target (where I work now), was completely different. I was given a choice of real-world-like problems to solve and a couple weeks to code. Two were pretty heavily algorithm&#x2F;math-focused but the third was right up my alley -- implement a microservice backed by a data source and a different (potentially flaky) service. I took my time, wrote code I&#x27;m proud of, deployed it on Google Cloud, and explained my solution in detail to a Principal Engineer. There were still personality and experience questions (and I think also some algorithm questions) but nothing like my other experiences. It felt much more grounded in reality. Are you a solid developer, good communicator, and good fit for the company. In the end I didn&#x27;t get the exact position I applied for but I&#x27;m still extremely happy.<p>My takeaways:<p>1. Maintaining an accomplishments journal as more beneficial than I could ever imagine. I write down everything I&#x27;m proud of - when I&#x27;m proud of it even if it seems minor. I can always delete it later. Also, the STAR format is actually really good.<p>2. Don&#x27;t stagnate in learning. Technology and methodologies are changing all the time. I don&#x27;t follow every fad or code in my spare time but I feel strongly taking some time periodically to maintain a level of expertise is a good investment.<p>3. Knowing my strengths and weaknesses really helped me focus while preparing for my interviews.<p>4. Learning from interviews and maintaining confidence was big for me. I took notes immediately after each interview of what I wanted to work on. I asked for as much feedback as I could get. These notes made it back to my journals and are things I&#x27;ll refresh time-to-time because I know nothing is a given. Who knows what I&#x27;ll want in another 15 years.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Situation,_task,_action,_result" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Situation,_task,_action,_resul...</a>

These companies might also not pay very well (like fb, google, etc). Something to keep in mind.

How can more companies adopt this and give candidates more take home tests rather than leetcode

It&#x27;s definitely important to prove you understand the core concepts required to be a successful developer, such as using efficient &amp; scalable approaches to solve a problem, but writing quality code from scratch simply doesn&#x27;t mix with high anxiety. And it&#x27;s not representative of how programming work is done in the real world.<p>I think a good middle-ground is pair programming where the interviewer writes the code based on the pseudo-code provided by the interviewee. This way, the interviewee displays their thought process and communication skills without being bogged down by programming language nuances.

Man I&#x27;ve said it before, but I need to get the hell out of this industry. Its pointless to argue against the whole whiteboarding &#x2F; leetcode process, it exists for a reason, but I&#x27;m quickly realizing everything about the industry, including the industry process is just incompatible with the way I work.

I am going to kill myself (exaggeration). I have maybe one of the best cv&#x27;s (I am not saying that, it is feedback from industry) for last year student focused on low-level programming. But I cannot bypass recruiters. Why? because none of them even heard Boost.Beast or anything on my cv. Or any C++ thing I have done as project or my publication. They literally do bunch of find&#x2F;search on the pdf. And because of that I am unable to get any internship, particularly now which there is no meet up or in person networking.<p>P.S. I used to have extremely successful in person networking before COVID19.

We use a simple 2 step process that allows both the company and the candidate to have more certainty about the opportunity. This only applies to technical jobs.<p>1 - First interview. Does the candidate know about the company? Does he know anything about the business domain? Conversation about problems he has encountered in his past experiences. it works like a knowledge sharing conversation, you really get to know how well things have been thought of.<p>2 - Freelancing period of about 3 weeks, 20h&#x2F;week - You get to know the technical skills, cultural fit, communication skills and all other aspects that you only arrive to practicing it.<p>So far it has worked pretty well for us - we&#x27;ve hired about 11 developers and refused&#x2F;have been refused by 5. It&#x27;s an empirical process that works for both parties.