TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

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

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The problems with live coding interviews

86 pointsby garrettdimonabout 2 years ago

32 comments

bennyelvabout 2 years ago
A perspective from the other side of the desk (playing devil&#x27;s advocate here):<p>There&#x27;s a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven&#x27;t seen before and break it down to solve it in a sensible way.<p>There are plenty of programmers who fake their way through a career <i>without</i> having that skill. They just copy stuff and never really understand it. They&#x27;re fine for some types of programming career, but if your business involves solving new and novel problems then you have to know which type of programmer you&#x27;re hiring.<p>A contrived live coding exercise gives you a strong signal on this. It does have a decent chance of producing a false negative, but only a very small chance of a false positive, and that&#x27;s the trade that has to be made with this kind of approach.<p>Is a better option to not do this kind of assessment, hire the person, find out that they can&#x27;t do the hard bits and then fire them within 6 months? I&#x27;ll take some convincing of that...
评论 #35702028 未加载
评论 #35702166 未加载
评论 #35702061 未加载
评论 #35703199 未加载
评论 #35704817 未加载
评论 #35702189 未加载
评论 #35702010 未加载
评论 #35707144 未加载
评论 #35721919 未加载
评论 #35704081 未加载
macawfishabout 2 years ago
Recently I took a leetcode screening, my first ever, and failed to complete one single question in the allotted time due to a minor panic attack and a sudden loss of focus. The whole time I couldn&#x27;t help but think about the state of the economy and how &quot;this is it, this is my only chance.&quot; Half the time I was fighting with the in-browser IDE and struggling to remember names of JavaScript builtins that usually come easy.<p>Immediately after the time was up I magically started to realize how much I&#x27;d over complicated my one almost finished answer and quickly came up with much more efficient answer. Suddenly it started clicking how simple the first two problems were and how easy it would have been to crank them out if I wasn&#x27;t panicking about the tech bubble collapse.<p>The recruiter later asked me how it went and I grumbled something about how it was a leetcode test. He said &quot;oh well they need to make sure you have the skills for the job.&quot; At that point I was over the whole thing and honestly pretty fired up.<p>Over the next week I proved to myself that I do have the technical skills for that job, and that&#x27;s honestly what counts.<p>¯ \ _ ( ツ ) _ &#x2F; ¯
评论 #35707853 未加载
评论 #35706895 未加载
vparikhabout 2 years ago
I have been in the software industry for 30 years as of this month. I have never had a gap of longer then 6 months and the shortest time with a company was 4 years 8 months and the longest time was 16 years. I have worked on the following technoclogies. Companies range from on of the Big 3 consulting firms to startups. Here are the technologies I have worked on<p>- C&#x2F;C++ on Win16&#x2F;Win32<p>- Assembly language development with Z80&#x2F;8051&#x2F;ARM on embedded microcontrollers<p>- Java (core java, Servlets, J2EE)<p>- Ruby on Rails<p>- NodeJS &#x2F; Javascript<p>- Worked with AWS tech (the full stack)<p>- Relational DB (MsSQL, PostGres, MySql), NoSQL db (MonoDB)<p>- Coded for Linux&#x2F;Unix, MacOS, Windows 16&#x2F;32, PalmOS, iOS<p>I can provide reference for each of those skillsets form my past colleagues.<p>You know what - I probably couldn&#x27;t pass half of the insane coding puzzles these interviewers throw out. Not because I can&#x27;t solve them, I just don&#x27;t remember enough of the syntax or library semantics of the top of my head.<p>At my experience can we just assume that I am a competent coder (maybe not the top 1%, but at least in the top %20) and talk about the job and how I can contribute ? I mean its almost insulting if you ask me to make a linked list&#x2F;reverse a binary tree or other such nonsense looking over my shoulder me with a time limit.
评论 #35710056 未加载
评论 #35706315 未加载
评论 #35706909 未加载
评论 #35708601 未加载
评论 #35738251 未加载
alpinelogicabout 2 years ago
Very on point and I can truly relate to all of this. I&#x27;m so frustrated by the whole process that I&#x27;ve started to decline live coding interviews and any take-home exercises that take more than half a day to complete. Although I have over a decade experience in my field, have been a tech-lead at some of the largest corps, contributed to open source, mentored many Engineers, and really enjoy software, this whole experience is pushing me away from the field. I kind of don&#x27;t care to prove anything to anyone anymore over a 45min interview... will probably start a small biz and move far away from &quot;silicon valley&quot; types of people&#x2F;mindsets.
评论 #35702750 未加载
评论 #35702106 未加载
评论 #35701907 未加载
Ancapistaniabout 2 years ago
I&#x27;ve been on both sides of live coding interviews multiple times. I generally agree with the author, but I don&#x27;t think any of the issues he brings up are insurmountable.<p>When I&#x27;m the applicant, I make it a point to take control of the narrative by saying something like:<p>&gt; If it&#x27;s alright with you, I&#x27;d like to approach this as an opportunity to expose how I approach problems in general rather than how I&#x27;d solve this specific problem. I&#x27;ll speak stream-of-consciousness as I go through it so you can get an idea of how I&#x27;m thinking about it. Feel free to ask questions if you&#x27;d like; I&#x27;ll rely on you to decide whether it&#x27;s more important to you that I complete the task or explain my reasoning. I&#x27;m happy to switch to pseudo-code or just discuss potential approaches if we run short on time.<p>When I&#x27;m the interviewer, I open with pretty much the same thing. My goal is to put the applicant at ease (to the extent that I can) and make it clear what I&#x27;m trying to get out of the session:<p>&gt; First, let me say that it doesn&#x27;t matter to me if you complete the exercise or not. At this stage of the interview process I&#x27;m confident that you&#x27;re more than capable of solving the problem, so lets use this as an opportunity to get to know each other and see if the way we think about logic is compatible. I&#x27;d love it if you could point out things you&#x27;d change, but don&#x27;t worry about trying to &#x27;finish&#x27; or end up with production-ready code. It&#x27;s just a means to an end.
评论 #35706751 未加载
uptownabout 2 years ago
I’ve never tried this exactly, but I wonder how “live coding” interviews might go if the interviewer was the one doing the typing&#x2F;coding and the candidate’s role was to verbalize what the interviewer was doing (and why) - and also guide them to some degree.<p>It’d be more akin to pair-programming, which some of the interviews I’ve conducted have evolved into, depending on the strength of the candidates.<p>Would that capture enough to get a sense whether this person gets the gist of the code being written such that they could replicate the same output in a less contrived scenario?
评论 #35702924 未加载
评论 #35706881 未加载
评论 #35706219 未加载
评论 #35702340 未加载
lbrinerabout 2 years ago
These debates have been done to death and mostly I also think that the article is a fairly typical strawman argument. Take the worst way to do a live coding test, point out the problems and then dismiss the whole idea.<p>What else are we supposed to do? Take the fact that you can talk a good game as enough of a signal to invest 10s of 1000s? Assume that everyone with 20 years experience is as good as everyone else?<p>The problem is that there are no reliable signals. Most Developers I have interviewed have a massively inaccurate ability to judge their own ability (in both directions). I&#x27;ve lost count of the number of times candidates have rpomised that they can just learn whatever they don&#x27;t already know and haven&#x27;t been able to do it to any degree.<p>Qualifications are meaningful in some contexts more than others but most people in the UK don&#x27;t have comp-sci qualifications.<p>So yes, I will use various coding exercises because depending on the level, it shouldn&#x27;t phase someone to be given something quite simple and to see how they approach it (do they write tests first? Ask some good scope questions? Explain why they&#x27;ve done something the way they did?)<p>I have failed one of these tests in the past thinking I was a good Developer (I am!) but I don&#x27;t blame the test or the process, I realised that my approach was haphazard and not an objective good look to an Interviewer so it was actually helpful.
评论 #35714892 未加载
lucisferreabout 2 years ago
This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently <i>need</i> to focus on speed or performance. It doesn&#x27;t have to be a hard &quot;galaxy-brain&quot; problem. It doesn&#x27;t have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be able to complete without too much fuss.<p>Whether this is actually the case comes down to the hiring manager.<p>If the hiring manager decides to optimize for performance in the coding interview then yes everything said here is true. They will typically hire people who can perform well and fast at simple coding test type problems above other any other desirable attributes.<p>If however, they simply evaluate the ability to work through (at any reasonable pace) a fairly trivial coding task, but make the hiring decision on bulk of the rest of the interview, then it shouldn&#x27;t be a problem.<p>The problem is most hiring managers have not been selected for their ability, or even trained, in interviewing. A coding test is easy to set up (or copy from somewhere), administer and evaluate. It is often literally the least they could do.<p>What this post describes is simply hiring managers who lack interviewing skills. Personally, I would probably want to avoid reporting to such a person.
评论 #35702797 未加载
评论 #35706333 未加载
评论 #35702267 未加载
评论 #35704165 未加载
评论 #35702574 未加载
kayo_20211030about 2 years ago
Your experience sounds horrible, and unfortunately those sort of &quot;tests&quot; are just a horrible thing. Generally, do NOT do take-home exercises. That&#x27;s your time, which has value; the company doing the hiring contributes nothing. At least, in a live-coding exercise both you and they have some skin in the game. As with all tests, good or bad, part of the test is actually doing the test. Often it&#x27;s less what you know, or could do; and more about &quot;can you do the test?&quot;, and mostly &quot;doing the test&quot; is a poor proxy, and the whole exercise becomes a waste of everyone&#x27;s time.
评论 #35702037 未加载
评论 #35695648 未加载
评论 #35702701 未加载
评论 #35695584 未加载
评论 #35704791 未加载
评论 #35702388 未加载
评论 #35707194 未加载
评论 #35705250 未加载
flimsypremiseabout 2 years ago
I keep seeing people claim that no one offers alternatives to live coding in interviews, but not only does the author provide an alternative (take home coding test&#x2F;project), there are obviously many alternatives to live coding. I&#x27;ve been working in this industry for over two decades, and I&#x27;ve interviewed more candidates than I can count. I can assess a candidate with a 20 minute conversation, because a candidate&#x27;s understanding of the context and theory of how and why things are done the way they are determine how good they are at the job. Ask them what happens when you visit a website. The amount of detail they go into, and what details they focus on, will tell you an enormous amount about them. Ask them whether they prefer an OO or functional approach to organizing code. The good candidates will have thorough, well-thought out opinions, and you&#x27;re handing the bad candidates enough rope to hang themselves.<p>Of course, in order to be able to assess the answers to these questions in an effective way, you need to be able to very knowledgeable yourself, and that&#x27;s the real root of the problem here.
评论 #35707115 未加载
robomartinabout 2 years ago
Software development is not a performance art (like playing the piano). Putting someone in that kind of a situation is, well, sorry, as dumb as can be.<p>What&#x27;s important is how people approach computational problem solving, not if they can write a solution in 1 to 45 minutes. Really, who cares?<p>One of my go-to examples is trying to work from home. Which is great, yet has its challenges. We have three German Shepherds. They are lovely. However, when a delivery arrives or the gardeners are out nearby, well, it&#x27;s mayhem for a few minutes. I&#x27;ve come to understand that I should just take a coffee break when that happens. I can&#x27;t even do mid-level math, much less focus on a difficult CS problem during those moments. And it takes a good 30 minutes before my head can be back on task.<p>Stop treating software development like performing art or athletes having to perform in the heat of a game. That is not what we do. At all.
whoomp12342about 2 years ago
If I do a live coding challenge, it is absurdly simple and is meant to root out people who have literally no business being in the room.<p>Write a function that takes in a string and returns 1 if the amount of letters in the string is odd. It returns 0 if the amount of letters in the string is even.<p>If you can do this, we are good. I dont need NP hard or whiteboarding or algorithms. I can tell how good you are just by talking to you about your background.
评论 #35724498 未加载
评论 #35704069 未加载
评论 #35704737 未加载
评论 #35706446 未加载
jamesgillabout 2 years ago
The problem with live coding interviews is that they shouldn&#x27;t exist.<p>Another problem is that we&#x27;re prone to thinking that being able to do well on tests equates to doing well in life and work--despite a stunning lack of evidence in support it.
评论 #35702763 未加载
nailerabout 2 years ago
Also a bunch of us have autism, so coding, presenting, trying to gauge the audiences, existing understanding, ensuring remaining available space on the whiteboard, working out, went to talk, and went to type, making sure you were in gauged with everybody in the room, and all the other aspects of presentation at the same time is difficult.
评论 #35712862 未加载
RoyGBivCapabout 2 years ago
I think <i>reviewing</i> code is a much better method.<p>It&#x27;s a real skill you&#x27;ll actually employ. You&#x27;re coming at the code cold, which is actually a realistic scenario you&#x27;ll encounter on the job. Your ability to catch bad ideas and prevent them from getting literally codified is a valuable skill. And all of that is worthless if you&#x27;re in a state where you can see a mistake, but are too afraid to speak up; this gets tested too.<p>It might not be so great for newbies and people fresh out of college, but even they should be able to read the code and discuss it.
评论 #35704633 未加载
评论 #35703523 未加载
评论 #35706719 未加载
JohnMakinabout 2 years ago
Well stated. I seem like the exact type of dev as described in this blog post - I get performance anxiety and the audited interview process doesn&#x27;t fit my particular style. I wouldn&#x27;t describe myself as slow, but my steps to solving a problem are often not linear and sometimes difficult to measure in such a setting.<p>as a devops engineer as my main job, I also try to explain to interviewers that on any given day I am reading and writing half a dozen languages of vastly different paradigms, and although I&#x27;m very proficient in many of them, I definitely need to reference things that maybe shouldn&#x27;t &quot;need&quot; to be referenced (like confusing bash&#x2F;python loop syntax is very common for me as an example). This rarely ever slows me down in reality, but will definitely cause me to fail interviews I shouldn&#x27;t.<p>If I was an interviewer, I wouldn&#x27;t care if a dev knew whatever esoteric language syntax or API calls by heart. I&#x27;d just expect them to know how to use them intelligently. The former does not always imply the latter.
评论 #35706081 未加载
CobrastanJorjiabout 2 years ago
&gt; Companies may deem these acceptable concessions relative to having a consistent and un-biased process....<p>YES! Yes, exactly. A consistent and unbiased process that reliably weeds out people who is very bad at programming is incredibly useful. I&#x27;m not convinced live coding interviews are either of those things, but assuming they are, they are absolutely worth the listed downsides. Do they filter out lots of great programmers along with the bad applicants? Yes, totally, and that&#x27;s a major waste. But all of the listed alternatives are less reliable, less consistent, slower, and friendlier to cheating.<p>I would love to eliminate live coding interviews where I work. I hate the things. But I have never encountered a mostly consistent and kinda objective solution that compares. I was hopeful that the essay was leading to a proposal for one and disappointed once again at its lack. Please, someone tell me what the giant tech companies should use instead, and I will gladly throw these &quot;please reverse this linked list&quot; interviews into the trash.
sintezcsabout 2 years ago
I have a very simple rule that I’ve been following for years and it always worked for me. I ask a recruiter about the interview stages, and if I hear “live coding” I immediately decline this opportunity and switch to the next one. Eventually I was able to find really great places to work at, that made me happy for the next years.
syngrog66about 2 years ago
its extremely distracting. its like attaching an anchor to my brain. its like driving in traffic while simultaneously trying to text back and forth with someone on your phone. both suffer<p>and very unnatural<p>and insulting to an experienced person (whos been promoted, and whos survived many layoffs in the past, etc) with many accomplishments. someone who has clearly solved and shipped, repeatedly. and one who has artifacts visible out in public. and has praise testimonials from former bosses, coworkers, clients, etc
emodendroketabout 2 years ago
Amazingly, this latest take on this shopworn topic, which says nothing we haven’t all heard over and over, actually anticipates my response, “what are the alternatives?” and then fails to make much of an argument for any of them. Next.
Taylor_ODabout 2 years ago
&quot;Here are reasons why this thing is bad. I don&#x27;t have a better option.&quot;<p>This type of interview related blog post seems to hit the front page every week. Almost everyone agrees that interviewing doesn&#x27;t feel good and seems overly complicated&#x2F;difficult&#x2F;whatever.<p>I hate that interviewing is a skill that has to be developed, in large part, separately from other engineering skills. I also don&#x27;t really enjoy SQL&#x2F;Database work. But I&#x27;ve gained enough competence in SQL that I&#x27;ll be fine in most jobs. The same is true for my interviewing skills.
评论 #35702753 未加载
rockbrunoabout 2 years ago
Everyone complains about the state of SWE interviews yet nobody seems to be able to come up with a legit better alternative. Even the author recognises this in the article.<p>This format is popular because it&#x27;s the best time&#x2F;effort trade-off for both the company and the candidate. It&#x27;s massively flawed, but everything else attempted so far turned out to be even worse.
评论 #35702415 未加载
评论 #35724428 未加载
评论 #35706625 未加载
评论 #35723726 未加载
assbuttbuttassabout 2 years ago
&gt; Another unavoidable facet of live coding interviews stems from effectively requiring someone to just start typing. For plenty of people, that’s not a problem, but for people who tend to be more tactile, visual, or kinesthetic, just banging on a keyboard isn’t a natural way to begin problem solving.<p>In my experience conducting these live coding interviews, it&#x27;s almost a universal rule that if the candidate starts coding immediately, they will waste a lot of time on irrelevant details, or take a long time to see that their approach can&#x27;t work.<p>I always try to encourage the candidate to talk through their solution or draw a diagram if it helps them. Candidates who follow this advice always perform better.
fourseventyabout 2 years ago
There are problems with not doing any live coding too. I&#x27;ve interviewed people for programming jobs who can bullshit their way through a phone screen but literally can&#x27;t write a for loop or a simple fiz buzz program.
lasereyes136about 2 years ago
&gt; In my experience with live coding interviews, the companies and teams seem oblivious to the gaps created by using live coding interviews as one of the key signals.<p>To me this is the key to the whole problem. For many companies live coding interviews are a cargo cult approach to interviewing. Since the people that do them don&#x27;t understand how to evaluate others they become a checkbox exercise that only evaluates if the candidate would tackle the problem the same way the interviewer <i>thinks</i> they would tackle the problem.
beerplsabout 2 years ago
It’s as simple as this: refuse any and all interviews that require you to dance<p>I refuse to take those interviews. I had one company that promised they wouldn’t give me a live test, and when I told that to the interviewer who was trying to give me a test he said “hm, well we’re going to do it anyway”<p>I passed the test and was given an offer which I shot down for the company which respected my terms<p>In the end the other company was left high and dry when they needed the new team member<p>Just do it. Enough of us see this for what it is. If we just act how we think we change the industry
评论 #35704400 未加载
Gunaxabout 2 years ago
Tl;dr but this debate has been done, a million billion times already.<p>The author concludes with a decent summary of the issue (ie. Is this the best method among the worst?). But doesn&#x27;t actually find a better way of doing things.<p>And in the million forum threads on this issue, no one else has either.
评论 #35703039 未加载
评论 #35723791 未加载
languagehackerabout 2 years ago
If you&#x27;re grading someone during the coding interview exclusively on their code, sure. I use a <i>pairing</i> interview to make sure that the person can collaborate effectively, think out loud, and shake out ambiguity.<p>There is a nice side effect about doing this as a coding interview; there are often obvious indicators that a candidate is a poor fit -- for instance, big knowledge gaps in the standard library of the primary coding language.<p>More important is how the candidate <i>structures</i> how they would solve the problem, and how they communicate it to the person on the other side of the discussion. Are they taking testing into account? Do they iterate rapidly, or have a monolithic solution they have a hard time conveying?<p>For lack of an effective whiteboarding solution with remote interviews, coding interviews are here to stay. They should be reframed, though, as focusing on collaboration -- not on being a leetcode champion.
rolenthedeepabout 2 years ago
After having been through this crap and now being on the other side of the desk, I&#x27;ve come to the conclusion that this is simply standardized testing for adults, with all of the same myriad problems. It doesn&#x27;t identify what you&#x27;re actually looking for, gives you more false signals, and alienates the talent you actually want.<p>The way we do these at my current job is extremely productive for us. We look for two things, apart from basic competency: problem solving, and asking for help.<p>It&#x27;s structured as a two 90 minute pair programming sessions. Interviewee shares their screen, and we work through the problems together. Obviously it&#x27;s pretty hands-off, but we guide and nudge where appropriate. Here and there, when they use something that relates to a deeper topic, I&#x27;ll ask questions to gauge how deep their knowledge goes. Like asking if they know how C#&#x27;s foreach works under the hood. Not as a selection criteria, but simply to get a sense of how much they know.<p>Use of a search engine is openly encouraged. A lot of the time, we don&#x27;t even care if the program actually runs. If they struggle with syntax or the correct function overload, we&#x27;ll help them out after giving them a little time to find the solution.<p>I also throw in a problem designed to get them stuck, and ask questions I expect they can&#x27;t answer. A good programmer asks for help and admits when they don&#x27;t know. A bad one bullshits their way through.<p>We want to hire programmers who can do a real job in the real world. Implementing red&#x2F;black trees on a whiteboard blindfolded isn&#x27;t a job skill, it&#x27;s a party trick. That&#x27;s not something a programmer will <i>ever</i> need to do.<p>In the real world, real people use google and stack overflow. They don&#x27;t have encyclopedic knowledge of the entire language&#x27;s syntax. They ask their coworkers for help or opinions.<p>Our interview process is designed to show us how a person will function in a scenario as close to the job as possible. Because that&#x27;s what we&#x27;re hiring them for. We look for their ability to work through a problem with the resources that everyone always has. We look for how they work with others and how much they lean on coworkers.<p>This has worked out extremely well for us. We&#x27;ve hired some very talented individuals, and have totally avoided the archetypal shitty dev. The people we hire immediately mesh with the team, and learn and grow the way all programmers do.<p>Granted, we are a small company and we have the time to have our own programmers giving interviews. We also have a much higher need to be so selective. But every single person who has made it to the technical interview has remarked unprompted that it&#x27;s the best interview they&#x27;ve ever had. And I mean 100%.<p>It&#x27;s because we treat candidates the way we&#x27;d treat our own employees. They get to know what the job is like, and we get to know how they&#x27;ll do the job.
评论 #35723818 未加载
angarg12about 2 years ago
I feel all discussions about the coding interview are missing two critical points: first, how we got here, and second, why are we still here.<p>First, how we got here. I didn&#x27;t experience this first hand, so I&#x27;m just making a recount based on what I&#x27;ve heard and read from &quot;old timers&quot;. My understanding is that before whiteboard, leetcode-style interviews became the norm, tech interviews were mostly unstructured and quite informal. In the really old times (pre 90s) you could get a job just by knowing how to use a computer. I believe this wasn&#x27;t that unusual in the 90s and early 2000s. I still remember hearing a founder-CEO bragging that his interview process was a 30 min chat with each candidate, and if he liked them, he would hire them.<p>From what I could gather Microsoft is the first big company that started using these &quot;coding challenges&quot;. Then they became wildly popular thanks to Joel Spolsky [1], the publishing of Cracking the Coding Interview [2], and Google made brain teasers world famous.<p>Second, why we are still here. First, I believe there is a huge cargo-cult factor. Companies want to copy big tech, and alumni from these companies go on to found their own. This kind of interview has been honed and polished over the years, landing in a local optimum. An entire industry of websites and products has been created, and there are many entrenched interests. People might hate it, but the process works well enough for tech companies that they don&#x27;t need to worry too much about it. Another under-appreciated factor is scale. This kind of interview sort-of scales well, which is important when you hire at a massive scale. That&#x27;s why things like &quot;have the candidate come to work one day and pay them&quot; won&#x27;t work for companies that need to screen thousands of people a week. Lastly, a standardized and &quot;well known&quot; process introduces some guardrails that can avoid some obvious pitfalls. The book &quot;Working Backwards&quot; explain how the Bar Raiser program was created at Amazon when a bad senior leader hire used the unstructured approach to hiring to build an empire misaligned with the company. At a big enough company this is bound to happen sooner or later.<p>Third, where do we go from here? I find it extremely unlike existing big companies will change their methodology any time soon. It might not seem like it, but for a company like Google it would be a massive undertaking to overhaul their hiring process. It would take years to achieve the level of efficiency and effectiveness of the current system, and surely there would be tons of opposition.<p>I believe the only way forward is for new companies to experiment with other methods of hiring, particularly at the beginning when they are nimble and can experiment freely. As they grow they will face challenges scaling, polishing and standardizing their process. At some point they will become the next generation of Big Tech, and the cargo cult wheel might spin again.<p>In any event it seems we need some sort of structured approach to hiring where we assess the match between company and candidate.<p>[1] <a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2006&#x2F;10&#x2F;25&#x2F;the-guerrilla-guide-to-interviewing-version-30&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2006&#x2F;10&#x2F;25&#x2F;the-guerrilla-guid...</a><p>[2] <a href="https:&#x2F;&#x2F;www.crackingthecodinginterview.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.crackingthecodinginterview.com&#x2F;</a>
评论 #35723805 未加载
eyearabout 2 years ago
Google, Facebook, Amazon use it for a reason. And they are top engineering companies. Period.
评论 #35702228 未加载
评论 #35767943 未加载
评论 #35704777 未加载
评论 #35703998 未加载
Arainachabout 2 years ago
Live coding interviews are the future. The risk of false impersonation was low enough for a while to rely solely on virtual screens, but widespread access to and awareness of large language models has made any virtual exercise unsustainably corrupted.<p>Sure, you can often tell the folks who know nothing when asking them to explain the code, but it&#x27;s increasingly difficult to tell a great engineer apart from a mediocre one that&#x27;s cheating, and once you start hiring cheaters the toxic effect to culture sets in fast.
评论 #35702365 未加载