61 ms·

Hiring Without Whiteboards

• joaomagalhaes 6y ago
  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. 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. 2 - Freelancing period of about 3 weeks, 20h/week - You get to know the technical skills, cultural fit, communication skills and all other aspects that you only arrive to practicing it. So far it has worked pretty well for us - we've hired about 11 developers and refused/have been refused by 5. It's an empirical process that works for both parties.
  • non-entity 6y ago
    Are all your candidates students or unemployed at the time of interviewing? How do people find that 20h/week?
    • joaomagalhaes 6y ago
      the average is 15h-20h per week. Imagine 2h each work day + weekends. We don't enforce these hours, if they want they can work more or less.
  • ffdjjjffjj 6y ago
    Wouldn’t this exclude the strongest candidates who can get other job offers?
    • joaomagalhaes 6y ago
      No, it gives us the opportunity to show the strongest candidates a better alternative
• shiftF5 6y ago
  This seems to promote Google Docs > whiteboard, what? At least you can brainstorm or draw diagrams on a whiteboard. IMHO the worst of these options is coderpad/hackerrank/etc. - it's robotic, discourages pseudocode, and perpetuates the idea that rote memorization is required to pass an interview.
  • 8organicbits 6y ago
    Brainstorming with a candidate is great, when you can get them to let you in to their thought process. It easily can turn a technically incorrect answer into a strong answer.
• samfisher83 6y ago
  Companies like google and facebook are paying 200k for entry level engineers. They aren't going to have any issues getting people to apply even with the whiteboard interviews.
  • pdubs1 6y ago
    What percentile of entry level devs get this? I'd imagine perhaps the top 10% or top 20%. I imagine the 50th percentile get something more like 100-150k, which in the bay area, compares to perhaps 60-80k in the middle of the country.
• crsv 6y ago
  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.
  • simonhamp 6y ago
    > they often give a very good and reasonable signal that often has a high corollary to work performance Do you have any statistically significant data to back this claim?
    • madamelic 6y ago
      There is statistical data saying the opposite: http://chrisparnin.me/pdf/stress_FSE_20.pdf http://chrisparnin.me/pdf/stress_FSE_20.pdf That whiteboard interviews are actually testing how you perform under stress rather than how good you are at your job. Additionally, in my opinion, it measures how good the interviewer is. If you get a bad interviewer or even just one in a bad mood, just pack your bags because you aren't getting it. Whiteboards are incredibly arbitrary in my opinion, if taken alone. If it is part of a complete assessment, ehhhh.
      • virtuous_signal 6y ago
        >There is statistical data saying the opposite Interesting study and really good discussion on HN at the time, but the opposite of "[Whiteboard interviews] often give a very good and reasonable signal that often has a high corollary to work performance" would be something like "People who do well at whiteboard interviews tend to be worse performers at work." I don't think that's what the study said at all; rather that people do worse at whiteboard problems when they're being watched vs. not being watched.
        • 6y ago
• 0xFFC 6y ago
  I am going to kill myself (exaggeration). I have maybe one of the best cv'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/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.S. I used to have extremely successful in person networking before COVID19.
  • leetrout 6y ago
    Is your username a reference to your humanity?
    • 0xFFC 6y ago
      What is that supposed to mean?
      • leetrout 6y ago
        I didn't know if it was a reference to a gene id
  • enjeyw 6y ago
    This feedback is well intentioned, so please don't take it as an attack. As much as we'd rather it not be the case, even for programmers writing skills are incredibly important. This comment is contains a few grammatical errors and is quite hard to read - I checked your comment history and many others suffer from the same problem. As some who hires, if I read a job application with this quality of writing, I'd probably dismiss it. If you're having trouble finding a job, it may be helpful to have someone read over any written material you submit alongside your CV (cover letters etc) just to make sure it's clear and easy to understand.
    • 0xFFC 6y ago
      I really apricate your feedback. Just one thing you should take into consideration, that is, as ESL I am not going to put that much effort on writing comments on HN to check for every grammatical error. I simply don't have that much time and energy. I do understand what you say. But that is not the case sadly.
