[HN Gopher] Coding interviews are stupid (ish)
___________________________________________________________________
Coding interviews are stupid (ish)
Author : darrenkopp
Score : 117 points
Date : 2024-05-05 18:03 UTC (2 days ago)
(HTM) web link (darrenkopp.com)
(TXT) w3m dump (darrenkopp.com)
| cranberryturkey wrote:
| When I interview an engineer I just ask them to walk me through
| some code they've written recently. If they don't have any side
| projects or github projects, then I would not even bother
| interviewing them.
| syndicatedjelly wrote:
| So you don't interview anyone whose work is company
| proprietary?
| cranberryturkey wrote:
| nope. tech is so fast moving if you're not at least
| experimenting with your own code then you're not going to be
| a good fit. we tend to also hire engineers who have
| contributed to open source.
| syndicatedjelly wrote:
| Good to know there are hiring managers out there who think
| like this. Thanks for the reply.
|
| May I ask what industry you work in?
| dgfitz wrote:
| I just want to know the company name so I don't
| accidently ever apply there.
| eep_social wrote:
| https://news.ycombinator.com/item?id=40211188
| parpfish wrote:
| The company that demands cutting edge experience is a
| strava for skateboarders app?
|
| I thought he was going to say that it was something like
| a foundational R&D lab or cybersecurity firm
| cmrdporcupine wrote:
| Yeah sounds like the measure of "cutting edge experience"
| here is defined as "has recently thrashed around in
| latest trendy JS framework"
| cmrdporcupine wrote:
| No kidding. I'd be happy to walk through the stuff I have
| on github but I also don't want my coworkers measured by
| whether they do the same.
|
| If anything, personal projects can end up being
| distractions from focusing singularly on work. Even
| though I'm entirely in favour of them, I also remember
| when I had a newborn at home and a family member in
| hospital, and such projects were not at all feasible.
| parpfish wrote:
| there's also the issue where the stuff i put on github is
| for hacky throwaway stuff and not representative of my
| professional standards for a "real" job. it'd be like
| interviewing a chef and judging their abilities based off
| of what they made themselves for dinner last night rather
| than what they cook in a restaurant
| jf22 wrote:
| Most code is not written with the latest technologies or
| techniques though.
|
| Why would being up to date matter?
| mrkeen wrote:
| I think you just gave the answer and then the question.
| jf22 wrote:
| I do not understand your reply.
| high_na_euv wrote:
| >tech is so fast moving if you're not at least
| experimenting with your own code then you're not going to
| be a good fit
|
| Huh? What kind of stuff ya do?
| Scarblac wrote:
| I experiment, of course. At work.
|
| And if you don't let people experiment during work, but
| only hire people that do, then that's a bad sign.
| leetrout wrote:
| I got irrationally angry about this at a previous job.
| Everyone was all excited management was having us all do
| a "hackathon" and I am loud and grumpy about how this
| should just be part of the normal course of business.
|
| We found solutions and tools that better solve problems
| but to this day have still not been implemented.
|
| Not everything needs a novel solution but not making room
| for innovation because the company is operating as a
| feature factory is boring.
| constantcrying wrote:
| >tech is so fast moving
|
| I recently meet a programmer in his 50s, still working on
| Cobol. Sure, you aren't gonna hire him, but do you think he
| has any worries about his job?
| CraigRo wrote:
| For those of us already putting in 10-14 hours per day at our
| day jobs, or who work in regulated industries, this is a
| nonstarter. My experience is that the people who are really
| good are kept pretty busy by their employer
| mlhpdx wrote:
| I avoid the issue by asking for "a page of code you want to
| have a conversation about". If needed, I clarify it can be
| code they wrote, code they use or just code they are curious
| an about. Failing to bring something, anything, is obviously
| a problem (and happens occasionally). The discussion quickly
| illuminates where the candidate is in their career.
| Paul-Craft wrote:
| I would love to be the candidate in this interview. Are you
| hiring? :-)
| Mashimo wrote:
| > 10-14 hours per day
|
| Oh heck nah.
| viraptor wrote:
| You're missing out on lots of amazing people who treat
| programming as work and have other hobbies. Or people in
| temporarily different situations (like young kids). Or people
| with more important things happening in their life. You're
| effectively filtering for mostly people in their 20s.
|
| I mean, it's your choice, but your loss too.
| mrkeen wrote:
| > You're effectively filtering for mostly people in their
| 20s.
|
| Or people who used to be in their 20s.
| Paul-Craft wrote:
| You also implicitly filter out people who were in their 20s
| when Github _et al_ didn 't exist.
| shrimp_emoji wrote:
| Citation needed
|
| All the good programmers I know have side projects and live
| and breathe code. None of the mediocre/bad ones I know do.
|
| Think of it this way: what's likely to make you a better
| programmer: spending half (0.5x) of every day on (a work-
| mandated subset of) code or spending most (1x) of every day
| on code? The answer is obviously the latter.
|
| And it sounds weird, but most of my programming knowledge
| comes from outside of work, even the knowledge that I apply
| _at_ work. Maybe it 's because work naturally discourages
| exploration since you're focused on the company's priorities.
| For example, I'm never implementing a collection in C at work
| (I use `std::vector` and stuff). Yet doing that in my own
| time taught me why certain operations invalidate iterators --
| a thing _senior_ coworkers of mine didn 't understand and
| which helped us catch a bug. :D
| constantcrying wrote:
| Sure, but a good employee is not just a good programmer.
| You don't want an obsessive, you want someone who is stable
| and has other things going on in his life.
| sevagh wrote:
| Tangentially related. I was trying to describe to a
| friend of mine how being discerning after a few years of
| experience means I do less work (or toil) for a better
| outcome, and why it's worth the higher salary I command.
|
| Young me would've enjoyed the process of building a
| thing, ignoring problems like maintenance burden, how
| fragile or brittle the new tool is, lessons learned from
| the old tool, etc. etc. (you know how it goes)
|
| Current me will take a task and mull on it. No pen to
| paper for _days_, preferring a minor adaptation to the
| existing process, or discovering that the desire was
| misguided in the first place. The work not done and
| wisdom to not do it is worth its weight in gold.
| Mashimo wrote:
| I think I only know a single programmer that does side
| projects. Work gives me time to look a new stuff and pays for
| courses.
|
| I mean I do have side projects, but those are all in a language
| I'm not specialized in and often single class small helper
| programs.
| whstl wrote:
| I'm often the only one when I work in smaller companies.
|
| And the best developer I ever worked with had zero public
| repositories in Github. Now that gave me some perspective.
| dexen wrote:
| Secondend! I like how this checks for both actual work quality,
| and for cultural fit, in one step.
| constantcrying wrote:
| Have you ever considered that people who have a single minded
| focus on software, might be solely good at software to the
| detriment of other skills?
|
| 8 hours of software development is more than enough practice
| for a developer. Having an employee with a well balanced life
| is superior to one who is unable to detach from his work.
| mrkeen wrote:
| I very rarely see anyone try _anything different_ in a 9-5
| setting. People leave university, join their first job, and
| spend 3 years learning how to develop in one way, and only one
| way.
|
| At-work choices are rarely choices, because you just do the
| next thing the same way as you did the last thing. If you step
| out of line, management will reel you back in. A 'big' change
| is switching from Spring to Micronaut (or vice versa).
|
| Some examples: I have pretty strong opinions about ORMs vs SQL.
| It would be interesting to discuss that on the job with someone
| who knows both well. But the guy you'll be talking to won't
| have tried SQL (beyond that academic thing they learnt at uni).
|
| Discussions about languages and types? "Java is good because it
| has types and JS doesn't" was the level of discourse I got at
| my first serious job.
|
| Having side projects at least indicates that they can try
| things out first-hand, own their own feedback loop, experience
| some surprises, and not just mindlessly cargo-cult "best-
| practices".
| mytailorisrich wrote:
| > _Q: Assume that you have an infinite stream of data that is
| coming in from multiple threads in an unordered fashion. Write
| the stream items to the console in order._
|
| If I were the interviewer I would be interested in what
| clarifying questions the candidate would ask and/or how they
| would highlight parameters and assumptions needed because the
| question is vague to the point of being unanswerable otherwise.
| tantalor wrote:
| As written this problem is impossible to solve.
|
| Proof: suppose there is only 1 infinite stream which is always
| descending. You will never find a lowest value, so you cannot
| rewrite the stream "in order".
| SJC_Hacker wrote:
| That could be part of the question.
|
| At one job interview I was deliberately given a problem which
| had no efficient solution. The idea was to find a heuristic
| which would get close to the optimal solution and run in a
| reasonable time.
| ClimaxGravely wrote:
| I got one of those at a FAANG interview. I was a bit less
| experienced and less confident at the time so I left the
| interview thinking I was misunderstanding some fundamental
| CS laws.
| dooglius wrote:
| The question is not clear but I assume the ordering is meant
| to be on some kind of timestamp, so the streams would each be
| increasing
| darrenkopp wrote:
| it's not impossible to solve, but there are situations like
| that which make any solution not work, which was a follow up
| question
| MrDarcy wrote:
| I came looking for how this could possibly be solved. Could
| you help me understand?
|
| If the input is infinite and unordered and the task is to
| produce output in order, how do you know when it's OK to
| start writing output?
| darrenkopp wrote:
| Sorry, I was paraphrasing the question and not giving
| every detail that I received. They also stated that there
| are no gaps, the values increment by one, and start at
| zero.
| tantalor wrote:
| How is that "in an unordered fashion"? It sounds pretty
| ordered to me!
| darrenkopp wrote:
| The data itself is ordered (which is why the task is to
| print them in order), but the order you receive the
| values is can happen in any order (ie the processing was
| split into multiple threads and each thread is posting
| back the results from the work).
| tantalor wrote:
| Ah then that's the classic "merge k sorted streams"
| question. It's a good question and easy to solve in a
| coding interview. Good candidate should be able to solve
| in about 30 minutes. My favorite solution goes something
| like "put values in a heap and then read them back out"
| because you only need to read 1 value from each stream at
| a time.
| darrenkopp wrote:
| Yep, that was my same approach as well.
| teeray wrote:
| The coding interview looks different when you view it for what it
| would be called in other industries: a licensure examination. It
| looks particularly insane to relicense for every single job you
| apply to. It also looks supremely unfair to have proctors for
| this exam with varying expectations and training to actually
| correctly administer it.
| shrimp_emoji wrote:
| Yeah, but the variation can be good. If I had to imagine what
| the hypothetical licensing process would be, I imagine it would
| be something easy that admits tons of mediocre devs. Plus,
| would it come in different language/subfield flavors to account
| for different roles? One job would ask me to implement a custom
| allocator, and I'd pass; another would ask me how to add
| Frondle to Artifactory, and I'd fail miserably.
| parpfish wrote:
| Actual engineering licenses in the US have kind of solved
| this.
|
| There's the easy exam that pretty much everyone passes eh e
| they get their degree (the FE), and then there's the hard one
| that not even everyone attempts after a couple years of
| experience (the PE).
|
| And within each level, you specify your discipline (civil,
| mechanical, etc) and then are required to have deeper
| knowledge of several subfields within that discipline.
| tracker1 wrote:
| Difficult to apply a lot of that, when in reality there are
| nearly infinite combinations of domain knowledge, software
| knowledge, architecture knowledge with languages and
| platforms. Some requiring more or less depth than others.
|
| Software is a craft discipline... it would be better
| organized as a guild with reputation at stake in concert
| with endorsements. But then you risk what is effectively
| nepotism and politics.
| parpfish wrote:
| you don't think other engineering disciplines have
| countless sub-areas of expertise?
| tracker1 wrote:
| I don't think other areas of engineering see the tooling
| options double every other year.
| pseudalopex wrote:
| The sort of interview being discussed doesn't test
| knowledge of the latest tooling.
| teeray wrote:
| > I imagine it would be something easy that admits tons of
| mediocre devs
|
| Given that Medical boards and the Bar strike fear into the
| hearts of students and demand immense preparation, I think we
| could do pretty well. The test prep mentality isn't
| altogether different from the "grinding leetcode" that
| happens today anyway. The difference is that it would at
| least be fair.
| citizen_friend wrote:
| - licensing ensures only a minimum level of quality
|
| - people with licenses still do interviews, often just as
| grueling
|
| - licensed careers with high performers (lawyers, doctors, ib,
| etc) have other forms of filtering which are much more painful,
| like years of low pay internships
|
| Studying for a few weeks to solve fun puzzles to make 400k
| sounds like a deal to me.
| cenamus wrote:
| Hearing from people that did internships in other fields for
| almost nothing, during which CS students make more than most
| workers really drove that point home for me.
| gedy wrote:
| Maybe for the devs, but "solves fun puzzles" is not a measure
| of quality either.
|
| The number of people who "aced the interview" but are
| borderline worthless for real product development is not
| trivial in my experience.
| citizen_friend wrote:
| I still haven't met the guy who is an algorithms genius who
| can't program, but I can guarantee a license isn't going to
| solve that problem.
| HarHarVeryFunny wrote:
| But being able to program is table stakes to be an
| effective developer. There better be a lot more to the
| interview if you are hoping to find rounded developers
| with proven experience at the level you are hiring for.
| citizen_friend wrote:
| For engineers at the mid to low level where leet code
| dominates the trait to select for is ability to program
| and be reasonable to work with.
| HarHarVeryFunny wrote:
| At entry level fore sure, but not everyone is going to be
| equal after 5-10 years of experience. They'll all be able
| to code of course, but some will have gained valuable
| experience and moved on in capability and some won't,
| which of course is why you interview to be selective - to
| find those who can do more than just regurgitate LeetCode
| solutions.
| arcticbull wrote:
| > They'll all be able to code of course...
|
| I promise you that's not the case, lol.
| gedy wrote:
| "Programming" is only half the battle. E.g. doesn't
| overcomplicate the codebase with weird one-off solutions,
| can actually work on features, some of which (God forbid)
| involve a UI or existing code.
|
| In 20 years, most leetcode style genius types I've worked
| with really aren't great at this type of SaaS work.
| gopher_space wrote:
| What you want is someone who can break down a problem to
| the point where they can use the scientific method to
| come up with an algorithm on their own.
|
| What you get is someone with canned responses in their
| head. And resultant mass layoffs. We're trying to
| automate picking just the right puppy instead of going
| out and playing with a few of them.
| weezin wrote:
| Programming is a very small part of the battle of being
| an effective software engineer.
|
| It leaves out:
|
| - communicating
|
| - teaching
|
| - dealing with ambiguity
|
| - navigating politics
|
| - working cross-functionally
|
| Most high level individual contributors at large tech
| companies don't even code.
| tracker1 wrote:
| As an addendum to "communicating" is documentation. That
| said, plenty of those who do document/communicate well
| can still suck at teaching/training at a higher level.
| rockemsockem wrote:
| What makes you say they don't even code? In my experience
| coding is indeed drastically reduced, but high level ICs
| still regularly code.
| whimsicalism wrote:
| i have experienced a lot of people who have convinced
| themselves they are adding value despite not coding, yes
| humansareok1 wrote:
| It's not about being able to program. It's much more
| about product sense and system design.
| fileeditview wrote:
| Only in other countries than the US there are also these
| interviews and you make far from 400k :)
| Paul-Craft wrote:
| Even in the US, "$400k" is almost certainly an outlier and
| not the typical case. Ever notice how people making these
| claims never provide data about actual comp distributions?
| I've been an engineer for almost 10 years and never had an
| offer come close to $400k per year.
| Domenic_S wrote:
| It's the typical case _for Bay Area-HQ tech companies_ ,
| at essentially all levels for Tier-1 companies, higher
| levels at Tier-2/3 companies, and specialist roles beyond
| that.
|
| "software engineering" doesn't print money any more than
| being "in finance" does, you'll make more or less
| depending on what company you do it for.
| pseudalopex wrote:
| > It's the typical case for Bay Area-HQ tech companies,
| at essentially all levels for Tier-1 companies, higher
| levels at Tier-2/3 companies
|
| What are the tiers? It's close to typical for a Bay Area
| Google L5 according to levels.fyi.
| humansareok1 wrote:
| Do you work in California for a company in this list?
| Meta Amazon Google Netflix Airbnb Stripe Square Microsoft
|
| If not it's unsurprising. But these actually are typical
| offers at those companies including Base Salary + Stock +
| Bonus.
| tracker1 wrote:
| It probably depends. I know at a very senior level in a
| lot of companies, you can hit a base salary around half
| that for Staff/Principal positions and some Architect
| roles, especially in higher paying areas. The value of
| stock offerings and other compensation, bonuses etc will
| vary a lot though. You may grind out 5-10 years to reach
| that level, then 5 years to fully vest at half that pay
| to see a $1M stock payout at 5 years bringing the average
| to $400k. Who knows. Different arrangements work
| differently.
|
| As an aside, when the market is relatively good, don't be
| afraid to straight up ask where compensation is on given
| roles when recruiters reach out, or to ask for more than
| you think you might get. You're pretty unlikely to get
| $400k or anywhere near it as a base... but you'd be
| surprised how reachable say $150k+ is as a base salary
| for a remote position when you aren't in SF or another
| major/expensive city.
| ryandrake wrote:
| Everyone on HN knows someone whose brother's uncle's
| girlfriend's nephew's former roommate works at Facebook
| and made $400K as a developer. And they'll point to that
| one person and say "See, it is possible to make $400K in
| tech." Yes, it is technically _possible_ , just like it's
| _possible_ to do plenty of difficult things. That doesn
| 't make these salaries common. For every 1 person making
| $400K-800K at FAANG in the Bay Area, how many dozens are
| working outside the Bay Area and/or for some no-name
| company making $120K?
| varjag wrote:
| I dunno man. A good third of my class seems to be working
| at FAANG and we're all from an unremarkable university in
| Eastern Europe. I'd imagine the prospects are much better
| if you start in the States already.
| whimsicalism wrote:
| in the sfba, levels.fyi shows it roughly at 85%-ile, not
| everyone - but hardly extreme outlier
| speeder wrote:
| What kind of job pay 400k? Even when I worked as C++ guru at
| BMW and was hired as very senior my before taxes compensation
| was 40k (year).
| michaelt wrote:
| Perhaps they meant to say "studying for a few weeks to
| solve fun puzzles, after getting a CS degree from Stanford,
| moving to a city where a basic apartment costs $1 million,
| and getting 8-10 years FAANG experience, also like half
| that $400k is stock not cash"
|
| But no licensing!
| citizen_friend wrote:
| None of these things are true of me actually. Skill based
| interview is an equalizer which overcomes status
| education. And fine divide the salary by 2 and it's still
| better than most "licensed" careers
| tracker1 wrote:
| Not to mention those of us who are self-taught and don't
| do as well in formal learning environments. One can be
| higher functioning, but not learn the same as others.
| It's harder to work around at times, and I do have to use
| various coping mechanisms in practice (same as setting
| lots of alarms for meetings through the day). I don't
| always do as well in converting literal leet code pre-
| screenings online though. I'd rather do a take-home type
| assignment (actually make a solution for X) or a person
| to person screening, where I can ask followup questions
| to better understand what I'm solving for in context.
| fnfjfk wrote:
| Stock in public companies is effectively equivalent to
| cash, so what's the difference? Sell on vest and buy
| index funds or anything you want.
| redserk wrote:
| That's assuming the stock price doesn't go down in the
| time it takes to hit your first (or any meaningful)
| vesting cliff.
| humansareok1 wrote:
| To be fair I think most top tier companies vest quarterly
| so...
| Paul-Craft wrote:
| They do, but they don't do refreshers quarterly.
| rockemsockem wrote:
| You definitely don't need 8-10 years or a degree from a
| particularly prestigious university to achieve this.
|
| Also you can get this pay outside the bay area, still in
| high cost of living areas, but for that pay it's really
| not an issue.
| flashgordon wrote:
| Jobs in bay area with most tech companies with 5-10 years
| of experience at mid level gives you this. With zirp gone
| this may no longer be true but was the case 2 years ago
| triceratops wrote:
| Jobs at software companies in the US. Other industries
| don't pay very much for technical talent.
|
| $40k is extremely low for a senior role. Even in places
| like India or China.
| arcticbull wrote:
| You can make double or triple that in total compensation at
| the staff or principal level in the Bay Area.
|
| I'm not saying these jobs are easy, or easy to get, but
| yes, they exist, even in this market.
|
| The reality is the biggest drop-off in recruiting is at the
| very top of the funnel. Your basic phone screen and first
| technical screen -- before you get to a full panel. Once
| there you have way more, qualified, applicants than roles.
| I'm not sure it really _matters_ which person gets the job,
| and this is one way you can make a fairly arbitrary
| decision. It 's nice because it's within your control to
| grind some leetcode lol. From the company's perspective
| it's fair and has limited negative selection risk, and
| doesn't lead to as many regrettable hires.
|
| If you've got 100 great candidates and 1 role, does it
| really matter which great candidate gets the job, so long
| as the selection process is relatively fair and uniform?
| From the company's perspective, probably not.
|
| Since there's no feasible way to select the local maxima,
| the second sort is consistency.
| Thrymr wrote:
| > You can make double or triple that in total
| compensation at the staff or principal level in the Bay
| Area.
|
| Sure, it is possible, but that is a small number of roles
| at a small number of companies, and the vetting process
| will be more intense. I think the coding interviews we're
| talking about in this thread are going to be at the
| junior to mid-level for the most part.
| damontal wrote:
| You can make millions as a famous actor in Hollywood. So
| what? That doesn't describe the average actor's
| situation.
| arcticbull wrote:
| I think it's a lot easier to get a staff role than being
| a Hollywood actor. Staff+ comprises around 7-10% of a
| company's engineering team.
|
| A quick Google leads me to believe there's usually about
| 15-20 A-list actors at any given time and 130,000 members
| of SAG-AFTRA.
|
| I think it's certainly achievable if you put in the time
| and effort (and of course if you're good at your job) --
| the question is do you want to or not. It can be
| incredibly demanding and may not be intrinsically
| rewarding to you. It seems folks generally believe
| "senior" is an achievable level -- they should, it's
| usually the first "terminal" level at which it's ok to
| remain for the rest of your career -- then you shouldn't
| view staff as intrinsically out of reach.
| fnfjfk wrote:
| Low level (L4) at big tech can clear $400k if the stock
| appreciates, otherwise L5 ("senior", but really just mid
| level) will easily be there. Higher level ICs can make 7
| figures.
| krat0sprakhar wrote:
| I think the author is talking about comp data from
| levels.fyi https://www.levels.fyi/t/software-
| engineer?countryId=254&cou...
| humansareok1 wrote:
| How are people still so misinformed about Tech salaries?
|
| Are you in the EU? Salaries are lower across the board
| there for engineers.
|
| In the US for Silicon Valley Type large Tech Companies the
| starting salary for New Graduate SWE's is 150k USD on the
| low end.
|
| For a senior engineer at FAANG it can easily get above 500k
| USD.
| speeder wrote:
| I am in Portugal yes.
| def_not_troll wrote:
| feel sorry for you, lad
| nsxwolf wrote:
| Keep in mind that 150k USD can also be a terminal salary
| at 30 years of experience in most other places in the US.
|
| Most jobs are not FAANG or FAANG adjacent.
| teeray wrote:
| > - licensing ensures only a minimum level of quality...
| people with licenses still do interviews, often just as
| grueling
|
| Agreed, I never asserted against these two points. The point
| of licensure is to make the first round, which is fairly
| routine at this point, more equitable and less susceptible to
| probabilistic effects. It also frees labor from administering
| this exam round to every candidate.
| rockemsockem wrote:
| How often do other industries relicense? How often would
| you propose relicensing for programming jobs?
|
| My concern would be skill atrophy between relicensing and
| then you'd still want to do the same sorts of interviews.
| xandrius wrote:
| Can I join your bubble?
| siva7 wrote:
| It would be nice. There are already too many devs and if we can
| lower that number by controlling the licensing our wages would
| also stay very high.
| rednerrus wrote:
| We need our own AMA.
| gwbas1c wrote:
| I personally think an industry-wide license would be an
| easier filter than requiring a degree: Schools don't often
| teach what you need to know, and sitting for an exam is a lot
| easier for the "I've been in the industry XX years without a
| degree."
|
| It would also be easier for the industry to settle on some
| filters in the exam to block people who just SPAM job
| postings. For example, open jobs for doctors are only posted
| on websites that are available to doctors. There is no way
| for the general public to SPAM job listings for doctors.
| roenxi wrote:
| The roughest outline for hiring as far as I can follow it is
| start with 100 resumes, filter it down to 10 by picking ones
| that are nicely formatted, then filter down to 1 by
| interviewing. Each level of filtering should be structured so
| that it biases towards technical competence.
|
| It isn't really a licensure examination because, as you point
| out, the industry doesn't bother to put the resources in to
| make sure anything is systemically analysed. It is a process to
| balance supply and demand of jobs.
| mucle6 wrote:
| 90% of the filter is resume formatting!!!? I'm open to hear
| your experience but that sounds like an arbitrary filter
| which limits your pool more than it selects for talent
| tracker1 wrote:
| It can depend, but yeah.. when you're filling 1-2 jobs and
| have a stack of 500 resumes, you're going to do quick
| filtering based on some pretty arbitrary decisions. Worse
| is that the recruiting companies will often do weird things
| to any formatting you have done. If even 50% of the
| applicants are technically qualified, dumping 90% at random
| is still likely to get you where you need faster.
|
| It's worth taking the time to ensure your formatting is
| consistent, with no/few spelling and grammatical issues.
|
| It will also vary by market/location. If you're looking at
| jobs local to you, it could be very different, especially
| for those jobs wanting domain experience. Different
| business sectors also congregate around adjacent
| businesses... so the choices and technology in one City
| will vary greatly to other Cities. As will the development
| process itself.
| humansareok1 wrote:
| Missed the step where they filter out anyone w/o a degree in
| CS from MIT/Stanford/Berkeley/UIUC/CMU.
| tracker1 wrote:
| As someone with no formal degree, but approaching 3 decades
| of experience, this last (recent) job search was rather
| brutal. Not enough feedback to know if/what was going on.
| Could be lack of formal education, could be my age (legal
| or not).
| xandrius wrote:
| Got any tips/suggestions on how not to be filtered out
| because of "formatting"? Got any great examples to share?
| thaumasiotes wrote:
| > It also looks supremely unfair to have proctors for this exam
| with varying expectations and training to actually correctly
| administer it.
|
| Those are your top two problems? When was the last time you saw
| an exam where the proctor was expected to hold a conversation
| with the examinees?
| manlobster wrote:
| You could view the trial-by-Leetcode that people undergo when
| they switch jobs every 4 years or so as a form of relicensing.
| One advantage that the current setup has over officially
| proctored examinations is that you get to try again repeatedly
| until you are successful.
| nine_zeros wrote:
| Simple coding interviews are fine for filtering candidates.
|
| Coding interviews with aha solutions or time bounds are just
| asking for people who memorize solutions. Forget about a problem
| solving engineering culture at these companies. Imo, the harder
| the leetcode nonsense, the worse the engineering culture.
| sshine wrote:
| At this point, I've had enough successful positions at hard jobs
| that I don't question my competency when I fail a pop quiz.
|
| I still don't know what my favourite Rust crate is. I feel I
| should have one after being asked more than a couple of times.
| ddoolin wrote:
| You've actually been asked that...? That's a trip. "Whichever
| one solves the problem at hand."
| sshine wrote:
| Three times, yes.
|
| I don't have one, though.
|
| Much like I don't have a favourite number or colour any more.
| I have favourite sets of numbers and colour palettes!
| jessekv wrote:
| I'd say regex, mostly for the well written blog posts.
|
| https://blog.burntsushi.net/regex-internals/
| relaxing wrote:
| Don't overthink it, just talk about something you like about
| the language. The interviewer wants to hear relevant words that
| demonstrate you've actually worked in the space (and not just
| did a tutorial or read a blog post.)
| fnfjfk wrote:
| Serde? Clap? It's not the objectively best crate, just one you
| like a lot and think is well designed. Both of those are "wow,
| this is way better and yet simpler than every language I've
| used before" crates for me.
| erikerikson wrote:
| Sounds like they are trying to discover good ones
| fwungy wrote:
| "Favorite" just means one you use a lot.
|
| It's like when people ask you what your favorite movie or album
| is. They're not asking you to literally move to a desert island
| with only that, it just means one you like that comes to mind
| easily enough.
| benreesman wrote:
| The modern FAANG Frankenstein interview is a mess. It was so/so
| at Google 15-20 years ago, it was so/so when initially FB but
| most everyone cargo-culted it 10-15 years ago. It's become "grind
| leetcode" which is clearly a failure mode.
|
| The trouble is it's a hard problem, and it usually gives - _some_
| signal, so it's sort of better than nothing? I guess? In cases
| where contract-to-hire make sense for both the company and
| candidate I generally regard that as ideal, but that's not every
| situation.
|
| Someone will solve this, and that person will be _very_ well-
| loved.
| HarHarVeryFunny wrote:
| Google did the "how many gas stations in the us" interviews for
| years before finally realizing that doing well on questions
| like this had no correlation to success on the job. Now, in
| reaction to that failure, everyone is doing the LeetCode thing
| instead, and presumably will eventually realize that this
| doesn't correlate either (especially irrelevant in this CoPilot
| era when ability to memorize and code up an algorithm is
| becoming about as relevant as ability to drive a stick-shift
| car).
|
| There's really no substitute for interviewing based on
| candidate's experience.
|
| Apparently the new job market trend is applicants firing off
| dozens/hundreds of AI generated applications, which are then
| screened by an AI on the other end.
| benreesman wrote:
| Haha I'm not sure I agree about how useful CoPilot is in
| practice (there are certain tasks where it shines but all of
| the LLMs print invalid code routinely).
|
| With that said you made me laugh out loud because I have a
| friend who knew two people trying to LLM some minor contract
| and it just went on forever. I definitely think two LLMs
| talking to each other with two people copy pasting and not
| realizing it is worth like, a Rick and Morty episode or
| something.
| HarHarVeryFunny wrote:
| Yeah, I've even seen people in top ML jobs glowingly
| describe the main value of CoPilot as (just) smart
| autocomplete, but copying/regurgitation of algorithms ought
| to be something that even today's LLMs should be capable
| of.
|
| Of course there's always Google search too if you are just
| looking for an algorithm, but LLMs help in the discovery
| process since you can describe what you need without
| knowing the name of it.
| Ekaros wrote:
| Using LLMs to find reasonable subset of algorithms for a
| problem sounds like a valid use case. Could even get
| naive implementation and lead to comparing them to pick
| right one.
| arcticbull wrote:
| > There's really no substitute for interviewing based on
| candidate's experience.
|
| That always happens in an interview loop too though.
| VirusNewbie wrote:
| Why do you think they haven't adjusted again? Is it possible
| it is actually (loosely) correlated to job performance?
|
| I interviewed at Google and all the questions were practical,
| challenging, and _not_ found on leetcode.
|
| I've seen all kinds of interviews in my twenty years of
| experience, and while all types can be done poorly,
| (including DS&A ones), having some live coding is one of the
| best signals you can get in a short amount of time.
|
| I've been blown away by a candidate while they're talking
| about their experience, but then asking them to code
| something small, they utterly bomb.
|
| Conversely, I've seen shy, humble candidates struggle to
| articulate their skills, and then crush harder and harder
| coding challenges.
| ryandvm wrote:
| > I've been blown away by a candidate while they're talking
| about their experience, but then asking them to code
| something small, they utterly bomb.
|
| You're making the opposite point you think you are. How do
| you know that you observed an inability to code as opposed
| to interview performance anxiety?
|
| I've been coding for 25 years, but have bombed my share of
| _very simple_ white-boarding exercises because I panic and
| my brain absolutely stops working. If it 's experience-
| based or even take home, I generally knock it out of the
| park.
|
| White-board coding works for FAANG because they have
| 100,000 applicants at any given time and it doesn't matter
| if it has an exceptionally high false negative rate. It
| does not work so well for shops that are struggling to find
| candidates.
| skohan wrote:
| > It's become "grind leetcode" which is clearly a failure mode.
|
| I have no insider knowledge, but I always wondered if those
| kinds of cultures had a hazing / blind-leading-the-blind aspect
| to them. I.e. the people who got hired were the ones who jumped
| through some arbitrary hoops, so they doubled down on those
| hoops being the right hoops to choose the best candidates.
| beezlebroxxxxxx wrote:
| You see the same effect in the cottage industry built around
| "cracking the code" and getting hired in these sort of
| companies. They produce marketing/video content that
| endlessly repeats "grind leetcode and 3 other simple tips"
| for getting hired, and then they insist that this is the
| _exact and only_ reason they got hired (rather than plain
| luck or some reference), so everyone outside looking in
| emulates and internalizes this idea as the _exact and only_
| way hiring could possibly be effective and "fair".
| Eventually those practices just become the norm and people
| are blind to alternatives.
|
| What was once considered a test of "intelligence" and skill
| in coding (whether a true assumption or not) has just become
| a test of "how much is a person willing to struggle to _earn_
| entry into our hallowed halls ". Actual potential ability in
| the role is secondary to _getting_ the role.
| madmountaingoat wrote:
| This is a great point. As companies get bigger you can find
| HR actually codifies the behavior as part of their efforts
| to reduce unconscious bias in the hiring process. So you
| end up with developers, who know this is a flawed system,
| perpetuating it because the rules require it.
| madmountaingoat wrote:
| Hazing is exactly what it is. It's a club and if you want to
| join the club you're going to have to go through the rituals.
| I hate participating in the charade but I do it with as much
| humanity and compassion as I can muster.
| corytheboyd wrote:
| Leetcode has the side-effect of filtering on "can code yes/no"
| which is a completely fair filter... I just wish it wasn't
| difficult DSA problems we used.
|
| The same screen can be done with much simpler problems. This
| light coding interview should also be more or less pass/fail.
| Do it before everything else to short circuit those who have no
| idea how to write a for loop.
|
| Save the interesting insights for real problem solving, code
| reviews, systems design... DSA under pressure is not something
| that actually happens on the job IME.
|
| Still, I'm conflicted, because a solid DSA understanding is
| incredibly helpful at times. At the very least, a solid
| understanding of the commonly used data structures, how to
| transform data structures, a good understanding of memory
| allocation with respect to code and runtime, reference vs
| copy... All things that if not understood, can cause serious
| problems.
| pseudalopex wrote:
| > Still, I'm conflicted, because a solid DSA understanding is
| incredibly helpful at times. At the very least, a solid
| understanding of the commonly used data structures, how to
| transform data structures, a good understanding of memory
| allocation with respect to code and runtime, reference vs
| copy... All things that if not understood, can cause serious
| problems.
|
| The same screen can be done with much simpler problems. Or
| direct questions.
| jkingsbery wrote:
| I work at a FAANG (and obviously, I'm not a company
| spokesperson, just sharing my own experience). Those who are
| passionate about interviewing internally all seem to agree on
| _not_ asking leetcode questions. I know leetcode questions get
| asked anyway, but there 's pretty clear internal guidance and
| training for interviewers saying not to use them.
|
| At least part of the problem is that leetcode questions are
| easy to ask, and most interviewers don't want to go through the
| hassle of coming up a question that scales well to the
| candidate's experience and knowledge.
| firstplacelast wrote:
| Do companies really want to solve it? Why hire so many MBA's
| when the nerds will wreck and devalue each others
| contributions/potential?
| secondcoming wrote:
| We scrapped coding tests at our last round of hiring, but the
| interviewees were so bad they everyone's time was wasted. We had
| to bring it back just to filter people out.
| foobarian wrote:
| We talk about something like this now and then but the thing
| is, if fizzbuzz is still managing to eliminate more than half
| the candidates I don't think it's useless.
| andrewingram wrote:
| That does loosely suggest that something of fizzbuzz-level
| triviality may be sufficient for first-round filtering.
| reaperman wrote:
| I've been having trouble finding the scientific papers behind
| this theory, but one I've latched onto is that "filtering
| against known strong signals is helpful" but also that
| "additional filtering beyond that is more harmful than random
| choice of the remaining pool".
|
| Basically, it can probably be shown that if you hire a group
| of completely random sample of resumes vs. hiring a random
| sample of people who can produce a working fizz-buzz program,
| that the candidates from the latter group will perform
| better. But if you then filter the fizz-buzz group by "can
| they solve this negative base math problem?" you'll be
| removing a disproportionate amount of candidates who would
| have turned out to be excellent for your organization, and
| your final "super-candidate" pool will actually be _weaker_
| (for your org / that position) than the average of all those
| who could solve fizz-buzz.
|
| I think the research shows that you should filter based on
| what you know for sure provides a true signal, then select
| randomly from the pool which passed your known filters. If
| anyone can help me find anything relevant about this, I'd
| appreciate it.
|
| Too many orgs treat hiring like the "secretary problem" but
| that requires the assumption that you can grade everyone
| accurately on a continuous scale. We can't yet do that with
| software engineers - theres no way to say someone is "80%
| awesome" vs. "93% awesome".
| secondcoming wrote:
| I don't agree. One part of coding tests is getting the
| right output, the other part is how they went about it -
| which is relevent even if they didn't solve the problem.
| You can tell a lot from the second part.
|
| I'm not a huge fan of coding tests, and I have a lot of
| sympathy for those who refuse to do them, but it's a case
| of "It's not you, it's everyone else"
| xandrius wrote:
| I believe it to be much better to see a candidate write
| some code quickly, have them write unit tests for it,
| discover that some cases were not handled properly and
| then they were.
|
| This is how 99% of developers work, I don't believe
| anyone who says they write their code perfectly and under
| stress every single time.
| leetrout wrote:
| I have never heard of the negative base question (I would have
| never passed that without help):
| https://math.stackexchange.com/questions/216800/how-i-conver...
|
| My worst interview questions that were silly:
|
| * number theory for django dev: how many prime numbers are there.
|
| * random brain teaser for django dev: infinite lasers pointed in
| space that turn at each other at the rotational speed of light-
| does the intersection travel faster than the speed of light
|
| And questions that were very fair that I bombed:
|
| * ms paint fill method on whiteboard. I think I checked diagonals
| when I wasnt supposed to - i cant remember but they were not
| happy with my answer.
|
| * for a given phone number and a US dialpad what are all the
| possible letter combinations for the number? In python this is
| just the built in cartesian product. But I still struggle to
| write it from scratch with a recursive function and getting the
| accumulation correct.
| htrp wrote:
| > I have never heard of the negative base question
|
| In what real world situation would you even use a new base
| system?
|
| Seti and Aliens are the only one that comes to mind, encode a
| new numerical system based on some fundamental physical
| constant like the atomic weight of hydrogen.
| henryfjordan wrote:
| I mean we use base-10 and base-2 both all the time. I'm using
| base-2 to talk to you over the internet right now!
|
| > Seti and Aliens are the only one that comes to mind, encode
| a new numerical system based on some fundamental physical
| constant like the atomic weight of hydrogen.
|
| That's base-1, aka counting
| relaxing wrote:
| The paint fill one is funny because the answer they're probably
| looking for (demonstrate you're comfortable with recursion) is
| actually the naive answer (blows up in practice.)
| Paul-Craft wrote:
| Your last example reminds me of a particularly absurd one years
| ago. I got asked to write a function that calculates all the
| subsets of a given set. The problem wasn't the question,
| though. It was that the person asking me this didn't even know
| what "yield" was in Python.
| dmoy wrote:
| > I got asked to write a function that calculates all the
| subsets of a given set.
|
| I very much dislike the interview questions which roughly
| translate to "do you know combinatorics/<insert-some-other-
| area-of-math>?". Even back when I was personally good at
| those questions (straight out of University), they were less
| interesting interview questions.
|
| I'm sure there's some jobs where it's relevant, but for the
| vast majority of software jobs... not so much. I get why it's
| done - they can be small, self-contained problems, which
| don't require a lot of external context. And they can be
| easier to come up with.
|
| > The problem wasn't the question, though. It was that the
| person asking me this didn't even know what "yield" was in
| Python.
|
| That is a problem too. As an interviewer, I'm okay with
| someone using a language or lang feature I don't know, so
| long as they can explain it. Some interviewers are much less
| flexible. Hell, sometimes I'll feign ignorance over some lang
| feature just to see what their explanation is like, because
| it's a measure of signal on how well they can teach a feature
| to a more junior dev.
| thaumasiotes wrote:
| There's a rotational speed of light? Does it mean anything for
| light to rotate?
| leetrout wrote:
| See, I can't even explain it back correctly. Kinda like this
| https://www.reddit.com/r/askscience/comments/3vnyty/if_i_swi.
| ..
| SJC_Hacker wrote:
| Thinking like an engineer, from the companies perspective, its
| just a filter.
|
| While it could be the case that candidate A who passes the coding
| interview makes a terrible employee, while candidate B who does
| not pass the interview would make a better one, it doesn't
| matter. As long as the pool of candidates who pass the coding
| interview, fares better than the pool who does not, it will be a
| useful tool until someone comes up with a better one.
|
| And the alternatives were worse. There was a time where unless
| you graduated from a top-flight school, or were top X% at one of
| the better state schools, or had some other "in" (e.g. knowing
| somebody) the cool kids at the time
| (Microsoft/Apple/Yahoo/Intel/etc.) wouldn't even talk to you
| mucle6 wrote:
| I think your analogy of pools is spot on.
|
| The goal is to view people as different "grades" like a
| commodity. They aren't measuring directly for skill, instead
| they're measuring for the odds you match a some "grade" of
| software developer.
|
| To your point, if memorizing the first 1k digits of pi
| correlated with a higher "grade", then companies would use that
| instead.
| endemic wrote:
| > There was a time where unless you graduated from a top-flight
| school, or were top X% at one of the better state schools, or
| had some other "in" (e.g. knowing somebody) the cool kids at
| the time (Microsoft/Apple/Yahoo/Intel/etc.) wouldn't even talk
| to you
|
| I don't think this has changed.
| yodon wrote:
| I'm a believer in Joel Spolsky's recruiting goal: "Smart and gets
| things done."[0]
|
| Add "not a jerk" (which I find is part of "gets things done" on
| an ongoing basis) and everything else is either vanity or
| decision paralysis on the part of the interviewer.
|
| [0]https://www.joelonsoftware.com/2007/06/05/smart-and-gets-
| thi...
| coev wrote:
| The article is from someone whose final-boss interview was
| with...joel spolsky. And it was a pretty useless-in-the-real-
| world question he was given as a coding exercise (base -2
| number conversion).
| yodon wrote:
| The base -2 question was asked by someone other than Joel,
| and definitely fits in the category of interviewer vanity
| questions.
| darrenkopp wrote:
| Yeah interview before Joel was base -2 conversion. Joel's
| interview was mostly a chat and we mostly talked about my dog
| (and other things I'm sure but I only remember talking about
| dogs).
| lazide wrote:
| To bastardize a quote - 'it's a terrible system of government,
| but it's the least terrible one we've been able to find'
|
| Seriously, what are the alternatives?
| spicyusername wrote:
| Standardized licenses, per language / domain / etc, that expire
| and / or something analogous to professional engineering
| licensure in harder engineering disciplines.
|
| Take the leetcode tests once every 5 years or so. Mentor for a
| few years with an experienced, and already licensed, engineer
| and get their approval. Then the interviews can skip the
| drudgery and can be higher level and higher quality.
| BerislavLopac wrote:
| Standardised on what exactly? There are so many methodologies
| and/or tools, with endless possible combinations, each of
| which can reach the desired result in terms of functionality
| and even quality. And enforcing just one means no possibility
| of progress.
|
| In physical engineering, things are very much limited by
| physical laws, which don't change (and even if our
| understanding on them might, that happens rarely enough to
| adapt). In software engineering, the foundational principles
| can and do change many times in an average engineer's career.
| mrkeen wrote:
| > the foundational principles can and do change many times
| in an average engineer's career.
|
| I'd like to hear more.
| lazide wrote:
| Not the poster, but I personally know folks who have gone
|
| Assembly (for 6800 series Macs) -> C (PC on windows) ->
| Java (hosted on prem) -> Cloud hosted Java + JS/React.
|
| Depending on your definition of 'foundational principles'
| either nothing has changed, or everything has. But one
| thing is clear, the day to day is completely different.
| BerislavLopac wrote:
| I'm talking about things like 8/16/32/64-bit processors,
| CISC vs RISC, from mainframes to personal computers, from
| isolated machines to ubiquity of modern Internet, quantum
| computing etc. Note that I'm talking about the
| fundamentals of software _engineering_ , not software
| _science_.
| pseudalopex wrote:
| DSA puzzles do not test software engineering. And they
| did not suggest eliminating interviews.
| mrkeen wrote:
| > Standardized licenses
|
| The licence you value wouldn't be the licence I value.
| sevagh wrote:
| This is what Triplebyte pretended to be. Then companies who
| got your resume from Triplebyte just whiteboarded you again
| anyway.
| gedy wrote:
| - Don't let the hr 20-something non-engineers be your first
| filter - the hiring eng manager reviews resumes. Let HR review
| the work history, references, and W2 stuff later.
|
| - Simple, practical coding questions related to your company
| need (so not algos/leetcode for 90% SaaS CRUD app companies)
|
| - Engineer or manager talk to candidate about past work and
| projects.
|
| If you are giant FAANG okay fine that won't scale. But most
| companies smaller than this will do just fine without the
| assumption of "everyone's a faker! Gotta prove you wanna work
| here!". This has worked fine for me in hiring past 20 years.
| fileeditview wrote:
| I've talked with applicants about their private projects. It
| gave me great insights. Also take home tasks with a discussion
| afterwards are a good thing and can be an alternative if
| candidates don't have private projects to talk about.
| Paul-Craft wrote:
| Oh... take home tasks.
|
| Theoretically, I agree these are a great way of generating
| some signal where there's not enough to be found by other
| methods. But, in practice, what I've found is that most of
| these types of exercises are _way_ overscoped, and even those
| which are not put a hugely disproportionate time burden on
| the candidate with minimal return for most of them. In other
| words, nobody wants to take the time to properly review these
| things.
|
| I've had much better experiences when people give me code and
| ask me to review it rather than when they give me a "spec"
| and ask me to write code based on it. One big red flag for
| the latter type of assignment is the phrase "production
| ready," as that can mean so many different things it's a
| borderline meaningless criterion.
|
| I could really go on and on about this, but I'm going to stop
| here.
| sevagh wrote:
| Passing one significant whiteboard interview once is all you
| need, that's your "licensure."
|
| Flip a coin whether I'll ace or fail a random leetcode question
| but after the one and only time my little monkey dance
| successfully got me into a "desireable" company, I started
| confidently rejecting other proposals to whiteboard me.
| ok123456 wrote:
| I've found that asking them to review some obviously bad code
| with glaring errors and problems is more informative than asking
| them to solve some random DSA problem.
|
| Candidates who can code well can point out code that has obvious
| problems. Just ask if this is good or bad, and if it is bad, how
| they could improve it. This demonstrates competency and doesn't
| make the interview seem like a grind but instead more like a
| conversation.
| rednerrus wrote:
| I'm in ops and we've found that simple exercises are better at
| weeding people out than complex ones.
| arp242 wrote:
| This reminds me of this discussion on cocktails and bartender
| skills from a while ago
| https://news.ycombinator.com/item?id=36492450
|
| _" The martini may be simple, but it is not easy to make an
| excellent one. It's a very solid test of a bartender's skill
| because, unlike many drinks, ingredients alone cannot carry
| the cocktail. A pina colada for example, is mostly about
| ingredients (are you using a good coconut cream? fresh
| pineapple?) For the martini the chilling and dilution need to
| be just right. This tests the bartender's most important
| skill: mixing. Proper mixing of the beverage is ultimately
| what makes a martini."_
|
| [..]
|
| _" martinis are shockingly easy to fuck up. and this
| conversation is exactly the reason why the martini is a good
| test of a bartender's capability. being a bartender is more
| than putting fixed quantities of ingredients in a glass. how
| do you know when your martini is properly diluted, either by
| shaking or stirring? a good bartender will know. a bad
| bartender will not. a terrible bartender won't even realize
| dilution is crucial."_
|
| I don't really drink much and never had a martini in my life,
| but I thought it was pretty interesting.
| tracker1 wrote:
| True enough... Even in software, I was pretty amazed at how
| much of a filter of, here's a CSV, use one of N languages to
| load the data, do a check and output the valid entries to one
| file and the invalid inputs to an error file. You can use any
| libraries you like, please create a github repo and share
| with $ACCOUNT for your solution.
|
| I know not everyone works with CSV necessarily, but there are
| dozens of libraries for a lot of languages. Even if focused
| on N being those supported in a given company/org. It should
| be less than an hour of work. Bonus points for any
| tests/automation, etc.
| Paul-Craft wrote:
| I agree.
|
| Last time I got hit with an interview question like that, my
| answer ultimately had to be "block the merge and counsel the
| person who wrote this about performance." I'm still not sure if
| that's the answer they were looking for (this was for a staff
| engineer position), but I'd stand by it 100% of the time.
| brian_spiering wrote:
| I use the "launch ramp" technique. Ask a series of prompts
| (instead of a single prompt with a long answer). Explain the
| prompts that will get progressively more complex, aka the ramp
| will gradually get steeper and get very steep later. I can stop
| the interview quickly if the candidate can not find simple
| mistakes and how to remedy them. I can also jump ahead to
| complex issues to engage highly qualified candidates.
| inerte wrote:
| Just got be careful with the "how to improve" part. In my
| experience as an interviewee sometimes it becomes a regular
| algorithmic interview. A couple times I found some N+1 queries
| or inner loops and was asked to "fix it", which might just turn
| into leetcode.
|
| The best code review interviews are the ones where there is a
| healthy amount of actual code, with a handful of functions and
| classes, some badly named variables, bad comments, some
| misleading code paths, couple bad patterns, etc... the worst
| ones are a non-optimal solution and you're asked to make it
| optimal. That's just leetcode disguised as "code review".
| ok123456 wrote:
| Leave it open-ended and include code with multiple levels of
| bad so it's not just a quiz. I used real C code that research
| scientists had given me. If they look at it and say there's
| no reason this should be in C and in a dynlang instead, that
| is fine. If I hand them C code where the entire program is a
| 1000-line main function, with lots of repetition, hard coded
| file names, and fixed-sized string buffers, and all they tell
| me is the indentation is icky: that's a negative signal.
| lapcat wrote:
| > I've found that asking them to review some obviously bad code
| with glaring errors and problems is more informative than
| asking them to solve some random DSA problem.
|
| I once had a coding interview like this, but the problem was
| that the code was so obviously bad, I couldn't even make sense
| of what the code was _supposed_ to do if it were good. It felt
| like the interviewer had just come up with an example of bad
| code without any context of how the code would make sense if
| made "good". It was just totally artifical.
|
| If someone had presented the bad code in some Stack Overflow
| question, I would have started by stepping back to ask, "What
| are your trying to do?" Except in this case, the interviewer
| wasn't actually trying to do anything except quiz me.
|
| Identifying a bug in production code would be better, I think.
| darrenkopp wrote:
| This is pretty interesting, I hadn't heard of this approach
| before. I'll have to give it a try some time.
| naw1 wrote:
| My approach has been giving candidates simple real world
| problems, e.g. extract the URLs from this file given a spec and a
| description of a few language builtins. I'll throw a few
| curveballs in depending on how they do but my goal isn't to stump
| them.
|
| I'm mostly looking to filter out the candidates that flat out
| can't code or describe their thought process while coding. You'd
| be surprised how many candidates I've interviewed pass the resume
| check, get to the interview and can't reason out a problem that
| could be solved with two for loops and an if statement.
| onetimeuse92304 wrote:
| Honestly, as somebody who is hiring senior devs I can't imagine
| not doing a coding interview.
|
| Unfortunately, it is very hard to judge somebody's coding ability
| in discussion alone. You can sort of get the idea whether they
| have or don't have experience and whether they have luck being
| asked about topics they know (although you can help your luck
| just knowing a lot of stuff).
|
| I have seen a lot of candidates who were quite smooth talkers but
| could not code their way out of a paper bag. Mind I do not mean
| remembering some complex algorithm. The task is usually some
| relatively simple data manipulation so that I can see the person
| approaching the problem, asking questions, getting involved in
| some discussion, etc.
|
| The task is usually ambiguous a bit and this is explicitly stated
| so that the candidate is actually expected to get stuck, don't
| know things and have to talk to me to get the problem solved. You
| would be surprised how many candidates do not listen or can't
| follow simple advice even when I am almost giving them the
| solution on a platter.
|
| The trouble is there is a lot of interviewers and many
| interviewers do not have a basic plan of what they want to
| achieve with the coding interview. What they want to learn about
| the candidates. Those interviews tend to suck.
|
| What also sucks is candidates who come to the interview
| completely unprepared, unable to answer most of the questions or
| get any progress on the programming tasks and then spew
| misinformation on the Internet about how supposedly _all_ coding
| interviews are stupid.
|
| I guess if you can code you may have some misses, usually along
| with some hits. Sometimes you are out of luck. The point is not
| that you need to get every job that you apply to, it is enough to
| get one of them.
|
| But if you can't code at all or you apply to positions that are
| clearly out of your league, you get rejected on all these
| interviews. And then what you do? Some people go to write on the
| Internet how _all_ interviews are stupid without ever considering
| how they contributed to all those failed interviews, how real
| life works (ie. 90% of everything is crap including 90% of
| interviews) and how the situation might look from the other side.
| arp242 wrote:
| I can't really code myself out of a paper bag either with a
| stranger watching and questioning me while I'm doing it. I just
| get so nervous and can barely think straight (in general I get
| rather nervous being watched). One time they asked me to do a
| function I literally exactly have on my public GitHub as part
| of a project (remove duplicate entries from an array without
| sorting; it's just a few lines and pretty straight-forward) and
| I couldn't really do it in the interview setting.
|
| Of course I wasn't present in your interviews and I'm not
| saying _some_ of those people really couldn 't code at all.
| I've worked (well, "worked") with some of them so I know they
| exist. But I'm not so sure all of those who flunked couldn't
| code at all. In my experience I'm not a hugely unique
| individual.
|
| If you don't want to accommodate that then fair enough; it's
| your interview process. But just saying your perspective is
| perhaps not entirely correct.
| 331c8c71 wrote:
| Not realizing that the interviewee might be underperforming
| due to stress is quite telling about the interviewer's
| emotional maturity.
| okwhateverdude wrote:
| >Unfortunately, it is very hard to judge somebody's coding
| ability in discussion alone. You can sort of get the idea
| whether they have or don't have experience and whether they
| have luck being asked about topics they know (although you can
| help your luck just knowing a lot of stuff).
|
| I disagree with your stated difficulty in judging coding
| ability by discussion alone. A skilled interviewer is easily
| able to ascertain breadth and depth of the candidate's
| experience provided the interviewer is also an expert and
| curious. And part of being a skilled interviewer is using all
| of the information at hand in their CV.
|
| >The task is usually ambiguous a bit and this is explicitly
| stated so that the candidate is actually expected to get stuck,
| don't know things and have to talk to me to get the problem
| solved. You would be surprised how many candidates do not
| listen or can't follow simple advice even when I am almost
| giving them the solution on a platter.
|
| Would instantly pass on working with you based on this alone.
| The intentional ambiguity is deceitful. The expected dependence
| and expected deference is so patronizing and manipulative. I
| don't need to have an ego measuring contest in an interview.
| You win, you're the smart, awesome guy. Go enjoy all that
| success, bro.
|
| I've had too many interviews like this where the dudes on the
| other side of the table have internalized their superiority at
| proctoring their simple tasks. These dudes think they are the
| great gatekeepers of... something. Like, the candidate just
| wants to cut code so they can pay rent and eat. They don't
| really care, nor should they, about your product, or your
| customers. It's an exchange of labor for a pittance of the
| value produced. And the dudes on the other side of the table
| are gate keeping it.
| xandrius wrote:
| Yeah, OP sounds dreadful to interview with. Especially the:
| omg, I basically gave them the solution!!
|
| When they themselves didn't have to solve it, since they came
| up with it.
| SuperCuber wrote:
| > A skilled interviewer is easily able to ascertain breadth
| and depth of the candidate's experience [without a coding
| test]
|
| And yet, many interviewers' experience shows that there are
| people that would pass a discussion-only interview and fail
| at basic coding tasks. There's plenty such people holding
| down jobs for a while, so even that may not be a sure
| indicator of skill.
|
| > The intentional ambiguity is deceitful. The expected
| dependence and expected deference is so patronizing and
| manipulative.
|
| I'm ~1.5years into my first job as a Backend Dev so I can't
| speak much about the industry, but based on my experience and
| what I hear from others, asking questions and clarifying
| unclear requirements is part of the job description. I almost
| never get my tasks in a precisely defined way and a lot of my
| job is gathering information and asking the right questions
| to build the right thing, often making my own choices and
| judgement calls. I assume that these skills are what GP
| comment is trying to test.
|
| > They don't really care, nor should they, about your
| product, or your customers.
|
| You can hardly blame a company for preferring someone who
| does. Or at least, pretends to.
| jerf wrote:
| I find a simple realignment would solve a lot of this interview
| angst: Interviewers seem to interview on the premise that they
| need to find out what the candidate can't do. But this is not
| useful. I can tell you what they can't do. To a first
| approximation, the answer is "everything". I am an experienced
| and skillful developer, yadda yadda yadda, and I've never touched
| React, have no game development experience, have never written
| kernel code, haven't touched matrices since school, have only
| dabbled in embedded development as a hobbiest, etc. etc. etc.
| Make a list of all the things I can't do and I look like an
| idiot. The list of possible things is too long.
|
| The goal of an interview is to find out what the candidate _can_
| do.
|
| If you interview someone, and they "fail all the questions we
| asked", it is not the candidate who has failed... the
| _interviewer_ has failed. You ran an entire interview and all you
| know is what the candidate can 't do. You have learned virtually
| nothing. The questions must be adjusted to what the candidate can
| do. Only for the absolute worst candidates should you ever exit
| an interview saying they failed at everything. (Sadly, such
| candidates do exist. For instance, consider the recent stories
| about AI fraud. If your level of programming skill is "I have
| ChatGPT", I'm going to have a hard time scoping a question down
| to you.)
|
| If I had asked this question in an interview, or a related one, I
| would have stepped the problem down until the candidate could
| pick it up. (Odds are I'd have started lower and worked my way up
| anyhow.) If the candidate then sort of finds their footing and
| once going can start folding in the other requirements as we go,
| great. Who sits down and designs a system for all twelve
| adjectives ("reliable", "concurrent", "redundant", "runs on a
| Z80") we want anyhow? One can not help but design a system one
| adjective at a time, with the others only kept in mind to make
| sure we don't back into a corner. There's no reason not to
| interview that way too. (And I tell the candidate this is what
| we're going to do, so hopefully they don't feel like I'm out to
| get them or experience requirements whiplash without knowing why
| I'm doing this.)
| cmrdporcupine wrote:
| Yes this, and to further this, the "can't do" thing that you
| measured is in fact extremely partial and incomplete: you've
| measured that the developer can't write an algorithm on a
| whiteboard with a felt tip marker in front of a stranger they
| just met. You don't even know if they can't write the
| algorithm. Just that they can't do it _there._
|
| Is that important to you? Maybe it is for some people. As a
| person who has been in team lead and hiring capacity before, it
| is not for _me_.
|
| I trained for interviewing at Google twice, but never really
| chose to give interviews despite that being a highly pressured
| part of the job because I could not philosophically vibe with
| that process. But what some people who have adopted this
| process are missing is that Google etc does this only because
| they are swamped with resumes and have their pick of bazillions
| of quality engineers. They don't _care_ about false negatives,
| more false positives.
|
| Startups and smaller companies _should_ care about false
| negatives. It 's hard to find and retain good people. Smaller
| companies need to aggressively find and cultivate good people
| to make good teams in order to be/stay competitive -- and that
| means accepting a diversity of ways of working.
| OnionBlender wrote:
| I'm glad whiteboard interviews are dead now that everyone
| does "virtual" on-site interviews. When I interviewed at
| Google, I requested a laptop because writing on a whiteboard
| all day hurts my hand. Every interviewer complained about me
| using a laptop.
| Paul-Craft wrote:
| What, exactly, was the substance of their complaint(s), if
| any? Was it just that you made them do their job in a way
| different from how they are used to?
| cmrdporcupine wrote:
| The "point" of the whiteboard interview is to see how you
| think and converse and interact around your coding
| process, not (necessarily) how accurate/good you are at
| writing the code. You could write pseudocode that can't
| compile, and as long as you can explain the algorithm and
| talk about its complexity you could "pass" (in theory)
|
| Screening interviews do take place in a shared doc or
| other editor, I believe.
| Paul-Craft wrote:
| I'm sorry, I don't see how that relates to what I was
| asking. To be clear, I _agree,_ I just don 't understand
| why you chose to write this in reply to what I wrote.
| cmrdporcupine wrote:
| The complaint of the interviewers would (likely) be that
| they want to see the candidate go through the whiteboard
| process, because of the reasons I gave. It's just part of
| the process. Writing in an editor takes away their
| ability to probe that process.
|
| Don't get me wrong I think it's silly, but
| Paul-Craft wrote:
| Oh, I see. There's no literal reason why that discussion
| can't take place over a laptop screen, either. So, I
| suppose it more or less _does_ boil down to "you are
| making us do our job differently from how we are used to,
| and we don't like it." That _is_ supremely silly.
| OnionBlender wrote:
| I've never had any company let me write pseudocode. I
| once tried to write "vec" instead of "std::vector" and
| the interview told me to write valid code on the
| whiteboard. (And I did explain that I was to avoid
| writing "std::vector" repeatedly).
| mrcode007 wrote:
| template<typename T> using vec = std::vector<T>;
|
| Or even using V = std::vector<T>;
|
| for a concrete type T
|
| Solves the problem. If someone denies you this, you don't
| want to work there :)
| OnionBlender wrote:
| This was years ago (pre-covid) but what I remember was a
| mix of: - "Oh, you're using a laptop"
| - "Do you really need to use that?" - "Just write
| it on the whiteboard" - "It would be easier to see
| on the whiteboard"
|
| They also didn't give me a mouse, so using the trackpad
| was slow.
|
| What I hate most about whiteboards is how you can't
| easily insert lines so you have to leave lots of space. I
| tend to write code like an onion rather than top down.
| cmrdporcupine wrote:
| Here's my take on it: the interview is testing your
| ability to "show" that you absorbed the content and
| process of your 4th year data-structures and algorithms
| classes. The whiteboard process is all about showing them
| that you can regurgitate what those courses taught you,
| likely in the manner that the prof taught you. You're
| essentially playing "professor" for them in front of a
| "class", for a short period of time. _Not_ showing them
| that you can write _code_. The code you write on the
| whiteboard will look nothing like anything you 'll ever
| write at Google.
|
| I think one way to do well in that interview, is to
| pretend you're the professor and they're a student, and
| you're working through course material.
|
| In the end, it's just showing them that you passed the
| socio-cultural hurdles _they_ think are necessary, even
| if they no longer explicitly check GPAs and which school
| you came from at interview time.
|
| Why?
|
| Google is more often than not the first job these
| employees have after school, and many stay there almost
| forever after. A large percentage are masters or PhDs.
|
| Google is founded by two Stanford grads, both children of
| academics, who never worked in the industry outside of
| Google.
|
| Academia is hence the reference point against which
| Google measures things.
|
| Google is structured in many ways just like a university.
| Publish or perish (Design docs, PRDs). Thesis committees
| (perf "calibration" committee, interview committees, etc)
| and review (intense code review). Even down to the
| _physical_ "campus" structure. On site cafeterias, even
| housing/dorms (GSuites, etc)
|
| It's something that was very foreign to me having worked
| in the industry for a decade before, without a degree.
| Paul-Craft wrote:
| > I think one way to do well in that interview, is to
| pretend you're the professor and they're a student, and
| you're working through course material.
|
| If that's what they want, they should give out the
| questions in advance, and have the candidate prepare a
| slide deck. No professor conducts class by having
| students show up and fire random questions at them all
| semester.
|
| More explicitly, if that's what they want, _they should
| say that._
| hansvm wrote:
| > no professor ...
|
| That's one of the higher leverage activities for an
| instructor. Anyone can go read a book, watch a video, or
| do some practice problems, and lecturing at a bunch of
| students isn't a great way to convey information, either
| in absolute terms or compared to those alternatives. The
| instructor's job is to tell you which books to read, why
| the material matters, and contextualize the course
| against other things you care about. The particular road
| they tell you to travel depends on where you currently
| are, and a 2-way conversation is critical to getting good
| results.
| Paul-Craft wrote:
| I know all that. But, have you perhaps been in an
| undergrad classroom recently? It's still predominantly
| lecture-based.
| cableshaft wrote:
| When I interviewed at Google I was making iOS apps using
| Objective-C at my current job, so I decided to stick with
| that for the whiteboard so I wouldn't blank out on some
| syntax at an inopportune time.
|
| Big mistake. The method names get so long I was kept
| running out of space on the whiteboard and it took
| forever to write it.
|
| I don't remember exactly what I wrote anymore (it was
| over a decade ago), but this site[1] has some examples of
| really long property and method names in Cocoa (its
| framework), like:
|
| splitViewControllerPreferredInterfaceOrientationForPresen
| tation
|
| or
|
| initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSam
| ple:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitm
| apFormat:bytesPerRow:bitsPerPixel:
|
| Anyway, for that and other reasons I didn't get the job
| (I apparently didn't prepare quite the right things,
| despite preparing for a few hours every night for the two
| weeks prior, which is how long the recruiter gave me
| before flying me to Mountain View, so my performance for
| at least two of the six interviews I had that day were a
| bit weak).
|
| [1]: https://github.com/Quotation/LongestCocoa
| jjmarr wrote:
| In addition to what others have said, that's an
| accessibility concern. There are many people who have a
| _physical_ inability to handwrite.
|
| https://en.wikipedia.org/wiki/Dysgraphia
|
| In some ways I'm grateful for Covid's impact on the job
| market because I now have many alternatives to physically
| drawing on a whiteboard. I can use TikZ as fast as my
| professors can draw, and I can put that on a monitor in a
| conference room. I've even used it on exams before.
|
| I would probably struggle for reasons unrelated to my
| actual competence as a programmer if I was forced to use
| a physical whiteboard during an interview. Your comment
| made me appreciate that I'm graduating into a different
| world than 4 years ago.
| AnimalMuppet wrote:
| > Who sits down and designs a system for all twelve adjectives
| ("reliable", "concurrent", "redundant", "runs on a Z80") we
| want anyhow?
|
| Wait, is Z80 seriously something that you want/design for?
| Paul-Craft wrote:
| Sounds more like a case of "arson, murder, and jaywalking,"
| applied for its rhetorical effect, to me. :-)
|
| https://tvtropes.org/pmwiki/pmwiki.php/Main/ArsonMurderAndJa.
| ..
| surfingdino wrote:
| I have 30+ years of experience on my CV and I still am being
| asked to do coding interviews... I flatly refuse every time,
| because they have no connection to the actual job. The hiring
| process disregards experience and treats everyone in the same
| way. Ours is a stupid industry.
| gnutrino wrote:
| Have you ever been hired by a company you refused to do the
| coding interview for?
| surfingdino wrote:
| Yes, more than once.
| xandrius wrote:
| What phrasing would you use to refuse? I'm curious :D
| surfingdino wrote:
| "I just don't do online coding exercises. They typically bear
| no relevance to the project and if you expect me to be
| solving basic problem in CS while being watched and judged in
| real time when I join then I don't think I want to join.
| Also, if you cannot judge my experience based on my CV then I
| don't think you know who you are looking for."
| thesurlydev wrote:
| I agree with the sentiment that the algorithms and data structure
| coding interview practices are a terrible measure of a software
| engineer candidate. There's so many other factors that make a
| good software engineer and to dismiss a candidate because they
| can't solve a single problem on the fly is wrong.
|
| In my experience, I've never got an offer after bombing the
| coding portion of an interview even though I shined in system
| design and behavioral interview rounds.
| andrewp123 wrote:
| If you want a more efficient way to practice, I've been working
| on https://deriveit.org/coding/roadmap#note-215. It's LeetCode
| site that's
|
| -organized intelligently
|
| -has simpler explanations than you find online
|
| We're super proud of our content and just recently 2 people have
| landed Amazon with us. People actually feel ready for interviews
| with us. Give it a go :).
| mstudio wrote:
| This looks really great. I love the presentation style. Clean
| and simple. Nice work!
| xandrius wrote:
| No thanks, we don't need more leetcode-related stuff. It should
| just disappear.
| max_ wrote:
| What exactly is an alternative way to hire good candidates that
| any of you think is better than coding interviews?
| humansareok1 wrote:
| The ways every other field on earth interviews people? Do
| Surgeons need to perform mock surgeries before they are hired?
| Do Accountants need to complete a test audit? Do Lawyers
| perform a mock trial?
| munificent wrote:
| _> Do Surgeons need to perform mock surgeries before they are
| hired?_
|
| They _must_ have a degree from an accredited institution
| before they can begin practicing, and part of earning the
| degree is operating on cadavers, so, yes.
|
| _> Do Accountants need to complete a test audit?_
|
| In order to be a Certified Public Account in the US, you must
| pass the Uniform Certified Public Accountant Examination,
| which has a section on auditing and has "task-based
| simulations", which are:
|
| "CPA Task-Based Simulations are scenario-based questions on
| the CPA Exam. They are a large part of what makes the CPA
| Exam so difficult. Each one will introduce a situation,
| provide data in the form of charts, memos, and emails, and
| require you to answer a series of questions."
|
| So, I think yes?
|
| _> Do Lawyers perform a mock trial?_
|
| In order to be a lawyer in the US, you generally need to pass
| a state's bar examination. Most of those include "performance
| tests" which require the testee to simulate part of the job
| of being a lawyer. I don't know think mock trials are part of
| that, but writing a legal brief or doing other typical lawyer
| work is.
|
| My understanding is that going to trial is a small fraction
| of what most lawyers do and lawyers going in that direction
| will gain that experience as junior members of a law firm.
| humansareok1 wrote:
| >They must have a degree from an accredited institution
| before they can begin practicing, and part of earning the
| degree is operating on cadavers, so, yes.
|
| You know what I meant. You have merely created a series of
| strawmen. They don't need to perform a trial surgery every
| time they interview for a new job. The same goes for all my
| examples so nice try.
| munificent wrote:
| In every profession that is relatively high stakes, there
| is a pretty concrete chain of validation that the person
| can do the thing they claim to be able to do and that
| chain of validation does indeed rest on demonstrated
| performance at that capability.
|
| Yes, a surgeon doesn't need to perform traial surgeries
| every time they change jobs. But, also, they only work
| inside certified, heavily-regulated institutations that
| are able to vouch for their previous performance.
|
| No such institutions exist for software engineering.
| ryandrake wrote:
| Yea, OP's questions show that what we really need is an
| equivalent to the bar exam for software developers, if we
| want to move beyond these fizzbuzz interviews. Something
| that would at least assure a base level of programming
| skill. You'd still have to test for specific domain
| knowledge, but a comprehensive "programming bar" test could
| at least show someone met the minimum.
| ryandvm wrote:
| You ask them about their experience. What projects they've
| worked on. What things they've created. Then you drill down
| into the details with them. What was hard? What was surprising?
| How did they solve it? How would they do it differently?
|
| Or you do a mock design exercise with them and hear them talk
| through their process. Are they going to use a relational DB or
| NoSQL? Do they need a queue or an event stream? What language
| do they want to use? Why?
|
| Or worst case scenario you give them a take home exercise
| (compensate them!) and then for the follow up you talk with
| them about their code and the compromises they had to make.
|
| Or hell, if they like white-boarding and want to do it, then go
| for it. But a lot of people (like me) have a tendency to lock
| up in those situations.
| dilyevsky wrote:
| Classic mistake of overthinking it and failing to realize what
| interviewer really wants - which is to make sure the candidate
| can actually write code, like at all. The question itself doesn't
| really matter as much as it's just a pretext. I actually asked a
| variation of this question for many years at Google and it was
| clear within first 5 mins who has been writing code day-to-day
| and who's been mostly "brining key stakeholders into
| conversations at appropriate time".
| munificent wrote:
| I love the typo at the end. I have definitely worked with some
| stakeholders that I would have loved to stuff in a jar of
| pickling spices and leave on a shelf for several years to
| ferment.
| dilyevsky wrote:
| Im dislexik
| Nevermark wrote:
| Ha! I thought it was Shakespearean!
|
| When you feed people confabulated information, it acts as
| an encompassing medium, a reality buffer, effectively
| making them more inert, less engaged, in actual reality.
| Brined.
| spankalee wrote:
| Exactly this. In the interviews I give I care about whether the
| candidate can write code, yes, but also _talk_ and _think_
| about code.
|
| The conversation is the most important part of the interview,
| and the thinking (and communication) is the most important
| thing I'm trying to judge after basic skills.
|
| Like you said, you can get a good sense within the first few
| lines of pseudocode if someone's at least competent at writing
| code. But that's just one motivation behind coding questions.
|
| It's also very difficult to talk about code, algorithms, and
| solving problems without a concrete problem and concrete code
| in front of the candidate and interviewer. So both the question
| and the code the candidate writes are mainly context for the
| conversation where I try to see how the candidate thinks.
|
| These kind of articles make me sad because I (and many other
| interviewers I've worked with) try to make it clear that this
| isn't a test - we don't care so much about being "right" or
| "wrong", and there shouldn't be any tricks of "a ha" moments.
|
| We explain the goals and what we're looking for right up front.
| And I would hope most interviewers do the same, but I guess
| not. So there's this persistent myth among both interviewers
| and candidates that coding questions are about getting a right
| answer.
|
| That's a shame because coding questions get such a bad rap, but
| I'm not really aware of a better options. Take-home problems
| and looking at GitHub are unfair to many people. A well-run
| technical interview should give lots of people a chance to
| succeed.
| spyspy wrote:
| Coding tests are an awful place to test someone's
| conversational skills. I don't talk while I code. You don't
| either. Honestly I can't even remember the last time I talked
| to anyone about the code itself outside of a PR. People talk
| about architecture and database migrations and why their
| containers aren't behaving locally. Nobody ever tests for
| that stuff.
| the_sleaze_ wrote:
| If you're anything like me then you think a lot while you
| code, like inner monologue thinking, and that's what the
| interviewer is testing for.
| 331c8c71 wrote:
| And vocalizing this inner dialogue comes naturally to you
| I suppose.
| chessnerd42 wrote:
| If you can't explain your thoughts out loud then you're
| going to have a difficult time working anywhere.
| simoncion wrote:
| For me, it's not at all "I'm incapable of explaining this
| to you given a few minutes to collect my thoughts." and
| very much "You either get Coding Mode, or you get
| Conversation Mode, but not only do you never get both at
| the same time, I need time to context switch from one to
| the other.".
|
| The second paragraph in this comment is very, very, very
| close to how my brain operates:
| <https://news.ycombinator.com/item?id=40290732>.
|
| And I've been programming professionally for _quite_ a
| long while now, so this quirk of mine doesn 't seem to
| have made it difficult for me to work at programming
| shops.
| DHPersonal wrote:
| As I've gotten older I've discovered that I really can't
| judge normalcy based on what I find natural to me. Every
| brain is different and abilities range. Some people
| visualize things in their head; some people have to talk
| out their thoughts; some people are more optimistic. If
| we are only grading on one very particular brain type
| then we are missing out on the opportunities for diverse
| thought patterns producing something even better than
| expected.
| IggleSniggle wrote:
| This provided me with a fascinating, albeit somewhat
| familiar, piece of insight: which is that I don't really
| _ever_ hear my inner monologue. I 'm not sure I have one!
| I'm either typing out my thoughts as I have them or
| speaking them as I have them.
|
| I struggle in coding interviews _precisely_ because of
| this: either I end up vocalizing my emotions and
| insecurities instead of coding, or I end up coding
| instead of talking about what I 'm trying to accomplish.
| Often I will see many alternate pathways branching out
| before me, but if I try to start talking about them, I am
| no longer coding, and so my brain context-switches to
| "social and emotional."
|
| Probably something I could get better at with practice,
| but I honestly end up commenting on places like HN simply
| because it "allows" me to think. If I could have a coding
| interview in the form of realtime text chat + code, that
| would be ideal for me.
|
| I guess I have seen companies do things like "contribute
| to this open source project and work through an MR." I do
| find that quite appealing as an interview process.
| entropicdrifter wrote:
| Interestingly, it turns out a large number of people have
| no inner monologue. [1]
|
| Some studies indicate that it's as low as 30% of people
| who _do_ (so 70% don 't have an inner monologue), while
| others show the opposite, implying around 75% of people
| have some amount of inner monologue while 25% do not.
| It's a difficult subject to test and study since we don't
| have direct access to people's minds and asking someone
| what they're thinking about literally forces their
| thoughts through the filter of language.
|
| [1] https://science.howstuffworks.com/life/inside-the-
| mind/human...
| basil-rash wrote:
| This is a fairly common condition, along the same lines
| as aphantasia (lack of inner-picture, rather than inner-
| voice). I do not believe there is any "cure" for it.
| josephg wrote:
| I don't have a sense of a persistent inner voice either,
| but I can verbalise my thoughts just fine. It feels to me
| like the part of my brain that turns thoughts into
| English sentences automatically goes to sleep when it's
| not being used. And that brain power can be used for
| something else.
|
| When I'm doing particularly hard programming work, I
| can't have words said near me. Even music with lyrics
| messes me up. I think because it wakes up my "thoughts to
| English" pathway and that gets in the way of my "thoughts
| to code" pathway.
|
| Anyway, I don't want to be cured. There's nothing wrong
| with my mind. If anything I feel sorry for people who
| can't turn off their inner dialogue, because it means
| they can never use those neurons for other tasks - like
| maths or programming.
|
| Personally I can talk while programming if an interviewer
| wants that, but I'll be a bit dumber at the keyboard than
| if I sat in silence.
| bobthepanda wrote:
| Personally I only ask super easy questions because you
| should at least be able to talk about something trivial.
| Yet unfortunately the question "find the second largest
| number in an array of numbers" has a high failure rate as
| the first question, because there are a lot of people lying
| on their resume just throwing spaghetti at the walls.
| bragr wrote:
| It's not a test of someone's conversational skills, its a
| test of their technical communication. Conversational
| skills get tested in the small talk and introduction phases
| at the start and end of the interview.
| feoren wrote:
| > I don't talk while I code. You don't either.
|
| That's quite an assumption. You've never heard of pair
| programming? You've never asked for help on a bug in your
| code? You've never talked through alternate approaches to a
| piece of code with a coworker? You've never hashed out an
| interface or a method signature or some pseudocode while
| talking through the problem? You've never walked through a
| calculation with an SME? All of these are "code and talk at
| the same time" exercises.
|
| If I'm being brutally honest, I have a deep-seated
| suspicion that everyone who says they can't talk and code
| at the same time also just _cannot code_ at all. I don 't
| know you, of course, and I'd love to be proven wrong. My
| sample size is small, but the few people I've met who
| cannot talk-and-code also simply could not code.
| nox101 wrote:
| You are the exception I think. Most interviewers care about
| the correct answer. Get it and maybe get the job. Fail and
| definitely don't get the job.
|
| If the interviewer said at the beginning, "I don't expect you
| to solve this problem in the 40 minute nor to have an optimal
| solution. I just want to watch you write some code and hear
| the problems you foresee and how you'd solve them" then maybe
| I could relax and do that. But, generally the pressure is on
| "get this right in 40 minutes or you're rejected"
| kyralis wrote:
| This is actually why I dislike these "coding interviews are
| useless" type articles. The issue has as much or more to do
| with bad interviewers than it does with the fact that it's
| a coding interview.
|
| When I'm tasked with interviewing candidates and evaluating
| these basic algorithmic and coding skills, I have a 5-part
| problem (each building on the next, and only revealed when
| the previous one is complete) that is basically impossible
| to finish in the time allotted. I tell the candidate ahead
| of time that it's an ongoing problem that's designed to not
| be completable in the time: we're going to work through
| this problem and see how far we get. I've passed candidates
| who "failed" the actual problem, when the conversation and
| coding that were shown still gave me a good understanding
| of their capabilities.
| darrenkopp wrote:
| I, personally, cannot _think_ and _talk_ at the same time.
| It's just a stream of half-sentences, many of which my brain
| has already moved on from because what I originally thought
| won't work.
|
| After writing this article it became very apparent to me that
| I'm complete garbage at interviews, but I'll outperform and
| exceed at the actual job function.
| feoren wrote:
| In my work, if you literally cannot write any code while
| also discussing the code, and if you literally cannot
| express thoughts while also thinking them, then you
| actually _wont_ exceed at the actual job function, at all.
| You 're not the only programmer on the team. I don't know
| why people think communication skills are not required for
| programmers. You won't be coding the correct thing unless
| you can talk about what you're doing.
|
| And that's all I ever ask in an interview. Ask questions
| and talk about what you're doing. The worst hires I've ever
| seen were all the ones who never asked questions and never
| talked about what they were working on. Half sentences are
| fine; moving away from the keyboard while we talk is fine;
| being unable to talk and think at the same time probably is
| not.
| darrenkopp wrote:
| If I'm not cut out to work in your environment, that's
| fine. I do disagree with your other conclusions, however.
| I'm not bad at communication, I'm bad at verbal
| communication while simultaneously trying to solve a
| problem. I'm excellent at problem solving and
| simultaneously chatting in something like slack, however.
| xandrius wrote:
| I would like you to be the interviewer of all my future jobs,
| please.
| hansvm wrote:
| The normal way to phrase that is "are you hiring?" :)
| kyralis wrote:
| You are not alone! This is also how I run coding interviews -
| I have absolutely passed candidates who did not actually
| complete the described problem. I always inform my candidates
| that we want to have a conversation about the problem and its
| solution. I also deliberately pick questions that are going
| to need thought and some design, specifically to spark that
| conversation - talking about reversing a list gets boring
| pretty fast.
|
| The issues people have with coding interviews are more about
| the interviewers than the questions, honestly.
| darrenkopp wrote:
| Adding another comment here, because this is part of the
| reason why I wrote this article.
|
| > These kind of articles make me sad because I (and many
| other interviewers I've worked with) try to make it clear
| that this isn't a test - we don't care so much about being
| "right" or "wrong", and there shouldn't be any tricks of "a
| ha" moments. > We explain the goals and what we're looking
| for right up front. And I would hope most interviewers do the
| same, but I guess not. So there's this persistent myth among
| both interviewers and candidates that coding questions are
| about getting a right answer.
|
| I understand all of those things. I've written the same
| before[1]. However, as clear as your instructions are and as
| well meaning you may be, it may not help. I can logically
| understand every word you say, but as soon as that question
| rolls out, I will now be dealing with stress hormones and 30
| years of learned behaviors from thousands of experiences,
| whether I choose to or not.
|
| So while I applaud your methodology and wholeheartedly agree,
| just telling people that doesn't guarantee that it's not
| still an issue because humans are complex organisms.
|
| [1]: https://darrenkopp.com/posts/2016/02/25/always-learn-
| somethi...
| nineplay wrote:
| The problem is that the candidate has been assured that they
| will be asked 'leet' code questions where solving the problem
| isn't enough, they will also be asked about O notation and how
| the code can be optimized and whether to use memoization or
| recursion. This is what the books will tell you, this is what
| YouTube will tell you, this is what 'helpful' recruiters will
| tell you.
|
| And IME this is what most interviewers have been taught.
| They've got a list of sample questions, they've been told that
| if they give the knapsack problem and the interviewee doesn't
| immediately call out 'dynamic programming' than the interviewee
| is a pass.
|
| If you only want to see working code than you are the exception
| rather than the rule.
| kevincox wrote:
| I will ask all of those questions. But I don't expect perfect
| answers. You should at least know what big O is. I would
| really like it if you can tell an O(n^2) algorithm from a
| linear one. (That is often really important in real-world
| code). I would like you to consider different ways you can
| optimize the code.
|
| I don't expect you to quickly crank out a novel optimal
| algorithm. But I like to see that you can think about how to
| solve problems programmatically. I would like to see you can
| identify differences in different algorithms and what
| tradeoffs there are. Considering different approaches that
| may be faster also shows that you didn't just memorize an
| algorithm from somewhere but that too took time to actual
| understand the problem and build a mental model in your head.
|
| I have given people great reviews when they couldn't come up
| with a working algorthim because the clearly knew how to
| think like a programmer and considered all of the important
| things.
| nineplay wrote:
| That's a pretty far cry from
|
| > which is to make sure the candidate can actually write
| code, like at all
|
| It's also still a terrible approach and only gets leet code
| crammers.
| ChrisMarshallNY wrote:
| This was an interesting observation:
|
| _> What I do know, however, is that for every 1-hour interview
| where I evaluated if someone knew their data structures, I could
| have just taught them._
|
| I don't really hear much about training. I doubt it's because we
| don't do it, but maybe it's not an interesting topic for
| discussion.
| angarg12 wrote:
| Sounds a bit delusional to me that you can just "teach someone
| data structures in 1 hour".
|
| Also the role specifics matter here. It might be ok to bring in
| a junior who needs lots of mentoring onboard. For a tech lead
| who is going to be driving the direction of a team, I'd expect
| them to be up to speed and autonomous very quickly.
| spankalee wrote:
| It's not "teach someone data structures in 1 hour", but teach
| them the approach needed for that problem in 1 hour.
|
| And it's a pretty insightful comment, because being able to
| be taught a practically useful algorithm, and use it on a
| question, in just an hour is a sign of a good candidate.
| Interviews should often be run just like that.
| Paul-Craft wrote:
| I don't think "I can teach someone data structures in 1 hour"
| is a good faith interpretation of what OP meant. I would
| expect it's more like "I could teach someone about a data
| structure that could be used to solve this problem
| efficiently and simply in 1 hour" is closer to the mark.
| GoToRO wrote:
| Training is not billable. Managers decided they only like
| billable hours. Kind of like when you decide that you only like
| winning the race and you hate training.
| mrmetanoia wrote:
| I dropped out of school (English literature) because I needed
| to make money and pay bills due to a life change, and i applied
| at a place that does internet stuff to do tech support because
| computers were a big part of my hobbies. I moved up over the
| years learning as I went and now I've occupied a few
| 'engineering' roles. I used to feel somewhat embarrassed to
| hold an engineering role with no engineering degree.
|
| But I stopped worrying the more I worked with software
| engineers. They were just people, some sucked, some were great,
| their education almost never had anything to do with the
| bracket they fell into. The worst one I've ever met has a PhD.
| The best one I've met also has a PhD.
|
| Then I found more people in these positions that have degrees
| or no degrees, and the people that work well both with degrees
| and without had something in common. They can more or less be
| taught to do anything, they can extrapolate and apply knowledge
| outside of the specific example initially given, and they
| understand the big picture/desired end results. I hate to say
| it so crass, but they are good at identifying the trivial
| bullshit and addressing it or cutting through it rather than
| sitting in it. They "Get it." From the ideal to what the
| business demands, they just get it.
|
| Training competent people is a boon. I don't know how you seek
| out interested/curious competency and then train it, but if we
| can figure that out, it'd be cool. I'm really tired of working
| with people who have degrees and jobs because their mothers
| told them it pays well. Computer Scientists with no interest or
| curiosity about computers.
| majormajor wrote:
| Training and teaching is hard. "One hour of interviewing could
| be avoided with one hour of training" is wildly optimistic.
|
| It also ignores the breadth of knowledge you likely want a
| candidate to have (and are just trying to sample at through a
| short few interviews). How many hours of training are you
| willing to sign up for? How confident are you that the
| knowledge will "stick" for any given candidate? Are you going
| to fall back to GPA and school prestige to measure how well
| they've retained knowledge in the past? That seems like a step
| in the wrong direction.
| xandrius wrote:
| Yeah but a data structure is definitely some stuff one could
| grok in 1h.
| darrenkopp wrote:
| I don't think it's wildly optimistic, but perhaps we are
| thinking about it in different ways. I don't think I could
| teach someone how to implement each data structure in an
| hour, but I could easily go over
| maps/queues/stacks/hashtables and tell you when to use each
| in an hour. I know this because I do that very thing in less
| than an hour in code reviews.
|
| I do agree that the "stickiness" is iffy, but it usually
| sticks pretty well. You then have a second problem that can
| be described as "when you have a hammer, everything is a
| nail" as they use their new fancy hashtable everywhere.
| jlas wrote:
| Coding interviews are a lossy process. Once you realize this the
| angst of rejection softens and it becomes an almost mechanical
| effort.
| swozey wrote:
| I refuse to do code tests. I don't mind doing a small 2-3 hour
| project that I will walk the interviewer through to explain my
| reasoning for doing things the way that I did, but I cannot code
| in front of someone. I can't even type correctly on my keyboard
| if someone is looking over my shoulder.
|
| I've _never_ touched leetcode and I interviewed with Nvidia a few
| years ago for a position I was an absolute shoe in for,
| unfortunately they wanted me to do a live leetcode.
| bena wrote:
| I think people get confused with "the best" rather than "good
| enough". You'll never find "the best", you will find a number of
| people who will suffice.
|
| Interviewing should be more about avoiding bad candidates than
| finding the best candidate.
|
| This guy fails coding interviews. Then he gives coding
| interviews, but the people he selects based on these interviews
| are a mixed bag. Because he's failing the interview from both
| directions.
|
| I've given coding interviews, all the questions I've given have
| been "leetcode easy" level at worst. In person, I usually try to
| get the person to write up an implementation of Towers of Hanoi.
| One of the example recursion problems. The interview is not an
| adversarial process, it's a cooperative one.
|
| I want to see them think and I want to see them come up with code
| on the fly. Because while we can look up things on the job, at
| some point, it also requires original thought.
| darrenkopp wrote:
| > Interviewing should be more about avoiding bad candidates
| than finding the best candidate.
|
| > This guy fails coding interviews. Then he gives coding
| interviews, but the people he selects based on these interviews
| are a mixed bag. Because he's failing the interview from both
| directions.
|
| Good points, but I should say that the people that didn't work
| out weren't always because of technical abilities. The company
| that had the worst success rate was fully remote, but I don't
| know if there's any interview process that can help with that.
| rsyring wrote:
| We used four basic exercises during the first remote interview.
| Simple things like, "there is a number on each line of this text
| file. Find the sum of them."
|
| This was an effective method to screen out applicants who didn't
| have the basic coding skills to align with their stated resume
| experience. And there were a decent number of these.
|
| We did further development project exercises later in the process
| that took about 15 hours. We paid the candidates for this time,
| even those that didn't pass. It was also an effective screening
| tool.
|
| All our exercises were very "real world." In the candidates own
| development environment and having been given instructions on how
| to prepare. They also have access to whatever Internet resources
| they want while doing the exercises. If they can't do the
| exercises, they can't do the job.
|
| I know there are mixed opinions on this and I feel for candidates
| who have to invest a ton of time in exercises like this. But I
| can't imagine trying to hire without visibility into how they
| execute relatively basic software development tasks.
|
| I think employers can and should structure the process so the
| time investment is minimal upfront and only increases as both
| parties have gotten to know each other and want to proceed.
| cma256 wrote:
| 15 hours! You're hiring contractors not interviewing.
| mylons wrote:
| this seems completely reasonable compared to endless
| whiteboarding?
| bick_nyers wrote:
| Depends on the pay. If more companies start doing this,
| then you can imagine having to slog through 10-20 of these
| as an applicant will increase the time to find a job
| significantly. Most people don't get hired off of their
| first successful round of interviews. If the company pays
| as much as the job salary itself then I am fine with this.
| nox101 wrote:
| I'd expect lots of employed people with families not to
| have 15 spare hours X the number of companies they are
| interviewing with
| whimsicalism wrote:
| Paid how much? 15 hours is over a thousand dollars - probably
| closer to 2 or more
| mylons wrote:
| is that really a lot of money for a company? don't you often
| spend that much in having your developers interview
| candidates and white board them?
| whimsicalism wrote:
| i am curious how much they are _actually_ paying. i have no
| intrinsic qualm with it and agree that developer time is
| expensive
| xandrius wrote:
| Do they get paid the rate of the position in hours?
| gwbas1c wrote:
| > and then finally an interview with David Fullerton and Joel
| Spolsky
|
| Joel Spolsky wrote the book on interviewing a software engineer:
| https://www.joelonsoftware.com/2007/06/05/smart-and-gets-thi...
|
| The book is a fun read, but it's easy to miss a very critical
| detail: A coding interview is supposed to demonstrate that a
| candidate is comfortable coding, not that a candidate can wrote
| memorize XYZ algorithm, or read your mind well enough to care
| about the corner cases that you care about.
|
| I always give a lot of hints, and focus on that "we're having a
| discussion about code" when I interview a candidate. I don't
| expect a 100% right answer the first time, but I do expect a
| candidate to have a certain degree of intuition about how to
| program a computer.
| phendrenad2 wrote:
| Here's what nobody wants to admit: Software development is
| probably 10% engineering, 20% science, 20% putting blocks into
| holes ("when MICROSERVICE apply KAFKA"), and 50% arts & crafts.
| And we're just testing for the blocks-in-holes part.
| kstenerud wrote:
| My approach to interviews over the past decade has been as
| follows:
|
| 1. My preparation for an interview involves researching the
| company, not technical matters. I don't brush up on coding
| interview questions. I've never done leetcode.
|
| 2. If I find the interview questions to be ridiculously off-topic
| (such as silly algorithm questions), I end the interview. You're
| not the kind of company I want to work with.
|
| 3. If I find the questions to be valid, but I can't answer them,
| then I'm not the right candidate for the job (hopefully I'd
| already have found this out during the research phase, but we all
| make mistakes).
|
| 4. If we can get past all this gatekeeping to the actual
| important topic if what BUSINESS issues they're trying to solve,
| and how I can fit into this process, then we've got a real
| interview and I'm interested.
|
| So far I haven't been out of work more than a few months.
| gardenhedge wrote:
| How do you end the interview? To me it seems like that might be
| awkward.
| theideaofcoffee wrote:
| I'm not op, but I have had to do this a few times because of
| the same reasons. You pause, take a breath and kindly say
| "thank you for the opportunity, but at this time I don't
| think this is the right fit" and leave it at that. No need to
| embellish, or add extraneous detail or think you're being
| awkward because they will do the same thing if they don't
| want to go further in the process with you. It's just
| business, treat it as such.
| josephg wrote:
| If I'm considering ending the interview, I'll instead
| critique it on the spot. It's more interesting for
| everyone. If they pass me over, that's fine - I'm already
| considering walking out anyway.
|
| "Hey, can I stop you there for a minute? This interview
| style isn't really working for me to the point that I'm
| considering cutting the interview short and heading out.
| Here's why ..." - and then have that conversation. Some
| people will take that badly - and that's fine. But I have
| no idea what will happen next after saying something like
| that. And that makes it an interesting direction to take
| it.
| xandrius wrote:
| We should be a union of people who won't take this kind of bs.
| I have the same exact procedure as I think interviews like that
| show a complete lack of understanding of what makes a developer
| great in a company, and let me tell you, solving
| CodeSignal/Leetcode unpaid for hours isn't that.
| iamleppert wrote:
| I have done a few of these types of interviews. It's incredibly
| awkward. At one place, I was even issued a laptop, a badge and
| added to the Github organization. I mean, I guess? But it felt
| like I was starting work, not doing an interview. People there
| also didn't know if I was a new employee or who I was when I
| went to lunch and get snacks. I spent more time getting my
| local dev up and running than actually doing the task I was
| assigned, which they could have gathered the same information
| about me in a 30 minute interview.
|
| If you can't determine from a few interviews you want to hire
| me or not, it's a no from me. It's a HUGE red flag if an
| employer can't seem to make up their mind so they have to
| resort to awkward "test drives" like this. If you have a job at
| the time already, it also makes it almost impossible to pull
| off without using PTO.
|
| Add all these things together and you really don't want to work
| for a company who is very inexperienced in hiring such that
| they resort to tests like these. It shows they don't know how
| to interview, are not efficient with your time (and probably
| their time also), and a high chance they are non-technical.
| quantum_state wrote:
| It's the right and honest way to go about it: good fit from
| perspectives of both sides ... that's the original purpose of
| interviews.
| jytechdevops wrote:
| i wouldn't give much weight to somebody who's resume shows a work
| history of starting out after college as a "CTO" to two
| "Principal Engineer" positions...
| xandrius wrote:
| Why not?
|
| I would still talk to them, it they actually were a CTO for a
| period and then got hired as Principal Engineer, they might be
| extremely talented.
|
| I find these meaningless reasons bullshit, just tell me that
| you spinned the roulette and 5 red came out and I needed a 7
| black to be chosen to be talked to. At least I don't start self
| doubting myself just because someone didn't like my formatting
| or the choices I made after university.
| darrenkopp wrote:
| Actually there's another job before that, I just don't list my
| full employment history. Before that was VP of Engineering.
| That's just my final title, however. I started that as a normal
| engineer. And then as a senior engineer before CTO.
|
| Small companies, so not the same as being VPE or CTO at Amazon.
| You see those as title downgrades, but I don't. I have a lot of
| talent, so people want to promote me and put me in charge. I
| don't want to be a manager/leader currently, I want to be a
| strong IC.
| frithsun wrote:
| It's against federal law to IQ test employees, so they ask brain
| teasers that are IQ test questions thinly disguised as "coding
| questions."
|
| It's not a perfect system, but it works better than the
| alternatives.
| kstrauser wrote:
| Maaaaaybe, but I'm not ditching them. When I'm interviewing
| someone, I try to set them at ease. I'm not here to spot typos.
| I'm trying trying to trick you. I want to see how you think about
| problem solving, and _I'm cheering for tou_. I want you to be The
| One!
|
| At a prior job I was the person who asked candidates to write
| fizzbuzz, and it was much more of a filter than I ever would have
| suspected. One senior engineer, from a company you know, with a
| master's in compsci, couldn't write a for-loop for the life of
| 'em. Another QA engineer wanted to write tests for their
| implementation by capturing stdout and comparing it to a
| hardcoded string.
|
| Me: What if you want to test the output of 1,000,000,005?
|
| Them: We could store the test output as a file on disk instead of
| a string!
|
| Me: Well, ok, suppose you only want to test that one specific
| value and not all the others?
|
| Them: Ah, got it! We could discard all but the last line of
| stdout and just look at that.
|
| Me: Can you think of a way to structure your code so that we
| could just calculate the output of one single number without all
| the numbers before it?
|
| Them: Uhhh...
|
| Those are 2 examples out of many. I honest to god don't know how
| some people managed to build their resumes while not knowing how
| to do the simplest thing in their field imaginable. Imagine you
| were interviewing cardiologists and a solid 1/3 of them had never
| heard of blood. What? How? How did you get to this point?
|
| And that's why I'd never hire someone until I've collected
| evidence that they personally can turn ideas into code. If you
| can't wrap your brain around fizzbuzz, you're gonna have a hell
| of a time when a customer gives you a change request.
| r0s wrote:
| Everyone seems to agree live code interviews are both terrible
| and necessary.
|
| I'm a self-taught coder without a degree. I guess it may be extra
| frustrating for graduated candidates where your hard-earned
| degree buys you no credibility for skill.
|
| Kinda similar, after ten years of lead development coding every
| day in the enterprise on huge projects I still don't get a pass
| on the code interviews.
|
| I will say, if you're trying to career pivot and apply for a
| management or product or sales engineering role etc., lots of
| technical experience does carry weight in interviews.
| hintymad wrote:
| Assuming that a company does not look for candidates who are
| naturally good at ICPC-type of questions or geniuses who can come
| up with amazing algorithms in a matter of minutes, there is
| actually a different way to do coding interview: just give a
| high-level description of a sophisticated enough algorithm to a
| candidate and ask the candidate to turn that into code. I think
| it strikes a good balance between depth in CS and the coding
| abilities. This type of interview is similar to what engineers do
| at work too. We rarely invent new algorithms, but we do read
| white papers or blog entries or books to pick an algorithm to
| implement.
|
| There are many variations in questions too: search a tree or
| graph with some customized criteria, using a double buffer to
| implement a tree-style prefix scan, implementing an integer
| multiplication with unlimited digits, some streaming algorithm,
| tree-walking to transform one tree to another, a simplified skip
| list, the options are unlimited. A good candidate tends to grasp
| the high-level concepts quickly (and they can ask questions), and
| is quick to convert intuition into working code. I find that
| there is a strong positive correlation between the performance in
| work and the performance in such coding interviews.
| xandrius wrote:
| I still don't get why such questions are even asked as most
| jobs I've ever had not even remotely touched those and I've
| touched quite a few industries, technologies and types of
| companies.
|
| To me, the value of a software engineer is to ask questions,
| make hypotheses and be able to iterate quickly. Balancing
| trees, leetcode and other algorithmic stuff on the spot sounds
| like bringing the dreadful education system structure to the
| real world.
|
| Also if a senior person can't in 30/45 min of talking with
| someone figure out the general experience level then the
| problem is them, really.
| hintymad wrote:
| Personally I think such questions have three values:
|
| - Future proof. Unless I work for an outsourcing company,
| sooner or later I will want to push the envelope, or so I
| hope I do. And to push the envelop, one needs good CS
| fundamentals (maybe there are some exceptions in some
| specialized field). Think about React. It's a JS framework,
| yet to invent it one needs to understand at least compiler
| and graph.
|
| - Geekiness/talent filter. The same reason that the nascent
| Google and Microsoft and any elite companies like Jane Street
| asked Putnam questions, Martin Gardner questions, ICPC
| questions, and clever probability puzzles. Whether it's a
| good idea is debatable, but at least those companies want to
| have such type of people and they were hugely successful.
| Note the word filter: people who pass the interview may not
| be good, but failing the interview means the candidate may
| not be smart or geeky enough. Again, I'm not endorsing the
| idea but just exploring the motivation of the interview
| policies.
|
| - Information density. Assuming a company does want to time
| box a coding interview in an hour, it will be hard to come up
| with realistic question without spending too much time on the
| context. On the other hand, it's relatively easy to come up
| with a data structure/algorithm question that packs enough
| number of abstractions and inspection points to examine one's
| programming skill.
| davidw wrote:
| > Think about React. It's a JS framework, yet to invent it
| one needs to understand at least compiler and graph.
|
| Are you hiring people to create new JS frameworks, or to
| use an existing one?
| paulddraper wrote:
| To use an existing one.
|
| And tools are best used when they are understood.
| davidw wrote:
| Hiring, like many things - including engineering - is
| about tradeoffs.
|
| Is someone more knowledgeable "better"? Sure. But
| sometimes it's about getting a specific thing done, and
| if you're hiring someone to improve a web thing that uses
| React, maybe you don't _need_ someone who understands
| compilers and the kernel and how the underlying hardware
| works and all that. Maybe you can spend a bit less and
| get someone who will do a perfectly adequate job.
| bjablonski wrote:
| How many react developers understands compilers & graphs?
| I'd wager that it's way below 10%.
| mewpmewp2 wrote:
| Also why do you need knowledge on compilers and graphs to
| create React?
|
| Firstly, React is not compiled. Secondly the graph or
| tree or whichever aspect can come naturally when you come
| up with the idea of how it would be best to maintain JS
| apps.
|
| In fact most important experience should have been
| grinding put tons of unmaintainable JS apps to come up
| with something like that.
| Paul-Craft wrote:
| I don't know anything about quantum mechanics. Does that
| mean I don't understand how computers work?
| hintymad wrote:
| Well, I guess the example is more confusing than
| clarifying. I used that for a case of pushing the
| envelope. When Facebook needed a better solution for
| their feeds, they invented Reactive, and I was saying
| that one would need to know compiler to build JSX and
| need to graph to build the optimized virtual DOM. Yes,
| nowadays we just hire Reactive users, but my point is
| that in the future we may have another moment that we
| need to invent something, and as a company founder I sure
| would like to hire the author of Reactive or the like.
| paulddraper wrote:
| > I still don't get why such questions are even asked
|
| The thesis is not that these exercises are _representative_
| of work but rather _predictive_ of performance.
|
| Sales has a similar phenomenon with sports. While there is no
| athleticism involved in selling, many believe history in
| competitive sports to be a positive predictor of sales
| success.
|
| ---
|
| You can reasonably argue whether leetcode accomplishes this
| well or poorly, but...
|
| Always remember that purpose of an interview (for an
| employer) is to _predict performance_. So you are looking for
| the resume screening+interview process that most accurately
| assesses that.
| xandrius wrote:
| So you're saying that someone wasting their time studying
| leetcode to pass a stupid game is a good indicator?
|
| I would almost believe the opposite: if you actually pass
| those tests with flying colours, it shows me that you
| believe you needed to do that to be hired, while someone
| who's actually experienced would never in a million years
| step down so low.
| paulddraper wrote:
| I didn't state my personal opinion above, but yes I have
| seen leetcode aptitude to positively correlate with day-
| to-day problem solving.
| xandrius wrote:
| If your company uses leetcode to filter out employees
| then you are a leetcode team with your internal levels
| and ranks, not at all representative of the whole
| population of skilled IT people.
| josephg wrote:
| How would you, or anyone, know if your career is
| representative of the field?
|
| I'm sure plenty of people spend their career never
| learning or using data structures and algorithms
| knowledge. But I suspect plenty of people spend their
| career using this stuff all the time. Eg people who work
| in databases, compilers, operating systems, video games,
| ai, crypto currencies, and so on.
| pseudalopex wrote:
| I have seen Goodhart's law.
| josephg wrote:
| I believe skill at "leetcode problems" is predictive of
| general programming skill. Someone who can solve leetcode
| problems can almost certainly learn css. But, clearly
| from reading comments here, not the other way around.
|
| Personally I love leetcode style problems. They're fun.
| And useful - I use this stuff in my job constantly.
| mewpmewp2 wrote:
| I would be scared you are overengineering and optimising
| things though. I have seen people implementing complex
| paradigms and weird optimisations instead of writing
| simple code just to make sure they are perfectly
| optimising.
|
| E.g. optimising client side code where N is likely never
| to be above 300, but instead of few simple lines, write a
| complicated solution to make sure it can scale to
| billions and beyond.
|
| I would take any problem solving energy and spend it on
| side projects instead of doing leetcode. I do like those
| exercises, but I enjoy building new things more and which
| gives me practical experience which I think is more
| important.
| josephg wrote:
| Skill gives you the gift of choice. You know how to write
| it either way around and it's up to you to decide. Being
| able to correctly decide when to hack something
| inefficient together and when to optimise is another
| skill issue. It'd make a good interview question, that.
| mewpmewp2 wrote:
| Yeah, but leetcode does not necessarily give you that
| skill or even prove it. And a talented problem solver
| would be able to find optimal and practical solutions
| when they are required and are not premature even without
| doing leetcode.
|
| You might get false positives as well. E.g. you get
| people who are tunnel visioned on leet code, cracking the
| coding interview and other common system design books,
| they know all the answers, but then they completely lack
| common sense day to day and it can be hard to test for
| that if you are solely focusing on leetcode.
| hintymad wrote:
| > The thesis is not that these exercises are representative
| of work but rather predictive of performance.
|
| Well said. Just like in college, calculus (not analysis)
| and organic chemistry are used as filter courses. Of
| course, why the two courses, especially organic chemistry,
| are so hard to American students is another topic. I
| personally think that it shows the failure of the education
| system of the US.
| Paul-Craft wrote:
| > Sales has a similar phenomenon with sports. While there
| is no athleticism involved in selling, many believe history
| in competitive sports to be a positive predictor of sales
| success.
|
| This is interesting. I had never heard this before. Is
| there any research on this? For that matter, is there any
| actual research showing that leetcode-style interviews
| actually do predict performance? If so, do they do so any
| better or differently than an IQ test?
| devbent wrote:
| >I still don't get why such questions are even asked as most
| jobs I've ever had not even remotely touched those and I've
| touched quite a few industries, technologies and types of
| companies.
|
| I've had to work on tree traversal stuff multiple times in my
| life, anything low level GUI related will work with trees a
| ton.
|
| I've also had to work with hash tables directly, and with
| memory caching layers.
|
| I really should learn to write a proper parser, as I've had
| to write parsers multiple times now and they are always an
| ugly hack job.
| josephg wrote:
| Yep. In a project I'm working on at the moment (collab text
| editing), I've implemented 2 different b-trees, a skip
| list, 2 custom file formats and a dozen or so algorithms
| which do various graph traversals.
|
| I get that this is uncommon, but if you scratch beneath the
| surface, most software (browsers, databases, compilers,
| OSes) are full of this stuff.
|
| Even while I was consulting stuff like this would come up.
| At one company we were using a custom graphql wrapper
| around a CMS, and it was missing some functions we needed.
| The wrapper was implemented like a compiler from the cms's
| data format to a set of query functions. Fixing it to do
| what we needed it to do was really hard and broke my brain
| a bit. But I did it. And I wouldn't have been able to
| without understanding compilers and algorithms.
|
| You can spend your whole career walking the beaten path
| adding features to apps and websites, and never traversing
| a tree at all. There's lots of work like that out there.
| But if you ever want to go deeper, you've gotta understand
| data structures and algorithms. I know not everyone is
| suited to it, and that's fine. But there's definitely a
| reason big tech asks about this stuff.
| sanderjd wrote:
| > _But if you ever want to go deeper, you've gotta
| understand data structures and algorithms._
|
| I don't think this is _quite_ right. I think it 's more
| like:
|
| If you ever want to go deeper, you've gotta be able to
| recognize when the problem you're solving fits a pattern
| for which good data structures and/or algorithms exist,
| and you've gotta be able to find, understand, and apply
| good reference material.
|
| Solving this "knowing what you don't know" problem is the
| best and most important role of formal education, in my
| opinion. It's not as important to _know_ a topic as it is
| to know that it exists, and some of the basic terminology
| necessary to get started researching it further.
| pseudalopex wrote:
| > I've had to work on tree traversal stuff multiple times
| in my life, anything low level GUI related will work with
| trees a ton.
|
| How many times did you have to write tree balancing code
| with no reference materials?
| Paul-Craft wrote:
| Bingo. You forgot to add "with someone literally looking
| over your shoulder," though.
|
| I've written AVL trees, B-trees, red black trees, and a
| bunch of other things people have named here. But, right
| now, without looking at any references, I couldn't even
| tell you how to balance an AVL tree, much less sit down
| and write out code for it.
| whstl wrote:
| I disagree with some of this.
|
| At some of my past jobs and the current one, this kind of
| algorithmic knowledge was important to build features that
| were differentiators in the market. As much as people love to
| pretend, not every single possible solution is in a library.
| Sometimes you're the one building the library.
|
| It doesn't have to be leetcode, but candidates should at
| least be able to produce some code that doesn't come from the
| README of their favourite framework.
|
| Also, talking for 30/45 mins can be enough, but it produces
| false positives when you have people coaching candidates.
| I've had people completely acing interviews that it felt like
| the perfect candidate. Well, it was rehearsed. When I asked
| for a fizz-buzz type question they completely messed it up.
| godelski wrote:
| > if a senior person can't in 30/45 min of talking with
| someone figure out the general experience level then the
| problem is them, really.
|
| This is why I've always been so confused. Why is the software
| engineering interview wildly different from the traditional
| engineering interview (seniors sit down with candidates and
| discuss how to solve a relevant proxy problem the team is
| currently undergoing (has the side benefit of making the
| interview process potentially fruitful if you don't go with
| that candidate. This can be (and sometimes is) abused
| though)). I mean... we all speak the same language, and that
| isn't standard English... right?
| markwkw wrote:
| Mechanical engineering interviews seem to do the same as
| software: "Engineers always ask about beam bending, stress
| strain curves, and conservation of work. Know the theory
| and any technical questions are easy."
|
| Basically an equivalent of simple algorithmic questions.
| Not "real" because it's impossible to share enough context
| of a real problem in an interview to make it practical.
| Short, testing principles, but most importantly basic
| thinking and problem solving facilities.
| godelski wrote:
| > Mechanical engineering interviews seem to do the same
| as software:
|
| I've been an engineer in the past (physics undergrad ->
| aerospace job -> grad school/ml). I have never seen or
| heard of an engineer being expected to solve math
| equations on a whiteboard during an interview. It is
| expected that you already know these things. Honestly, it
| is expected that you have a reference to these equations
| and you'll have memorized what you do most.
|
| As an example, I got a call when I was finishing my
| undergrad for a job from Raytheon. I was supposedly the
| only undergrad being interviewed but first interview was
| a phone interview. I got asked an optics question and I
| said to the interviewer "you mind if I grab my book? I
| have it right next to me and I bookmarked that equation
| thinking you might ask and I'm blanking on the
| coefficients (explain form of equation while opening
| book)". He was super cool with that and at the end of the
| interview said I was on his short list.
|
| I see no problem with this method. We live in the age of
| the internet. You shouldn't be memorizing a bunch of
| stuff purposefully, you should be memorizing by accident
| (aka through routine usage). You should know the
| abstractions and core concepts but the details are not
| worth knowing off the top of your head (obviously you
| should have known at some point) unless you are actively
| using them.
| glandium wrote:
| We live in the age of ChatGPT. It might actually be time
| to assess how candidates use it during interviews. What
| prompts they write, how they refine their prompts, how
| they use the answers, whether they take them at face
| value, etc.
| skydhash wrote:
| You might as well ask how they use book libraries and web
| search.
| epolanski wrote:
| I'm a chemist by education, so all my college friends are
| chemists.
|
| Being asked a theoretical chemistry question at a job
| interview would be...odd.
|
| You can be asked about your proficiency with some lab
| equipment, your experience with various procedures and
| what not.
|
| But the very thought of being asked theoretical questions
| is beyond ridiculous.
| scruple wrote:
| I've only ever had a single whiteboard interview in my
| career, and it was a single interviewer who preferred them
| (I accepted the job), but I have also walked through the
| backdoor via recommendations for all but 1 of my employers
| in ~20 years in the industry. From embedded in radio and
| television broadcasting, to medical robotics, to AAA games,
| with some excursions into web development. Every other
| interview at a company I accepted an offer for was a
| conversation with engineers about my experience and some
| hypotheticals.
| epolanski wrote:
| > Why is the software engineering interview wildly
| different from the traditional engineering interview
|
| I have my personal theory.
|
| 1) Top companies receives way more applications than the
| positions they have open. Thus they standardised around
| very technical interview as ways to eliminate false
| positives. I think these companies know this method
| produces several false negatives, but the ratio between
| those (eliminating candidates that wouldn't make it and
| missing on great candidates) is wide enough that it's fine.
| It does leads to some absurd results (such as people
| interviewed to maintain a library not being qualified
| despite being the very author) though.
|
| 2) Most of these top companies grew at such rates and
| hiring so aggressively from top colleges that eventually
| the interview was built by somewhat fresh grads for other
| fresh grads.
|
| 3) Many companies thought that replicating the brilliant
| results of these unicorns implied copying them. So you get
| OKR non sense or such interviews.
| lmm wrote:
| > Also if a senior person can't in 30/45 min of talking with
| someone figure out the general experience level then the
| problem is them, really.
|
| OK take it as read that your posturing has succeeded and we
| all agree that you're a brilliant interpersonal genius and
| the rest of us are all useless chumps. What then? The rest of
| us still need to interview and make hiring recommendations.
| Or are you suggesting that employers should fire anyone who
| lacks your magical talent?
| blindriver wrote:
| Unless you have data to show that your "different way" produces
| better results, your idea sounds exactly the same as every
| other idea, which is basically garbage.
|
| Lots of people have lots of ideas on what makes a great
| interview question, but none of them are backed by data.
| LeetCode-style algo questions USED to be an indicator of
| intelligence as per Google's investigation, but now it's so
| heavily gamed that I doubt there's any signal behind it
| anymore.
|
| Someone needs to spend time and effort and money and actually
| do random controlled tests to see if people who pass a
| particular type of test actually make good employees. But so
| far no one has done this, except Google as far as I've seen.
| But even now, I think there's no evidence that even algorithm
| questions are any indicator, given what I've seen.
| godelski wrote:
| > Unless you have data to show that your "different way"
| produces better results, your idea sounds exactly the same as
| every other idea, which is basically garbage.
|
| Do you have evidence that the standard coding interview
| works? (There's evidence that it doesn't)
|
| I'm with you that the claim might be too strong to say "this
| is the way" but that's because I'm of the (very strong)
| opinion that interviewing is an extremely fuzzy process and
| there are no clear cut metrics to measure one's abilities in
| a significantly meaningful way. all models are wrong but some
| are useful There are useful interviewing methods but
| certainly not "the best" method. Trying to just mark
| checkboxes only leads to mediocre results. The reason we're
| generally okay with this is because we more often than not
| don't need rockstars and it doesn't make sense to put a lot
| of time and energy into this process when we get sufficient
| results through lazy methods.
|
| FWIW, a typical (non-software) engineering job really just
| involves high level discussions like the OP suggests but even
| without the implementation. It is generally about seeing how
| the person thinks/problem solves and looking at problems they
| solved in the past. It isn't resource intensive and good
| enough. Because truth is, you don't know what someone is like
| as an employee until they are an employee (and even then this
| is fuzzy)
| blindriver wrote:
| > Do you have evidence that the standard coding interview
| works?
|
| No, I think that they are all garbage.
|
| The only way to really hire is by having a vibe check to
| see if they are someone the team wants to work with, making
| sure that the person seems competent and has a reasonable
| chance of being very productive, and then hiring them
| quick. Give them a month and if they don't seem like a good
| fit, then fire them, with 2 months severance.
|
| This is the only way I've seen that will produce a great
| team quickly, by hiring quickly and firing quickly. This is
| similar to what Netflix does but they also pay top of
| market which not too many companies can afford, but it
| produces the best results.
| hintymad wrote:
| All fair points, and I agree with you on rigorous
| experiments. For now we are talking about only intuitions.
| Paul-Craft wrote:
| > _LeetCode-style algo questions USED to be an indicator of
| intelligence as per Google 's investigation, but now it's so
| heavily gamed that I doubt there's any signal behind it
| anymore._
|
| Where can I find the data on this?
| jjtheblunt wrote:
| What is ICPC?
| pseudalopex wrote:
| International Collegiate Programming Contest
| jjtheblunt wrote:
| Thanks
| lesuorac wrote:
| Eh, if you hate coding interviews such much you can try something
| else like welding.
|
| Oh wait, welders have to prove they can weld before they get
| hired? [1]
|
| ---
|
| The general issue with coding interviews is most companies don't
| validate that the interview is actually correlated with job
| performance. Of course a process where the blind leads the blind
| is going to have issues.
|
| [1]:
| https://www.reddit.com/r/Welding/comments/26ppfb/what_to_exp...
| theideaofcoffee wrote:
| Even a skills-based test like welding, you do run up against a
| limited number of real standards, unlike coding interviews.
| What materials are you joining, measurements, what process are
| you using, do we have particular requirements about
| penetration, non-destructive test results, tensile strength,
| etc etc. That's the problem with modern development not having
| a central certification or licensure or a standards board/bar,
| everyone tests something different even if they think they're
| testing the same thing and it's a depressing mess.
| rdtsc wrote:
| > like we are stuck in a cargo-cult mentality where we are just
| doing things because that's what the big companies do, and if it
| works for them it must be what we need to do.
|
| Absolutely. They do leet code -- we must as well. Google is
| laying people off -- so must we. Steve Jobs was an asshole, I
| also must be an asshole, that's how you grow a great company.
|
| > The question, which I've heard is a Facebook favorite, was
| "convert a decimal number to base negative 2".
|
| Assuming I don't care as much about the the interview and am just
| practicing, I would have asked "so how often do you folks,
| convert numbers to base negative two?"
|
| > but fuck that question and just waiting for you to eventually
| arrive at the little trick to make it work.
|
| That sounds like a "coffin"-type problem as per
| https://arxiv.org/pdf/1110.1556. You have to know the trick, or
| you might spin your wheels for 40 minutes.
| feoren wrote:
| > I have, once again, failed an interview
|
| Can we stop calling it "failing" when a company decides you're
| not a good fit? If you go on a date and don't get asked for a
| 2nd, did you fail the date? You're not just what they're looking
| for right now; not everything has to be a failure.
|
| > for every 1-hour interview where I evaluated if someone knew
| their data structures, I could have just taught them
|
| I'm sorry, what? He thinks it takes _one hour_ to teach someone
| data structures? We sure are wasting our time with those multiple
| college courses and hundreds of textbooks on the subject then. We
| should just get this guy to spend _one hour_ imparting all
| necessary knowledge into everyone.
|
| > it's often said that what's more important is how you solve the
| problem, not that you solve the problem, but in practice human
| biases will work against you if you don't get close to it
| working.
|
| Human biases are much _more_ likely to work against you if the
| interviewers have not spent time trying to come up with a
| consistent test that they give everyone. Does the author think
| human bias is absent from non-technical interviews? The less
| standard your hiring methods are, the more bias you 'll have.
|
| > I'll just keep practicing for interviews until I successfully
| trick someone into thinking that I know how to code and then
| secretely become one of the best employees they have ever had.
|
| I don't know who Darren Kopp is, so maybe I'm about to get an
| army of replies saying he's their coding role model, but this is
| an article about whether code interviews work or not, and he's
| basically saying "if they don't hire _me_ , who will _definitely_
| become one of the best employees they 've ever had, then their
| coding interview process must suck". The other possibility is
| that Darren Kopp just isn't actually tremendously more stellar
| than everyone else and coding interviews are actually kinda
| working. For his argument to work, he has to be one of the best
| possible candidates for _every job_ he 's applying for. I just
| kinda doubt that.
| elevatedastalt wrote:
| > Can we stop calling it "failing" when a company decides
| you're not a good fit? If you go on a date and don't get asked
| for a 2nd, did you fail the date? You're not just what they're
| looking for right now; not everything has to be a failure.
|
| If you wanted to get the job, and you didn't get it, you
| "failed".
|
| There's no need to sugar coat it.
| darrenkopp wrote:
| > Can we stop calling it "failing" when a company decides
| you're not a good fit? If you go on a date and don't get asked
| for a 2nd, did you fail the date? You're not just what they're
| looking for right now; not everything has to be a failure.
|
| Fair point.
|
| > I'm sorry, what? He thinks it takes one hour to teach someone
| data structures? We sure are wasting our time with those
| multiple college courses and hundreds of textbooks on the
| subject then. We should just get this guy to spend one hour
| imparting all necessary knowledge into everyone.
|
| There's a difference between understanding how to implement one
| and just knowing how to use one that's already been written by
| someone and when to use it.
|
| > Human biases are much more likely to work against you if the
| interviewers have not spent time trying to come up with a
| consistent test that they give everyone. Does the author think
| human bias is absent from non-technical interviews? The less
| standard your hiring methods are, the more bias you'll have.
|
| Fair, but alas I don't know the rigors they have put their
| hiring process through. If I were a betting man, I'd still say
| that if we measured all processes using programming tests, the
| majority of successful candidates had working output by the
| end.
|
| > I don't know who Darren Kopp is, so maybe I'm about to get an
| army of replies saying he's their coding role model
|
| I've been told this by everyone who knows me
|
| > but this is an article about whether code interviews work or
| not, and he's basically saying "if they don't hire me, who will
| definitely become one of the best employees they've ever had,
| then their coding interview process must suck". The other
| possibility is that Darren Kopp just isn't actually
| tremendously more stellar than everyone else and coding
| interviews are actually kinda working. For his argument to
| work, he has to be one of the best possible candidates for
| every job he's applying for. I just kinda doubt that.
|
| Actually the only conclusion I have after writing the post is
| that I am not talented at interviewing. I do believe coding
| interviews have flaws for how they are used, but that doesn't
| necessarily make them wrong or right. I agree with your first
| statement, maybe I'm just not a good fit.
|
| Perhaps both of us are correct as I consider coding interviews
| more of an audition than anything else. If Tom Cruise auditions
| for a part and doesn't get it, does that mean he's a bad actor?
| Likely not.
|
| (I'm Tom Cruise here, btw).
| utensil4778 wrote:
| Where I work, we have a really just absolutely radical hiring
| process.
|
| We sit the candidate down, and present them with a task. Then we
| all sit down as a team and work the problem. The most recent one
| was building a game of marbles. None of us knew the rules of
| marbles, but the candidate knew how to take a vague task and work
| with the team to produce something functional.
|
| Which is what the job is. We ask the candidate to show us that
| they can do the job and then hire whoever 1) did the best work
| and 2) vibed with the team.
|
| Anyone who places real value on leetcode is not someone who
| should be managing programmers because _that 's not the job_. In
| precisely zero real-world situations does any programmer need to
| be able to write a red/black tree blindfolded on a whiteboard
| standing on one leg and signing the national anthem. In the real
| world you just grab the algorithm out of a book or stack
| overflow.
| 0xbadcafebee wrote:
| You cannot tell anything about a person by giving them a test,
| other than their test-taking ability (you are what you measure).
| You have to balance it against context and other information. If
| all you do is look at "the score", you're measuring the wrong
| thing. If your test leads to questions whose answers display
| competency and skill, you're measuring the right thing.
___________________________________________________________________
(page generated 2024-05-07 23:01 UTC)