That's because professional outcomes for programmers aren't related to aptitude. Nobody ever got promoted for writing good code. (But the reverse is very common.)
Harder programming questions do a worse job of predicting outcomes
211–220 of 540 posts
Re: Harder programming questions do a worse job of predicting outcomes
#212You realize that this approach is flawed the moment there are blogposts / books ( e.g. Cracking the coding interview ) on how to crack it. The how to crack 'x' becomes a field altogether ( coaching / youtube videos / blogs / books etc ). Also, platforms like hackerrank are adding fuel to fire. I read the CEO write somewhere that he wished the below "were taught in schools : 1) Communicating complex ideas with clarity…
I mean, this is literally how any kind of industry with a test develops. Do you think the MCATs or the Bar exam are flawed because they have books on how to do well? Whenever there is any kind of standardization for testing, some ecosystem will evolve around it.
The big difference is you pass the MCAT or bar exam once, then never worry about it again.
Re: Harder programming questions do a worse job of predicting outcomes
#213Earlier quoted context omitted.
Except for people over 50 who have probably realized there is more to life, why would some demographics be willing to grind less than others? Edit: By "over 50," I mean age demographics in general, which is the main thing that raises your family obligations. The only demographic division that I can think of that would reduce someone's willingness to abandon their personal life would be age.
They have kids. Developing a sentient being is a higher priority and more difficult than developing React Redux.
Wouldn't that just be another expression of age demographics?
Re: Harder programming questions do a worse job of predicting outcomes
#214Earlier quoted context omitted.
I go back and forth about how I feel about doing heavy algorithm/data-structure stuff in interviews. On the one hand, I have never once written any kind of sort algorithm or LRU cache by hand for a production system, because why would I? Pretty much every language's standard library has a fairly-optimized sort and caching thing built in, and if they don't then there's still probably a million outside libraries to do…
I think the important thing here is the difference between understanding complexity and implementing a sorting algorithm. If I were hiring a carpenter I would want to know they understand their tools and when to use them. I don't care if they don't know how to make them. But of course knowing how to make them suggests an intimate appreciation for the craft (looking your way Matthias Wandel)
The flip side would be asking a carpenter to do trigonometry problems or something... Anyway, what's most important is measure twice and cut once. That and following a blueprint and going the extra mile.
Re: Harder programming questions do a worse job of predicting outcomes
#215Because they're designed that way. It all comes down to: * Rejecting far more candidates than you need to -- so you can feel like you're hiring "the top 1 percent" * Giving yourself the feeling that you have an objective hiring process (when really you don't) * Making your own team members feel like they're super brilliant and special when really they're not That's what the modern hiring process is designed to do. An…
Don't forget that they introduce market friction to reduce developer turnover and reduce salaries. I suspect one of the reasons Google is so open about their process and the need to study is so that everyone follows suit. Thereby forcing people to take days off and do homework for even the most mediocre of positions, causing the switching costs of interviewing anywhere to become higher.
That's a nonsensical line of reasoning. Hard interviews don't reduce salaries, they increase them. Why do you think FAANG companies pay developers 300k+/year when there are so many lower-status companies who pay <100k/year and still manage to find hires? Because the latter are willing to hire candidates who have worse resumes and less impressive interview skills that the FAANG companies consider beneath them.
Re: Harder programming questions do a worse job of predicting outcomes
#216Earlier quoted context omitted.
I agree with the sentiment, but I noticed recently that TaxJar (I considered applying there at one point) mandates a trial period along these lines. From https://life.taxjar.com/distributed-team-hiring-process/ , "... We hope a candidate is able to spend somewhere between 80 and 160 hours working with TaxJar during their trial. ..." Presumably there are some people who are willing to do a trial, either concurrent wit…
TaxJar sounds insane. So after I go through up to 4 weeks of poorly paid work (while working my existing full-time job and raising a family), I get to participate in their hazing rituals! https://life.taxjar.com/taxjar-traditions/
Try flipping it and looking at it from their vantage point - probably they are aware that not many would take this up, which would leave only the kind of people they want to work with showing up to their doors ? Maybe it's a clever hack to filter people out ?
Re: Harder programming questions do a worse job of predicting outcomes
#217I changed careers from another technical non programming career to web development. I got a handful of interviews but I never felt like I was showing them what I could do... learn.
Until one finally gave me a fairly straightforward homework style project. It was probably more apt for a noob and I threw myself into it and submitted my work and explained what it over the phone. I was in the office the next day and we talked about it and I had an offer.
The homework style interviews are understandably controversial, but at least I got to show my work, me doing my work, my thought process, outside of a few moments at a keyboard.
Re: Harder programming questions do a worse job of predicting outcomes
#218One issue I've noticed is that the elite companies are trend setters, and their interview methods are being copied by non elite players.
Perhaps Facebook needs and wants engineers that can bust out A* on the spot, but I doubt Nordstrom or Starbucks needs that level of talent.
This has changed the field where now to even get an average job at an average company you need to study at the new normal, whose interview ideas were designed to look for the top 1% of the field.
Re: Harder programming questions do a worse job of predicting outcomes
#219Earlier quoted context omitted.
The massive FAANG-types of companies receive so many millions of job applications, they championed these types of interviews to have a more objective way to filter through all the applicants. That practice has waned somewhat at the larger companies (not totally, but it's changing), but has trickled down to smaller companies.
I received a cold call from a Lyft recruiter recently for a senior machine learning position. I asked why they were reaching out to me and the recruiter mentioned that it’s an especially hard time to locate experienced machine learning candidates, they don’t have enough applicants. I said I was interested in interviewing but that I would only agree to a process that evaluates me based on my previous work history, and…
I understand takehome and whiteboard coding of course, but why not system design questions?
Re: Harder programming questions do a worse job of predicting outcomes
#220Earlier quoted context omitted.
I've worked with some folks who were decent engineers who originally didn't get offers from FANG companies because they blew the interview; they later studied their ass off on leetcode and got offers. This did not make them better engineers at all. Ultimately, its just studying for the test, very much like the ACT/SAT in high school. You can be great at taking tests but ultimately a terrible student or vice versa.
I go back and forth about how I feel about doing heavy algorithm/data-structure stuff in interviews. On the one hand, I have never once written any kind of sort algorithm or LRU cache by hand for a production system, because why would I? Pretty much every language's standard library has a fairly-optimized sort and caching thing built in, and if they don't then there's still probably a million outside libraries to do…
> On the other hand, I genuinely do feel theory is really important.
My beef with this in interviewing is that a huge chunk of modern programming work is developing UIs - and user interface theory and skills are treated like some softball thing. You ask UI-related questions to interviewers and half the time you get some shrug "oh we use whatever", etc.