• new_realist 6y ago
  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.
  • madamelic 6y ago
    "oh no, this 'no-name company' is _only_ going to pay me $100k+ / year while I live in a low-cost of living area, boo hoo hoo" Scrolling through there are a lot of high-quality companies (Auth0, ASOS, Blue Bottle, Basecamp, Buffer, Canonical, CircleCI... and more and more). Just because Google or Microsoft aren't on the list doesn't mean these are backwoods operations. Those companies don't need to bring in new candidates by being on these lists.
    • simonhamp 6y ago
      /raises hand And Elvie! (If you make it to ‘E’) We’re hiring right now :) https://elvie.workable.com https://elvie.workable.com
  • sangli 6y ago
    Anyone else sick and tired of FAANG worship? Lot of groundbreaking stuff came from smaller companies and startups.
  • tchaffee 6y ago
    In other words the companies that 99% of the world's developers work for. What they are "resorting" to is a hiring process that finds good developers at a reasonable cost. "We can't pay you what FAANG pays but we don't put you through a shitty and lengthy interview hazing" is a pretty good proposition to the vast majority of us.
    • kamaal 6y ago
      Most companies don't even have spare billions of dollars to waste playing these games. Your normal companies, with normal budgets, have normal projects, which need people who can get work done. If you want some one who can build web sites using React JS you are better off hiring people who know and have built things using React JS. There is little logic in hiring people who can do some obscure fashion-of-the-week algorithms, assuming if they can do this they can learn React is just plain wrong. A person does what they are good at doing, if some one is good at interviewing their incentives are in changing jobs often to find the next company that can offer a raise. Not getting your work done. Also this whole thing that one must know these algorithms because they might once in a life time face a need for Dijkstra's sometime during midnight at a place where they wouldn't find an internet connection, is unrealistic. C'mon. Get real. Companies are full of situations where people are digging with shovels and spoons, because people don't have the skills to use and build tools and system to save thousands of man hours of manual effort. Code bases are full of tech debt. Deployment problems because tests aren't written, or there is just no CI infrastructure. Lack of skills and productivity is a far more realistic and commonly occurring problem than these once in a decade algorithm needs. On top of this comes the need for proactive problem identification and solving(a.k.a innovation). The fact that FAANGs have to acquihire or acquire companies to grow shows they are not hiring the right people either. As of today if you are hiring for devs. You must look for turn-key projects executed, expertise in one main programming language/stack, ability to script quickly, skills to build tooling/monitoring, ability to produce deployable code, code maintenance, writing test cases etc etc.
• kanobo 6y ago
  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.
  • kansface 6y ago
    You would never hire a senior engineer like this (or anyone who is currently employed), but maybe it has its place for high risk hires.
    • madamelic 6y ago
      You can and it happens. source: work at a place that does this
  • druidmaster 6y ago
    if i ruled the world
  • deleted 6y ago
    [deleted]
  • Johnny555 6y ago
    The most qualified applicants already have a full time job and probably don't want to take a second job.
  • matthewowen 6y ago
    I have a small child and a full time job. It's really not very feasible for me to make time to do a "real project", paid or not. Especially if I'm interviewing with multiple companies.
    • kanobo 6y ago
      Yea, I didn't consider that. My thinking was that the hiring process is such a time suck that the applicant should at least paid for those 'take home tests' and 'in person interviews' everywhere in that list ... but yea I'll go back to the drawing board.
• wendyshu 6y ago
  No one enjoys whiteboard interviews but it's not clear that these companies have better alternatives. Many of them do take home projects which are time consuming. I'd prefer the employer look at my GitHub profile as there's plenty of code there already. Furthermore, I'm not a fan of "interviews" in general, I find that more information is transmitted by eating lunch with the team and talking like normal people.
  • kipply 6y ago
    Recurse Center has a pretty nice model where they give you a part of a program (small) to bring ahead of time (or you can pick any program you've written) and the interview is going through the code and adding a feature or two. That kind of interview mitigates the amount of trivia and preparation-gaming while also ensuring that the applicant can solve problems as a team and is a competent programmer. It is cheatable in that one can memorize implementations of some features, though it seems somewhat difficult and not more cheatable than just memorizing a bunch of CS trivia.
    • deliveryboyman 6y ago
      I'm not too familiar with them, but why does Recurse Center need to interview people for technical positions?
      • pyb 6y ago
        The Recurse Center is a retreat that you attend with other like-minded programmers. I recommend it if you are interested deepening your experience as a programmer, by working on personal projects as part of a helpful community. There is a selection process as mentioned above, but it isn't onerous.
  • johannes1234321 6y ago
    I like whiteboards, if there is an interesting problem. Going through my GitHub account however isn't good. It's full of quick one shot things, experiments and so on, very little production ready code and not representative of anything.
• deleted 6y ago
  [deleted]
• mbil 6y ago
  This is a great list. Thanks for sharing it. 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. 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'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. 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.
  • sangli 6y ago
    I would rather spend 3-4 hours working on a take home test rather than writing on whiteboard. Last year, I did take home test for 5 different companies and all 5 of them invited me to the next round. I yet to have a successful whiteboarding interview.
    • _qulr 6y ago
      But did you get any of those jobs? I wouldn't call being invited to the next round successful if you don't get the job. In fact it's a loss, more lost time for the candidate.
      • bananaface 6y ago
        Yeah seriously - "rounds" don't mean anything unless they publish numbers, and even then it's sketchy. You need to be able to verify that they're actually there to shrink the pool, not just provide the impression of it. Take-homes are free for the company to issue.
• marcinzm 6y ago
  The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it's a horrible system except for all the others. 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'll get a lot more of them than full in-person interviews. Pair programming? That'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.
  • vsareto 6y ago
    Gotta disagree on pairing, as that gives you an actual computer. If it's your own environment, you're at least comfortable with that. You don't have to worry about penmanship and can get IDE suggestions. It's frustrating not being able to get your ideas down quickly enough like when writing code on a board.
  • nsainsbury 6y ago
    I would argue the problem is it's not a one-time cost. You pay the cost almost every time you want to change jobs, because leetcode/algorithmic interview questions are so fundamentally different to what we actually do day-to-day as developers. It is very easy to completely forget all about graph algorithms in, say, 3 - 5 years during which time you've been a productive, valuable member of a software development team that...you know...actually builds things customers care about.
    • pb7 6y ago
      Small price to pay to get more and more absurdly high paying jobs every 3-5 years. Being a productive, valuable member of a software development team is teaching you things that will set you up for success in higher level roles. You won’t be taken for those roles on Leetcode interview performance alone.
• mraza007 6y ago
  How can more companies adopt this and give candidates more take home tests rather than leetcode
  • vvG94KbDUtRa 6y ago
    I really don't understand the idea that take home is somehow more fair or accurate than whiteboards. I've judged and taken both whiteboards and take homes. Take homes are more annoying for the candidate, and in my experience much more subjective from the interviewer. In my experience take home is the absolute worst way to pick a candidate.
    • dudul 6y ago
      When I do a take home I have access to google, StackOverflow, etc. I can spend 15minutes on it, then pause to do something else (while I still sort of think about the problem), get back to it for 30 to 60 minutes, rinse and repeat. Which is exactly how I work in real life. Take homes can actually be compiled and executed against a test suite for correctness. Take homes tend to be more realistic exercises than balancing a f-ing tree or walking some idiotic graphs.
      • kronin 6y ago
        When I interview (and yes, there's whiteboard time), I tell the candidate up front and very clearly, "I will be your Google. I know we don't work in a vacuum"
• dilatedmind 6y ago
  I interviewed with crowdstrike recently and the interview was a whiteboard system design interview followed by 4 whiteboard lc easy problems. So I'm not sure how accurate this list is.
• cletus 6y ago
  Oh God, here we go again. Coding on a whiteboard in an interview is not "broken". What is "broken" however is making the problem the candidate needs to solve "hard". I can't stress this enough: a whiteboard coding test is nothing more than a negative filter. It's to filter out people who can't turn a simple idea into code as these people exist. This is why FizzBuzz was such a simple problem. But interviewers fall into the trap of thinking "this problem is too easy" 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 "trick" or not (eg reversing bits in O(log n) or the tortoise and the hare). This actually makes the test completely useless. A negative filter is simply a filter whereby if you fail it, you almost certainly aren't a great hire but the reverse doesn't apply: there should be no A+ on a whiteboard coding test. It's straight pass/fail and an easy pass at that. 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. 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.
  • yelloweyes 6y ago
    >which will generally require a certain level of communication skills and presentation ability, is the right place for you. It's really not about presentation ability. It's "oh shit I have x minutes to do this and I have to get it right or I won't get the job, oh shit 5 minutes passed already and I haven't done anything" type of anxiety.
    • cletus 6y ago
      And you can't imagine that same person having this mental dialogue? "Oh shit, I have to get up and talk about my project. What am I going to say? What if my director thinks I'm an idiot? What if they ask me a hard question? What if I can't answer the question? Will they cancel my project? Will they bring in someone to rescue me? Will I get fired?"
• bastardoperator 6y ago
  I prefer the take home text. Less stress and I can really show what I know. Sure it's time consuming, but I always try to have fun with it. If I get a take home test, and it's writing some code, I know I have a shoe in the door. I interviewed at one of these companies in the list. I'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.
• bit_logic 6y ago
  Another tech interview thread. For the side that supports these types of interviews, I'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'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. I'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. I'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/pencil and allow them to write code the way it'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't test anything. Think about how limited it is and how different it is (for example, you can't just press an up arrow and add a newline, have to find an eraser and start over). It's yet another useless skill to learn just for interviews (writing compilable code on a whiteboard/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). I hope people start pushing back on this. The reaction should be, wow you care so little about your interview process that you can't get a $200 chromebook in here?
  • choppaface 6y ago
    As somebody who has sadly had to make hundreds of candidates write on a whiteboard, here are problems I’ve run into getting the candidate a laptop: * IT just fails: they’re unwilling to supply it, there aren’t enough, the current laptops on hand are junk, or the default password is wrong. These all happen with HR buy-in and funding. * Recruiting just fails: they “have to move the candidate fast because of a competing offer,” they tried to work with IT but IT blocked them, they got laptops themself using their own budget but then ran out. * I failed: I didn’t make time to prepare a non-whiteboard question, I didn’t tell my manager in each and every 1:1 that candidate experience sucks, I had three laptops and I forgot to bring my personal spare to the interview. In general the core problem is there is zero incentive for hiring managers to do anything but shotgun candidate pools like they do today. There’s also no feedback loop to evaluators to help them improve. False negatives are completely tolerated despite there being a huge gap between CS jobs demand and CS graduate supply.
• rainyMammoth 6y ago
  The issue with LeetCode style interview is that almost EVERYONE can solve those questions after studying a couple weeks/months. The only thing that LeetCode questions predict is if the candidate has been training for LeetCode questions. 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.
  • logicslave 6y ago
    Right but in some ways this is what they need. Someone who can stare at computer science material, that is probably boring, for long periods of time. Someone who has a good memory for details, can remember routines. Can "solve" problems that have been solved before by applying theory. Someone who is willing to follow the rules and go through the process.
    • fogetti 6y ago
      I think you made a logical somersault. Leetcode doesn't imply any of those, neither good memory for details or that you can "solve" problems that have been solved before by applying theory. You missed the whole point of the OP's post it seems. The only thing that leetcode implies is that you can solve leetcode tasks.
      • amznthrowaway5 6y ago
        Leetcode implies all of those, and just like in mathematics competitions, being able to solve these problems implies a high level of ability.
        • fogetti 6y ago
          Nope
    • Peritract 6y ago
      Remembering the solution to a problem isn't the same as solving it. Testing if people can regurgitate solutions is at best pointless.
• sturmeh 6y ago
  By no means an exhaustive list, so really just promoted listings.
• rajacombinator 6y ago
  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. 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.)
• tptacek 6y ago
  What you really want to know is whether the take-home assignment really decides anything, or whether it'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't have much faith in them, and still select candidates based on interviews and resume screens (or "pair programming" projects that are really just multi-hour or multi-day interviews). I have a hard time believing that this many firms have take-home assignments that really matter, and aren't just another hoop candidates (or, maybe, disfavored candidates) are forced to jump through.
  • kasey_junk 6y ago
    I’ve gotten to the point where it’s simpler than this. Firms get 16 hours to evaluate me. If the take home isn’t a huge component of that I know they’ve cargo-culted it. I won’t do it if they can’t promise that isn’t the case. I say this as someone who was an extremely early adopter of take home tests and think they are the highest signal filter you can reasonably have in the US. So many places have added take homes in the worst possible way without removing all the other nonsense. It’s as if orchestras started demanding high pressure auditions and then threw out the results if the person talked a good game in an interview.
• dbcurtis 6y ago
  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. 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. The people who can produce quality code for your organization will show up pretty fast.
  • asdff 6y ago
    In higher education there has been a lot of walk back from tests like the GRE in most fields. It turns out, being good at the GRE only correlates to your ability to be good at taking the GRE, and doesn't correlate with actual graduate school performance or outcomes. Performative interviews occupy a similar space. You spend all this time and effort studying for something at is ultimately irrelevant outside of the interview. Just a pure waste of brain cells and calories, with a few new gray hairs for you.
• LargeWu 6y ago
  As somebody who has been interviewing recently, the format I've preferred is from TestDome. I've never used leetcode or others but I imagine they'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.
• IgorPartola 6y ago
  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/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. 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.
  • eximius 6y ago
    I'm not sure why you're being downvoted for asking about their previous work and watching how they treat people.
    • IgorPartola 6y ago
      Eh. I don’t care about downvotes. But yeah if people want to throw the same ten dozen puzzles at each other and then wonder why the people don’t work out, it’s definitely not time to try anything different :)
      • cutemonster 6y ago
        @eximius, > service workers ... > watching how they treat people They are not people though. But yes, agreed that we should treat them well
  • scatters 6y ago
• jb775 6y ago
  It's definitely important to prove you understand the core concepts required to be a successful developer, such as using efficient & scalable approaches to solve a problem, but writing quality code from scratch simply doesn't mix with high anxiety. And it's not representative of how programming work is done in the real world. 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.
  • cutemonster 6y ago
    Interesting idea
• atlgator 6y ago
  Thanks for this list. I'm going to need a new job soon.
• Apocryphon 6y ago
  This is yet another tech interview discussion, so I'd like to highlight a subthread from the one earlier this month: > I'm actually a little scared to leave my current FAANG gig for that exact reason tbh. I'm fairly certain I wouldn't make it back in the door without more leetcode grinding + repeated loops than I'm willing to do at this point in my career. >> I'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't really leverage anything I've learned over the past 7 years of my career in the interview, at least at the early stages. >>> I feel extremely little of what I'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 "endgame company" where I feel it's worth staying long term. https://news.ycombinator.com/item?id=23848717 https://news.ycombinator.com/item?id=23848717 Even as we debate the validity of the metrics measured by technical interviews, it's also worth considering the metrics used to measure engineer worth in the industry at large. This existentialist "fear and loathing in FAANG" discussion was quite illuminating, and a little sad.
  • User23 6y ago
    There's no rule that says you can't apply for more than one role at a given FAANG. It's not like they blacklist you for not getting hired in one role. They know they have an intentionally high false negative rate, you get to try again.
    • flak48 6y ago
      I think Google blacklists you after 3 failed onsite attempts.
  • biql 6y ago
    > I'm actually a little scared to leave my current FAANG gig for that exact reason tbh. I'm fairly certain I wouldn't make it back in the door without more leetcode grinding + repeated loops than I'm willing to do at this point in my career. Makes you question if this is the precise point of it.
• charliebrownau 6y ago
  Im amazing that no companies are willing to work together to reject - * "Diversity" (Discrimination) quotas - * "Affirmative" action - * Paid time off (Pregnant/sick/etc) - * Income Tax - * GST/VAT - * Payroll/wage tax - * Forced super/retirement funds
• gwbas1c 6y ago
  I just started working at a company that didn't do any whiteboarding or technical challenges. As far as interviewing me goes, they broke all the "rules" that I used to follow when interviewing candidates at my old job. 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!
• smabie 6y ago
  Is it simply a coincidence that people don't like whiteboard interviews and believe they don't work? Seems pretty convenient to me.
  • fogetti 6y ago
    Conversely: Is it simply a coincidence that people like whiteboard interviews and believe they work? Seems pretty convenient to me.
    • smabie 6y ago
      I don't like whiteboard interviews and I don't know if they work.
• dimaryz 6y ago
  what's FB doing on this list?
• 11thEarlOfMar 6y ago
  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 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we'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'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. 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's a check point to look for concerning weaknesses, as well as get buy in from the broader organization. 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.
  • victor9000 6y ago
    This sounds like a pretty reasonable process, are you guys hiring?
    • 11thEarlOfMar 6y ago
      Digital Dynamics, a small company in Scotts Valley, Ca. We make specialty industrial control computers.
• fazkan 6y ago
  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't have good CS fundamentals. By fundamentals, I don'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.
  • asdff 6y ago
    But are you really hiring smart+hardworking people or just people who are really great at working on a whiteboard?
• sytelus 6y ago
  Just curious, does work at these companies require any algorithm design skills or is it usual web/app/database development work?
• Trias11 6y ago
  Best way to avoid this BS is to be introduced by an established insider to help bypass this.
  • malechimp 6y ago
    There. That's it. All this is a far-from-optimal filter for the total strangers. Get a foot in the door with an established insider and you get right to the last interview(s). No WBs, no take-home projects.
    • non-entity 6y ago
      Does this actually work in practice? From my understanding knowing someone might get you past the initial HR / ATS hell to a first round, but you mostly have to follow typical processes after that.
      • Trias11 6y ago
        In some cases yes. In my experience they were even apologetic "sorry, we have to do this, let's get over it". Once the pull to get you in is in place - it will help to put a checkmark in internal bureaucracy checklist and minimize unrelated interactions.
• sourgrape 6y ago
  FAAG all use white board - there must be a reason. I just do not understand - if you are a competent programmer, what are you afraid of white board Interview? Show your ability or stop whining!
• shahbaby 6y ago
  When there are hundreds of applicants for 1 role of which the top 10 are all equally qualified, no interview process will seem fair. So how do we break the tie? Whiteboard? No whiteboard? Pair programming? If we accept that after a certain point the process is random, why not simply break ties with first come first serve? In the final few rounds, is a candidate who can solve the exotic DP problem just because he's seen it before really any better than the others?
• langitbiru 6y ago
  Maybe we should give options to candidates. If I were to hire software engineers, I would offer every option to them: 1. Whiteboard interview 2. Opensource contributions 3. Take-home assignment 4. Becoming contractors for a short period 5. Etc So if they fail whiteboard interview, they can redeem themselves with their opensource contributions. If they don't have opensource contributions, then they can take home our assignments. And so on. So it's fair (I think).
  • asdff 6y ago
    Why is US-based computer science seemingly the only field with these strange nonstandard interview processes? It's like a fad that turned into an arms race and is now the default response for any american technology company's HR department, because these guys certainly aren't in HR for their creativity.
  • hansvm 6y ago
    That's not necessarily a bad approach aside from the cost to the hiring organization to maintaining so many workflows. It lines up with, e.g., Triplebyte's and Google's studies about how a candidate's success in a role is tied much more closely to the moments where they impressed you the most rather than any kind of minimum bar you need to meet or some kind of average performance. By giving the candidate the opportunity to impress you however they're best able to do so you could plausibly get a stronger signal.
• nextlevelwizard 6y ago
  If you can't explain your thought process on a whiteboard you don't know what you are talking about. Literally no company wants you to make actual production code on a whiteboard.
• remote_phone 6y ago
  They need to take Netflix off the list. All they do are algorithmic whiteboard interview questions.
• me551ah 6y ago
  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/js/css, Xamarin, .NET Core, Code generation, Java microservices , Native Windows and AWS services. 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't satisfy the criteria for companies who ask for 'x' years of experience in 'y'. So whiteboard and algorithm problems work well for me, because there's not really much to learn and memorize in those topics.
• Agentlien 6y ago
  I live in Sweden and we seem to have a very different interview culture. I've never heard of whiteboards or trivia questions, here. I've only gone to four interviews (across eight years), and been lucky to get an offer each time (three of which I've accepted). They have all been primarily discussions about personal experience, hobby projects, personal interests, would-be responsibilities, benefits, and company culture. At one place (Ghost Games, an EA studio and the only company which wasn't purely Swedish) I had to complete a code assignment (create a clone of a classic arcade game in C++) ahead of the interview.
  • estomagordo 6y ago
    I saw both sides in Sweden. Including being the interviewer who discovered that senior applicants with over 15 years of experience could not for the life of them figure out how to reverse a string. Not something that I could have found out during our casual conversation about past experiences, of course.
    • zerr 6y ago
      So s/he failed the (interview) specific anxiety test.
    • cutemonster 6y ago
      They were typing on what, when trying to do that? (Nothing against whiteboards or laptops or paint brushes, just wondering) What type of job were they applying for?
  • TrackerFF 6y ago
    Norway, too. Only ever encountered WB questions at one place, and it was a FAANG-type American company with a satellite office here. Everyone else were just normal interviews, with mostly behavioral questions, and some softball technical questions.
• a_square_peg 6y ago
  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: "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." - http://origins.sese.asu.edu/ses405/Additional%20Reading/Frosch%20on%20System%20Engineering.pdf http://origins.sese.asu.edu/ses405/Additional%20Reading/Fros... Current technical interview processes with its whiteboards and technical questions will undoubtedly lead to hiring the first type of music student.
• darepublic 6y ago
  I don't fully agree with the part of the title that reads Companies that don't have a broken hiring process Only because they don't currently do whiteboards. I feel like interviews in general is a tough problem
• rendaw 6y ago
  I haven't seen portfolios mentioned yet, but that's another option. Pros: do it once, use it at multiple interviews. Cons: more difficult to make sure it's original work, difficult to come up with ideas. I did CV screening and very few people had anything, it's not like a portfolio project needs to take more than 2-3 hours to create. Portfolios are a common requirement in other fields where creating a portfolio is even part of the educational process.
  • red2awn 6y ago
    What kind of portfolio worthy projects take less than 3 hours to create?
    • rendaw 6y ago
      Scraping Kickstarter projects with certain keywords and sending yourself an email, a tool for slicing csv files, reimagining various basic command line tools in new languages, a tool to scan a file with an unused filename in the current directory, a program to sort music by idv3 tags, an http media server, etc... All of these would show 1. basic language ability, 2. some simple algorithms, 3. ability to do something to completion.
• genezeta 6y ago
  One thing I've been wondering lately about take-home tasks is how everybody complains about time estimates, and yet here's a bunch of "small projects" which someone pretends to have very precisely estimated. Unfortunately, most companies fail to honestly estimate the cost of the tasks they assign for these processes. Many of them because they just don't take into account numerous small tasks that the candidate will need to deal with. I've seen a lot of these tasks ask for setup instructions, good unit tests, explaining any decisions you make, etc. In case there's any visual user interface (e.g. some web component) they also ask for it to be nice, as in "we don't want a designer but we need you to make it somewhat nice". And then they'll say it should take just a couple of hours. I've also seen a fair number of others casually say their task should only 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.
  • asdff 6y ago
    I would never apply for a job that made me do a homework assignment. This is a huge red flag that this employer doesn't value your life outside of work at all.
  • malechimp 6y ago
    I've done this a couple of times. All for German companies in Germany. The last one took me a weekend. They liked it and booked me a ticket for on-site. Where they whiteboarded the hell out of me and rejected me on the basis of not getting the right answer fast enough and using wrong syntax in a couple of statements. And there was not a single question about the take-home project. After that I just decided I'm not going to put the time and effort in that sh*t anymore. I'm not even going to go out of my way to accommodate interviews in my working hours. Next time it happened I replied back that I'm not interested. For the record, they wanted a silly automation in AWS and kubernetes. Most of the time would go to setup everything up as my future-employer assumed that I had an AWS account and that AWS is the only cloud that matters. (I work on a different provider daily). Both times it was automotive-related IT. Dunno if that's something to do with it. My take-away so far: Whiteboard sucks but at least it respects your time while the take-home proj does not necessarily keeps you from wb and is usually ridiculous to a large extent.
• mesaframe 6y ago
  I'm absolutely fine with whiteboards. What I'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.
• leoedin 6y ago
  The best interview test I'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. It was good because: 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. This solved most of the problems I'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're either making them waste hours of time before they can start, or disregarding good candidates. Ultimately you want to find candidates who can solve problems and understand software architecture. Unless you're interviewing for a devops position, making them spend hours setting up a build environment seems like testing for the wrong thing.
• collyw 6y ago
  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. 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. 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.
  • judofyr 6y ago
    > 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. Seems like a good solution if the candidate has a side project. However, many candidates might have their majority of the "good" code they've written owned by their previous company. > I am sharing in the hope that this will become the standard Hopefully it can become a standard option. There's probably never going to be a standard technique which fits for all candidates (or employers).
    • asdff 6y ago
      >However, many candidates might have their majority of the "good" code they've written owned by their previous company. Which is a huge problem in this field that stymies wider innovation in technology by limiting discussion around technology through literal gag orders. You should be able to reuse whatever you write. It's silly. I'm not stealing cash out of the register, the company doesn't lose anything from me keeping a copy of my code snippet around for future reference. It's not the whole codebase, it's just what I've contributed. I swear, lawyers have ruined technology.
• matthewmacleod 6y ago
  I agree that the cliché whiteboard interview is just awful – I've had my share of terrible ones. However, there is one form of whiteboard interview that I really like – it's where the interview is about system design and architecture rather than coding problem nonsense. I think the first time I saw this was at Google, where the question was pretty much "We are going to design Google Maps from scratch – what does it look like?". The interview is about evaluating the candidate'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. I liked it so much that I've built it into our own recruitment process for our most recent role – it'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's been really interesting to see how different candidates have approached the process. (Anecdotally, the biggest indicator of a good candidate so far has been the use of abstraction rather than concrete technologies - i.e. "I would have a queueing system here and an object store there" rather than "I would have Kafka here and push to S3 there").
  • cutemonster 6y ago
    I like these interviews, seem like fun. > a system that we want to build. We let the candidate lead the design They never got upset and thought they were working for free? If you were to use their designs and ideas, then what if they later claim you've infringed on their IP?
• usgroup 6y ago
  It’s a funny cultural thing. Here is a caricature: 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. 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. 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 ...
  • VonGallifrey 6y ago
    > 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 ... That might work if you have 110 people applying for 100 positions. Just hire everyone and then fire 10 people. Over hiring 10 people probably isn't that much of a problem. However that does not work if you have 100 people applying for 5 positions. This is the situation we found ourselves in and we had to filter somehow. We chose to do a very simple code challenge which ended up being a very effective filter.
    • usgroup 6y ago
      Sure but you’re bound to say that ... Find me a hiring manager than publicly says anything else. That’s kind of part of the point. I roughly recall google touting ~50% hiring success rate and that’s with a 4 interviewer, 10-15 man interview process, and undoubtedly a massive false negative rejection rate. I think some undesirable attributes are observable in fairly short screeners ; sure screen away . But I bet you that you’d do at least as well if not better by just selecting at random past that point.
• zerr 6y ago
  We need a similar list for companies without Agile.
• posharma 6y ago
  These companies might also not pay very well (like fb, google, etc). Something to keep in mind.
• anticristi 6y ago
  I feel a better title could be "Hiring without CS trivia". 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.
• bob1029 6y ago
  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. 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. 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.
  • lowwave 6y ago
    Yeah, there are so many times where I'm asked to solve some sudoku puzzle in an interview. It is really sign of a big interview question.
  • drglitch 6y ago
    Arrangements like this are much harder in US because 1) by default there is no health insurance if you’re a contractor, and obtaining your own is incredibly expensive and 2) there are also pretty complex tax implications of being a contractor; there are many other factors as well. It also puts a candidate at a disadvantage, because looking for a job is heavily one-sided burden. On a personal level, as both (occasionally) a candidate and a senior hiring manager, I always wonder about white boarding - i believe it works when the interviewer is looking for your thought process, and not code specifically. For example, something as simple as saying “I don’t expect this code to compile” at beginning of interview immediately puts candidate at ease and let’s you understand their logic and not the ability to recall specific function signatures on the fly.
    • zerr 6y ago
• _qulr 6y ago
  Programmers change jobs very frequently. They come and go. So why are we so obsessed with "getting it right", as if hiring a programmer were like signing a 30 year mortgage? Hiring is a crapshoot. You'll make bad hires. That'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. No, a bad programming hire is _not_ devastating to your company. You'll live. A bad CEO hire could be devastating, but you can't do a whiteboard or a take-home test for that. "The perfect hiring process" is classic premature optimization.
• non-entity 6y ago
  Man I've said it before, but I need to get the hell out of this industry. Its pointless to argue against the whole whiteboarding / leetcode process, it exists for a reason, but I'm quickly realizing everything about the industry, including the industry process is just incompatible with the way I work.
• fogetti 6y ago
  Can someone explain to me why isn't it ever part of the discourse to talk about certifications? 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. 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.
  • twic 6y ago
    The best programmers i've worked with don't have degrees in computer science, or anything like that. Metallurgy, civil engineering, mathematics. On the other hand, i've worked with plenty of people with CS degrees from respectable universities who were useless. A degree is not anything like a certificate, and universities simply aren't in the business of actually deeming anyone suitable to hold any software engineering job in the industry. Even if you fixed this, so that somehow every competent programmer, and only competent programmers, had some certificate from a university, all it would do is let you hire graduate developers easily. It wouldn't let you sort the wheat from the chaff at senior level.
    • fogetti 6y ago
      You completely missed the second part of my post: "The whole hiring process could be replaced with a timely renewal of accreditation." The accreditation would be available to anyone. Just like anyone can become a lawyer in Japan for example. You don't need to hold any diploma for that. Although it might increase your chances to get accredited if you have formal education.
      • twic 6y ago
        Fair enough, that does address the point about hiring seniors. But if universities can't currently usefully certify people for fundamental development ability, after having them on campus for years, i don't see how they'd be able to accredit seniors for the more complex skills they need.
• smashface 6y ago
  A thought I had recently was to shift from having candidates write code to have them review code. I'm sure it's not an original thought, but it comes with a few advantages. 1. Reading someone else's code is usually harder than writing your own and in most projects you spend more time reading code. You're seeing how they'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's work and how well they can communicate their own ideas.
  • tchaffee 6y ago
    Some of the very productive developers I have worked with are not great at code reviews. It's a different skill from writing code and not everyone who is good at coding is good at reviewing other people's code. Considering most of us spend about 90% of our time coding and a very small amount of time doing code reviews, your best signal in my experience is just giving candidates something to code.
• robert_g 6y ago
  Adding my own personal experience. At the end of last year I wanted to change jobs but I was paranoid about my raw algorithm knowledge. I've been a consultant for over 15 years. The last company I worked at for a decade. I'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. I know my limitations and I know how to find answers. 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. 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'd ever quit my job.) 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't have enough experience in consulting working with large companies. (This was a bit of a shock but whatever.) 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. 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.) 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/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'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't get the exact position I applied for but I'm still extremely happy. My takeaways: 1. Maintaining an accomplishments journal as more beneficial than I could ever imagine. I write down everything I'm proud of - when I'm proud of it even if it seems minor. I can always delete it later. Also, the STAR format is actually really good. 2. Don't stagnate in learning. Technology and methodologies are changing all the time. I don'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. 3. Knowing my strengths and weaknesses really helped me focus while preparing for my interviews. 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'll refresh time-to-time because I know nothing is a given. Who knows what I'll want in another 15 years. [1] https://en.wikipedia.org/wiki/Situation,_task,_action,_result https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
• mountainboot 6y ago
  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. 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.
  • nikon 6y ago
    I had the same experience on some vague Postgres question for a Rails job when I was junior. I asked a similar question along the lines of: how often do you use this day to day here? Similar response.
    • braythwayt 6y ago
      For many engineering candidates, we ask them to design the data schema for a calendar. I’m sure my employer and the question are not a secret. We have various follow-ons, like handling the wild number of ways meetings can be periodic, exceptions, and so on. Nobody has ever asked me how often we need to build calendaring software, because I explain right up front that while this is a “toy” question, our core product functionality schedules people, and nearly every feature from a calendar app has some analogue to things we either do, or are asked to do but haven’t prioritized yet. I think it’s ok to ask “toy” questions, but I also think that there should be a ready answer to the question “Does this have anything at all to do with the job?” p.s. We don’t ask a question directly about scheduling, for a simple reason: Almost everybody understands the basic idea of a calendar, so it’s a more “level playing field” for candidates to think about calendars than schedules.
      • partyboat1586 6y ago
        Schema is something you work with everyday so that is fair. Even if the particular schema is for a made up problem it's fairly close to reality.
• farcaster 6y ago
  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 ("oh, you consider yourself a good self-learner? French? I bet you couldn't read some news in French if I opened any here right now. JUST KIDDING") 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. They took a month to send me an email saying I wasn't accepted.
  • malechimp 6y ago
    IMO you should have ended the interview the moment you detected that you were being treated poorly. Let alone not doing the homework.
• 29athrowaway 6y ago
  When the bar is low and interviews are easy, the bar is not only low for you, but also for your coworkers. If the interview bar is too low, you will be exchanging hours of frustration by months to years of frustration.
• lovetocode 6y ago
  Are the STEM fields the only ones with asinine interview processes? What does an interview as an accountant, sales or manager look like?