Whenever I have to solve a really hard problem, I always have at least two mediocre solutions before I come up with a really good one.
That doesn't work well in interviews, especially with how terrible most interviewers at time management. I sometimes get 10 minutes for a system design problem because the interviewer was expected to get signals on my non-technical competencies as well as system design.
This is never enough time to ask clarifying questions, diagram things, and get a good solution out unless it's similar to a problem I've already solved.
It's often OK to not solve the problem as long as you give an interviewer insight into how you think, but some interviewers expect a miracle.
> It's often OK to not solve the problem as long as you give an interviewer insight into how you think
It's not, though. Many people have no clue how to interview well, and way too many tech interviewers are obsessed with whether or not the candidate got the "right" answer.
Anyone who dropped multiple mediocre solutions before a good one in an interview with me would likely get a strong hire — I love to see this kind of iterative thinking, and finding people who can role model a healthy exchange of rough-draft ideas is always a great boon for the team's psychological safety (and by extension, their creativity and productivity).
But I think, industry-wide, it's not great. As a SWAG, probably ~50% of interviewers are more interested in the correctness of the answer rather than the caliber of the thought process and communication.
>As a SWAG, probably ~50% of interviewers are more interested in the correctness of the answer rather than the caliber of the thought process and communication.
And this is why most the interview processes as practiced today are a joke. It's far more this weird sort of cargo-cult hazing process than any actual sort of reasonable assessment. Few people give challenging problems that they expect won't get solved to step through thought processes, they have some predisposed ideal solution or perhaps probably optimal algorithmic solution on the spot. That lends itself well to a combination of assessing rote memorization and chance, I suppose.
> It's far more this weird sort of cargo-cult hazing process than any actual sort of reasonable assessment
This is 100% what it is. A "We went through it so you do too." sort of thing, combined with the fact that management can't interview everyone and SWE's aren't good at reading people to determine if they're lying.
I have a friend who's a manager at a FAANG and while there's a lot of good, smart people there, there are many, many people who are terrible at what they do and are very difficult to deal with.
My company does not do whiteboarding and makes an effort to get to know the person. We rarely get bad hires. Maybe 1 out of 100? Give me 10 to 20 minutes just to talk to someone and I'll tell you if they'll be a good employee. One of the first things I do is assess if they're lying on their resume. If they're not, then I'm comfortable believing in their skill set.
I've said before to other technical folks that the interview process in tech is more a measure of ability to handle anxiety and stress than whether one can solve problems competently and gracefully. Granted, in my current role I make it clear to candidates that they may have to perform under pressure at 2 am when there's an outage possibly due to their code or even others' and many people are relying upon you in particular for guidance. I also make it clear that we do a LOT of things to keep such a skill from being required but no process is perfect so being able to handle such a situation without panicking is an important factor in the hiring criteria because each of those situations I can count have been very important and high impact (it's part of why they're so stressful, right?).
Every other practice we have in our interview process is justified based upon historical precedent as well as a team decision for where the team wants to go next.
To effectively fix an emergency situation like an outage, you have people extremely familiar with most/all aspects of your systems walking through a checklist of checks, verifications and tests to identify the root cause of the issue and then go to work on that. The point is that people are "under pressure," sure, but they are extremely comfortable and familiar with the domain. They already know what is supposed to work or what the expected results are to certain basic tests, and that familiarity and knowledge is what maintains a level head and prevents someone from panicking.
This is pretty much the opposite in an interview situation, even when it's a subject people know well, there's way too much "unknown" about your particular setup that the interview doesn't/can't know.
The test has a number of fairly loose factors that are explained to the candidate as more about approach and communication than a “correct” answer (although don’t keep sitting and wallowing about a particular problem like the Python GIL for what is meant to be about exploration together). 1. Many outages are due to systems not even known to us to even exist for a team, so being able to determine when one knows something v. does not is a skill in the sense of knowing when to stop wasting time and to escalate and when to keep trying to troubleshoot their responsible areas - response time isn’t the KPI in an interview and never should be. Part of why I ask this is to determine if a candidate will give up really, really easily and just escalate saying “this isn’t my problem” - this isn’t acceptable, has happened to us all at previous companies, and is basically one criteria for failure / dismissal. A more constructive attitude and approach is “I have done a lot of evaluation including A, B, C, D and do not have anything else in mind, I would appreciate another set of eyes” - that is basically all we can reasonably expect in an interview situation and of course nobody knows anything about a company’s systems as a new hire. There is usually no expected canonical answer as well which would bias interviewers for a “correct” solution or even approach.
2. I usually ask candidates questions and scenarios based upon their submitted code samples and will presume an OS or cloud provider they’ve listed as something they’re familiar with on their resume. If you have lied for any reason it will be very obvious very fast as I keep adapting the question to a narrower and narrower scope to being a purely toy problem that is now useless for measuring anything beyond whether they’ve seen the problem before. Usually we can spot some errors in code samples submitted and make it clear to candidates that we do not expect perfect or necessarily even working code! The test isn’t about necessarily being bug free but about the attitude one has about their work output and how they’ve thought about various failure modes. I’ve had candidates surprisingly often say “that can’t happen, I made sure of it in my test cases” and then I show with a quick test run I think of that their submitted code does indeed have some flaws that would have had issues in production causing, say, OOM issues, segfaults, etc. A successful candidate’s attitude is accepting / welcoming of criticism as a team effort, has strong but loosely held opinions when encountering data contradicting their position appropriately, and is able to accept a challenge from junior engineer with respect and sincerity. Red flags = arguing with the interviewer for asking an admittedly irrelevant question, getting very defensive about a technical decision, and saying adamantly “this should have been caught in a code review so it’s not relevant” and being dismissive about the question. Yes, I’ve seen all these responses before. Nowhere in this process does “is expert at X” enter the picture, and we are usually evaluating the quality of the questions asked by the candidate as well. Many of us on the team have respectfully asked the relevance and presumptions of a question and that’s a big plus IMO - they have courage, respect, and critical thinking skills under pressure. I make sure to tell them that during the interview because people are so used to taking orders and shutting up that it’s bad for the organization.
Another set of red flags I’ve seen is “I’ve never had to do X, it’s taken care of by Y” and being unable to reason or even conjecture about how Y could be designed and reassured it’s not about correctness when it’s on their resume. Like I had someone that was pretty clearly a competent, skilled programmer but was applying to be an SRE and didn’t know how to work on a system below the container level with any tools proprietary or OSS - they were recommended to a different team but not for the applied position.
I assure you that everyone I’ve interviewed for years now has said they’ve had a great experience in all the follow-ups with recruiters, felt that the interview was a technical conversation rather than a hazing / torture test, and that nobody felt the questions were not relevant to the job once hired. I’m not an asshole as an interviewer trying to push people to some limit or something that seems to be the result of most technical interviews in our industry.
Here's a data point: anxiety from the interview (you depend on unfamiliar people judging you) is different from troubleshooting a technical incident (it is more on the exciting side).
There are certainly unfamiliar people judging me and my coworkers when there’s an outage involving customers of various levels, yes. And in a previous company sadly yes we have had people let go for poorly handling incidents that resulted in lost business. It’s a lot of SRE in the ugly side
Obviously, there can be many people who are affected by a technical incident. It may be wise to delegate handling upset customers and fixing a hard technical problem to different people.
Blaming people is a sure sign of broken processes.
Interviewees being able to instantly produce the right answer made me think of another problem Interviewers need to account for currently: people who are biding their time until the market heats up again.
There are definitely engineers hunting max salary/equity over everything and they are going to jump ship if they can get a FAANG role. Being able to spit out rote memorized leetcode and systems design questions is probably correlated with someone who wants to maximize their salary.
A few years back I failed an interview because I gave the impression that I didn't know much about full stack web dev. (To be entirely fair, I didn't at the time).
I was a little irritated though because, though I was early in my career, I have no doubt that I'd have been a productive member of their team within a month. I had thought the interview went well - we discussed the problem they proposed in detail, we arrived at a reasonable solution by the end, I asked lots of questions and responded well when I was prompted about edge cases.
I was just fuzzy on implementation details and aspects of database design that I hadn't had direct experience with.
Anyway, I'm not bitter, not getting that job led to a fantastic gig that I still have today. But I did feel like they were focused on the wrong things in the interview.
> A few years back I failed an interview because I gave the impression that I didn't know much about full stack web dev. (To be entirely fair, I didn't at the time).
> I have no doubt that I'd have been a productive member of their team within a month.
Did you consider that they might have skipped you not because you were "fuzzy on implementation details" but because you projected that vibe "I don't know much about what you do but I bet I can be ask good as you at it in a month"?
I don't think I projected that vibe. I knew ahead of time that the architecture interview was going to be the hardest part for me, and made an effort to show that while I had gaps in my knowledge, I wasn't going to be afraid to ask questions and have discussions to make it possible to get work done. I have a bit of an aversion to unearned overconfidence so I like to think that I did not project that in the interview, but obviously I can't experience myself from the interviewers perspective.
When I interview junior candidates, attitude, interest, and capacity for learning are more important to me than specific knowledge.
Anyway though, it was their choice, and I clearly didn't demonstrate what they wanted to see. Not getting that job left me in the right place at the right time for a job that I really love, so... ¯ \ _ ( ツ ) _ / ¯
I look back at myself and the kind of cringe responses (and questions!) I had earlier in my career and for the most part the interviewers were right to reject me but not necessarily on the basis of technical merit (or lack thereof). On a lot of teams being able to communicate effectively and develop a strong rapport quickly is a bigger factor for an individual's effectiveness than how much quality code and designs can be produced. Ironically, this is an even bigger requirement for smaller organizations. For example, see a pathological case a start-up of two people where they must both be _very_ good at working together or the entire company will fall apart quite quickly. Also in a lot of interviews I was unable to demonstrate that I'm competent partly because I had already burned way out from months of being on-call and losing a great deal of sleep, so I was walking into interviews at basically my worst possible performance. It took me quitting for a while, working on my own terms, and recovering slowly to be able to demonstrate what everyone saw when I was actually operating at my general level of competence in various dimensions. Additionally, got some professional help and with some clinical diagnoses under my belt with solid medications everything got substantially better after that. Going through basically an entire career with severe handicaps has made everything seem much, much easier to handle.
It's ironic that the dynamics of targeting higher quality candidates are not that different from personal dating. While for larger organizations they seem to stress how much more damage a bad hire can be they have the capacity to absorb losses better than substantially smaller organizations on a purely mathematical basis. Likewise, individuals that have higher resources, emotional intelligence, capacity for grace, etc. can much better tolerate "bad" relationships yet are among the most stringent at avoiding "bad" relationships in the first place.
I came up with the term myself which is why you can't find it but I also half expected someone to have named it as well. Because "manners" or "nice" is a mostly culturally-loaded or very subjective term I wanted to say "be considerate to others above how even one would want to be treated." And it's a word not used daily except among the religious in the West, and that works well for those groups because "act how you would in church / template / mosque / synagogue" as a reminder of what civility can look like. Granted, some churches in the US are truly frightening to me and maybe I should refrain from calling on such emotions.
One of my more embarrassing interviews was early in my career, after I'd be developing HFT trading systems. I'd never worked on a web app in my life, and was asked the difference between 4xx and 5xx codes. I had no idea. Something I could have googled in about 10 seconds was the pass/fail criteria for an interview.
It is particularly galling when the interviewer either assumes it is an easy question now that they know the answer (especially if they did not figure it out themselves), or does not understand the subtleties that a more perceptive person realizes must be dealt with before reaching a justifiable answer.
Can you elaborate on "and finding people who can role model a healthy exchange of rough-draft ideas is always a great boon for the team's psychological safety"? Would the opposite of this be flushing the idea maximally (and taking longer) before presenting it to the team?
Yes, exactly. You want people to be able to say things like, "Hey, here's a crazy idea..." or "What if we..." without having to worry that they'll be torn apart instantly.
According to Jony Ive, Steve Jobs was exceptional at nurturing this kind of creative environment. He describes it perfectly in this WSJ article [1] from a couple years ago:
> As thoughts grew into ideas, however tentative, however fragile, he recognized that this was hallowed ground. He had such a deep understanding and reverence for the creative process. He understood creating should be afforded rare respect—not only when the ideas were good or the circumstances convenient.
> Ideas are fragile. If they were resolved, they would not be ideas, they would be products. It takes determined effort not to be consumed by the problems of a new idea. Problems are easy to articulate and understand, and they take the oxygen. Steve focused on the actual ideas, however partial and unlikely.
The other part of it is that ideas, as fragile as they are, can blossom and transform if you can get multiple people and multiple different perspectives involved in the early stages. That's why it's so powerful to have this kind of culture on a team; it lifts everyone up.
The problem with polishing the idea into a final draft before sharing it is that — whether or not it's good — it's almost guaranteed to not be as good as it could have been. And, by the time the "final draft" is ready, it's too late to get involved — all the interesting rabbit holes and tangents and possibilities have already been pruned away.
Not the OP but I would say: yes exactly. A culture where you only see team members presenting ideas in their done state leads to overall worse solutions because people aren't collaborating & giving each other feedback on ideas-in-progress.
“psychological safety” is a newish buzz term that is basically an excuse for people who can’t handle criticism or debate, which I am seeing as increasingly common among younger devs. It is and should always be ok to freely exchange ideas without fear of being wrong, because everyone can be wrong. Even Einstein was occasionally wrong.
Your comment is a good example of a lack of psychological safety - you shoot the concept down with an intellectually dishonest argument, effectively ridiculing the idea.
The problem you describe is the part that is directly addressed by psychological safety. If you can provide a wrong answer and have people critique it but without ridicule, then you have a “safe” environment where people are comfortable to provide solutions without certainty on their optimality.
It's the exact opposite. A team with strong psychological safety is exactly the type of group that knows how to present critique and debate, even between junior, senior, and management participants.
The point is that participants feel safe challenging an idea.
> It's not, though. Many people have no clue how to interview well, and way too many tech interviewers are obsessed with whether or not the candidate got the "right" answer.
On the other hand, many interviewers are just normal people who have no idea how to gauge "how the candidate thinks", but like to think they are. I saw this a lot in the heyday of Google's brainteaser type questions. (And middle managers seem to revel in it.)
So the right answer is as good a proxy as they can hope for. It still sucks, but there you go.
The best interviewer I've had when applying to a company made it very conversational. It wasn't "solve this problem on a white board". It was how would you go about designing an application like Twitter that had to serve XXX millions of requests per day. I was just coming out of the (small) startup world and hadn't had to explicitly design for this sort of scale yet. But as I started talking about it, he asked questions which exposed some of the issues in my initial approach so I pivoted and addressed them. He wasn't looking for a fully formed solution directly out of my head, but was trying to figure out how I thought about and approached problems. The way he went about it was also very low pressure and felt like something you might be spitballing with a coworker over drinks. I try my best to emulate him when I'm in a hiring position.
That’s roughly how I’ve been doing it. The problems presented are always the same and there’s a set of clarifying questions written down for various options the candidate might offer. Only enough structure to keep it somewhat consistent.
I always say "Let's do the obvious thing first and we can discuss improvements?" and the interviewer always says "Sounds good" and there's never time to discuss improvements.
I often think it's a lot better to do an overall interview over a full day than to do disjointed rounds of 4-5 interviews over a few months.
Some advantages
- Interviewer and the interviewee are at ease. There is no rush to solve a problem.
- You can easily spend 90 minutes to 2 hours on System design, Spend 2-3 hours coding and another 2 hours in behaviour/leadership what not.
- The interviews can be progressive, meaning you don't make it through the first 2 hours - good bye.
- This can be done remotely as well as in person. Of course, in person would be better, hosting expenses etc.
End of the day, decision is made and you can verbally convey an offer/reject.
This calls for a lot of discipline and commitment from the companies and their interview panel, I mean so be it. Dedicate 1 month for hiring and be done, at least for senior positions. Just like you allocate time for your projects, allocate dedicated time for interviewing every 6 months, every quarter whatever.
Wait how do you think hiring is done right now? What do you mean “dedicate a month to hiring”? Once you are senior enough at a company you end up having to interview multiple people a week, plus all the other meetings, scheduling a full day interview, where someone can actually hang out with you for 2 hours is going to require advance notice. And not many candidates want to wait for a month+ for their interviews.
This is crazy for me to read. We hire senior engineers based on a single hour long group interview. I've never participated in an interview (either as an interviewer or interviewee) that has gone on for more than a single hour. We will interview about 5 candidates over a week's time and then offer the position to one of them (or keep looking if none are suitable).
Same here - You can tell immediately within 10-15 minutes if a person has "the right stuff". Anything above that is just you sucking tiny milliliters of juice out of a carrot hoping that "maybe" they'll work out and you can get "some" productivity out of them down the line or "maybe" they're secretly a really good developer.
Either that, or the amount of time you subject potential hires is just a "signal" of your power and a filter for the needy, desperate and intellectually invested. I guess some companies are looking for that.
> You can tell immediately within 10-15 minutes if a person has "the right stuff"
I do a lot of interviewing for our company, and I used to think this too. But I've been totally wrong a few times. Sometimes someone I've been 100% sure about has been let go after a few months, while some I've been very iffy about have turned out to be excellent coworkers.
I used to be in restaurant management and I recently got a job in entry level IT for the first time in 15+ years for work/life balance.
The best 2-3 hires I ever made as a restaurant manager I knew they would be great within minutes of starting the interview. Other than those outliers I would say a great hiring manager was about twice as likely to have a productive hire as a bad hiring manager. Great hiring managers were batting around 0.600, almost regardless of if it were a relatively “technical” position or not. At some level it was just a crapshoot.
Yup, the danger of the suss them out in 10 mins, is you won’t get diversity (I don’t mean race and all that bandwagon), you’ll miss some exceptional outliers imho.
Not necessarily, chemistry is such a big part of the selection aswell, you might have the criteria's for working somewhere, but do you also fit with culture? Many i have worked with would much prefer a person with less criteria and better culture fit, since with good fit you can easily learn the person what they need, and regardless of codebases most people will need some sort of onboarding for a new position anyway, good culture fit makes this transition much faster.
I would filter out the ones that have the criterias, and then see how they fit with current culture rather than roasting them with tests.
Well, I participated in one interview that took longer than an hour. It was supposed to be "an initial interview". With another to follow in a week or so.
It turned into: "an initial interview; meet potential future co-workers and manager; have them see me do some actual work they do; meet the company owner(as he happened to be there);meet the accounting person and haggle over proposed pay; meet the HR person and haggle over minor changes in the employment contract;finally sign the contract" all in about ~7h. Coming in I was expecting to spend an hour there, but I was pleased with the outcome. I spent 6 years working there leaving only because of a move to another city.
It all depends on how many applicants you get. If you're as big as Google and everyone and their grandmother applies, you can afford to have longer interview rounds for positions where you need to be thorough. Otherwise you spend more effort in bringing people to the interview.
We are a Fortune 100 company that everyone on the planet has heard of. We typically get 500+ applications per position. But we still only do a single hour interview to make a decision.
With remote interviews it’s at least common to see a ‘round’ scattered over multiple days and time slots, rather than a single visit with multiple interviewers in a row.
Paying for someone’s time is… tricky. If a company doesn’t pay, and the candidate is willing to do the interviews, it is a signal that both are expecting positive financial outcomes overall (ie both sides foresee fit).
The moment you start paying for people to interview, that signal gets weaker. Likely compensated by stricter resume filters. Its a disadvantage for people with uncommon profiles or less experience. (And an advantage for those that have more experience and some big names on their CV)
Opposite IME. Interviews go both ways. Senior people will be pickier while the more desperate and junior are the ones who will accept an offer from a company without properly assessing what they're entering.
You want to attract candidates that have a high probability of being hired.
If vJ is the perceived value of getting the job, pJ the perceived probability of getting the job, vI the value of the literal payment for going through the interview process, and vT the perceived value of one's time (and any other cost if it exists, such as travel) required to go through the process, we can represent the expected value of going through the interview process as:
EV = pJ * vJ + vI - vT
If we assume vJ >> vI and vJ >> vT (which I think is reasonable if you want the job), we can observe that the importance of vI and vT mostly depends on pJ.
I also assume that the candidate would choose where and whether to apply based on EV for their various options.
One one end, if your pJ is close to 1 (you're highly qualified for the job and will likely get it), the result is dominated by pJ * vJ which is ~= vJ; vI and vT matter little. This means that if you will probably get the job, it doesn't really matter much whether the interview is paid (and it also doesn't matter as much how much time it takes). For top candidates, the difference in pJ * vJ for different companies should be the dominant factor, i.e. they will apply for the best jobs.
On the other end, if your pJ is close to 0 (you're applying on a long shot), then vI and vT become much more significant factors. If your chance to get the job is really low, then the interview being paid makes it significantly more attractive, and it also matters more how much time it takes. The companies that pay for interviews, and companies that are easy to apply and interview for are likely the ones with the highest EV for the poorer candidates.
Basically the worse of a candidate you are for the job, the more important it is for the interview to be paid, because with a low enough probability of getting the job, this payment becomes a big factor in the expected value of doing the interview.
Of course it's not as simple as that, because people are not machines chasing pure financial interest and have feelings about how you treat them. Also, a highly qualified candidate is more likely to have a job that is closer to the one they're applying for, while an unqualified candidate might have a much worse job, making vJ higher for the less qualified candidate. But it is likely that the relative difference in pJ is much greater between a qualified and unqualified candidate than the relative difference in vJ. The candidate's own perception of the probability of being hired (pJ) might also be unrealistic in either direction, and I'm assuming it is a good predictor of the true probability of being hired. But I think in general the rule should hold, paid interviews would decrease the quality of the candidate pool.
Why do you expect employers would pay you? I mean, what if you don't pass it, or even worse, what if the company offers you a job that you decline near the end? Where would the money go?
Receiving a salary is not the thing you can expect when you're not doing the work... I mean cmon.. Plus the real salaries upon landing the job will be the top of the crop, so, I think expecting payment for interviewing is... Quite the entitlement.
I mean, would you pay money to a handyman if he'd show up near your roof and showed you how he uses his tools and how he WILL EVENTUALLY work, but, not really fixing it?
It's not uncommon for tradespersons to charge to come out and quote.
Having said that, I think paying people to interview for 6-figure salary jobs (AUD) is a non-starter to me. If a company is stretching your interviews out to the extent it's a waste of time, that's a signal that it's not a place you want to work.
> would you pay money to a handyman if he'd show up near your roof and showed you how he uses his tools and how he WILL EVENTUALLY work, but, not really fixing it?
If that was my idea not the handyman’s? Yes. I would expect them to charge for their time.
It's the interviewee's decision to attend, or not.
I don't think many handymen offered a chance for a two year, full-time building gig would say "sure, wire me $100 for the consultation and I'll come over", and if they did they'd be smart enough to realise they were politely turning down the job.
Frankly, "too preoccupied with the idea of getting paid for a single day of producing no output to take into account the potential to earn $xx,xxx more over the course of the year", sounds like an excellent way for employers to filter out candidates who have low interest in or confidence of getting the job or poor decision-making ability...
I think this hits the nail in the head for the argument I was trying to make: if you as a candidate feel the process is too long or daunting for you, you don't have to attend. It's that simple. Why would you expect compensation if people will do it for free or because they just want to take a shot at the job? To me it truly feels like entitlement... And of course the vast majority of us, myself included, can apply to "lesser known" companies, be done with interviews in a couple of days and it'll all also be good... Obviously compensation will come according to the effort... Demanding money for providing just a signal is useless
The company wants a day of your life, jumping through hoops to please them, providing “signal” for them, competing for the chance of them abusing you to extract value from you, and they want it for free.
Yes, entitlement is possibly a good description there. It’s far too one-sided. If they had to pay they’d suddenly find ways to get “signal” much more efficiently and effectively.
If a candidate assumes the hiring team is “competing to abuse them”, I’m happy with more or less anything that filters out people with that attitude.
Entitlement cuts both ways. Software development pays very well and largely has excellent working conditions, it’s basically a golden ticket. I know people who are essentially stuck in minimum or low wage jobs for life.
And if you say "I'm entitled to a job in software development without showing any skill or putting in any effort" then you sound entitled. If you say "I need to spend a day doing work things on a company's terms for a potential deal which would benefit the company a lot, and I want to be paid for my time and effort" that's ... not entitlement.
Don't for a moment miss that if "software development pays very well" then it pays the company even more than it pays you. Being employed by them is a win for the company they're not giving you free handouts, they should be willing to spend money to make money.
Entitlement doesn't "cut both ways", it's a mostly meaningless conversation stopping dismissive insult, but as far as power imbalances go one side is a company with millions of dollars and lawyers on hand or on retainer. If it's a big FAANG they likely union bust or block which is against employees interests, they possibly have stack ranking or other methods to divide and conquer employees by pitting them against each other, possibly has 'unlimited' vacation time which excuses them from rollover or payout for untaken vacation and maybe they don't approve vacation because everyone is always busy. Often they will be lobbying politicians to increase their power and decrease employee's power. Healthcare is tied to employment, which is in the company's interest and against the employee's interest because it makes leaving harder for the employee but does not affect firing or redundancy for the employer.
On the other hand you have a single lone human.
The employer also wants loyalty, often ownership of anything the employee creates on their own time while employed, often an NDR, and control over what the employee wears and says and the times they work.
And they want long days of interviews, often with terrible interview practises which don't give them good data (much discussed on HN year after year) - and they expect this effort and time which is ultimately for their benefit, for free.
I’m sympathetic to your points and have heard all the horror stories about FAANG hiring practices, but again: if you don’t want to go through the interview process, go for an ordinary job that doesn’t pay through the nose. Sure, they have stack ranking, but they also deliver compensation packages that essentially guarantee a wealthy, comfortable lifestyle.
Most tech jobs are not in FAANG.
> If you say "I need to spend a day doing work things on a company's terms for a potential deal which would benefit the company a lot, and I want to be paid for my time and effort" that's ... not entitlement.
I frankly don’t find it plausible that the work being done in a day or two during the interview process is valuable labor. Who is going to deploy that code and make it production ready? How would you even organise and plan that work? Is an engineer opening a PR internally with the interview code or something?
> Healthcare is tied to employment, which is in the company's interest and against the employee's interest because it makes leaving harder for the employee but does not affect firing or redundancy for the employer.
Fair. I live in a country with a public healthcare system so this doesn’t factor in for me.
> "I frankly don’t find it plausible that the work being done in a day or two during the interview process is valuable labor."
It's the hiring of an employee who will make wealth for the company over their employment period which is the financial benefit, not the work done on the day. But the work done on the day is still value - it's signals of the quality of the candidate which is something the company wants (and therefore values, and therefore should buy). Second, if someone arranges for your time and tells you to do some task they choose, they don't then get to say 'I can't get value from your work so I'm not going to pay you'", that's not how things work.
> "they also deliver compensation packages that essentially guarantee a wealthy, comfortable lifestyle."
And what about the people who spent a day on the interview and did not get hired? The company gets time, effort, signal information which benefits the company ("no hire" has value too), and the candidate gets their time and effort wasted. Imagine if you had two contractors do a task you set, then turned to one and said "I'm not using your work so I'm not paying for it", how well would that go down? "Fuck you, pay me"[1] I expect. It's not like going to a shop and not buying some things, it's like asking the shops to deliver things to you and then refusing to pay for delivery on things you don't buy because the shop had a chance of getting your business so they should be grateful. (Worse if the company is constantly interviewing just to keep the pipelines warm, without any interest in actively hiring anyone right now).
No but I also certainly won't expect the handyman to spend a day unpaid at my house talking trade before I decide if I really want their services or not.
However, if a for-profit company wanted me to spend essentially a full day of my time off work so that I can go and interview to make them more money than they'd be paying me - yeah that doesn't sound right at all unless you're straight out of school.
I know what you're saying with your handyman argument but that is a false equivalency.
I've had an interview in February, one in March, two in April, and will have one in June, all with the same company. Unpaid, of course. I also think it's insane, but when you're just graduated and unemployed, what else can you do?
Pretty much all my interviews except in Meta. This is in India though.
Meta was the most organized but even that interview went over 2 weeks.
My Walmart interview lasted 2+ months. Round1 week1, round 2 week 3 etc etc.
This is for Staff+ level positions.
EDIT: Just to state, companies do give enough time to prepare for the interview. I am only talking about the interviewing duration, not the prep time.
The culture is so different here in Australia and New Zealand.
I've done a lot of interviewing of candidates over the last 12~ years or so - here are some generalisations based on my experience and that of my peers for tech roles:
- 95% of the time it's 2-3 interviews / meetings. I have seen a single interview be enough when the person is already known to the team and the interview went well confirming and clarifying existing knowledge of the person.
- The first is usually a call with people and culture / the internal recruiter - high level intro and general culture fit. These tend to be between 15-30 minutes. You should usually know if you're being offered another interview by the end of the call - or within a few days at most and have the next (main) interview setup for the next week or two at most.
- Then if the role is for a developer / programmer or design / UX the candidate is usually sent a coding (or design) test which can be done remotely and will usually take 30-120 minutes but this obviously varies depending on the test, role, and persons abilities.
- Second is often a technical and team fit interview with two people in or working closely with the team / department you're hiring for. These are usually around 45-90 minutes. You should usually hear back about this within a day or two, and if another interview is required you would hopefully have that booked in for some time in the next week or two.
- A third is often done if the team/tech lead wasn't in a previous session - or if the interviewers can't agree or get a good feel for the candidate.
> The interviews can be progressive, meaning you don't make it through the first 2 hours - good bye.
Is that knowledge available in real time? When I interviewed at Google last year, the next thing I heard back from the recruiter was that I'd passed the interviews and should expect a job offer. She wished me congratulations. A couple weeks later, she informed me that my interview scores were too low to get a job offer. It remains unclear to me why there would be separate thresholds for "passing" and "eligible for hire".
So a lot of companies have “hiring committee” (incl google) that are required to approve a person write the job offer. The interviewers rate the candidates, and offer notes/transcripts, but don’t have the final say. The HC meets periodically, so there’s a delay between interview and offer letter.
What probably happened was that the recruiter looked at your profile, read the comments, and expected you to pass the HC (and told you the next day)… but you didn’t in the end.
Now last year Google implemented a hiring freeze, so you could have fell into that. I would believe that for easier-to-fill roles, during the hiring freeze they suddenly had a glut of candidates who “passed” with no job to give them, so the suddenly “failed” and we’re sent away.
> Now last year Google implemented a hiring freeze, so you could have fell into that.
I think this was earlier than the freeze. It was certainly earlier than any awareness of a freezing job market made it onto HN; the email from the recruiter promising to give me good news on a phone call tomorrow -- a rare example of a Google recruiter putting something in writing -- arrived on January 12 of last year. There was a very long lag between that call, described in my earlier comment and presumably taking place on Jan 13, and the followup telling me I'd been rejected on March 2. I undersold that by describing it as "a couple weeks".
On the other hand, according to my memory I was informed that I should see a job offer by the end of February - I noted at the time (to myself) that the schedule was surprisingly long - and in the light of your comment, that and the timing of my eventual rejection do tend to support the idea that the hiring committee's next scheduled meeting was at the end of February.
I have this exact issue going on. I've learned to distrust my 'instant answer'. I tend to skip this fast answer and work very slowly though the problem, and generally find the quick answer to have been wrong unless I know I have collected and absorbed a great deal of information, and slept on it for at least 1-2 nights. I have found the quicker answers to usually be correct if those prerequisites have been followed.
In "Thinking Fast and Slow", Daniel Kahnemann describes the "instant" answer as being given by "System 1", which the far slower (and more rational) "System 2" might distrust.
On the system design question, the only correct answer should be: It can take months to come up with a good system design, and even then it can be wrong because of a minor misunderstanding, a missed requirement, availability of support teams, etc. If someone came up with a system design in 10 minutes, I wouldn’t want to hire them.
Yeah, I was tripped up in an interview at Meta on system design, we had a good discussion, but on my part I didn’t realise they expected an actual solution during interview. I mean, you’d have a gist of a solution but you wouldn’t tighten the screws until you’d gone through many rounds of stakeholder discussions and requirements refinement. I was way more experienced than the chap interviewing me, it just felt all a bit contrived, playing at architecture, memorise these patterns for these x scenarios.
If someone came up with a system design in 10 minutes, I wouldn’t want to hire them.
Deep wisdom here, indeed. Don't you dare say this during an actual interview, though -- especially when you're asked to do the system design part in 10 minutes or less. The last thing these companies could possibly want is to have reality to intrude.
I can relate to the comment on interviews. When I was in school it was easy to apply what I'd learned throughout the semester to the exam questions... but in interviews, I'll be asked to solve problems that I've never dealt with, without a reference. My first instinct with any problem that's new to me is to find the state of the art, but obviously that's not possible in that case, so I'll think of a solution, then immediately doubt its optimality and rethink it... then repeat that once or twice and sometimes I'll end up with the same answer that I came up with initially, or I'll just doubt my ability and give an ambivalent or unconfident answer, especially if I feel like I'm making the interviewer wait. I'm sure I sound like an idiot to them every time I'm asked to solve a silly problem like that.
I usually go, “I’m reality I’d spend a couple of hours researching the best solution to this before starting, but seeing as I can’t d that here…”
And then proceed with my non-optimal solution. They often don’t care about optimality at all. I’ve passed interviews by implementing a bubble sort before. And I have no shame in doing so. I’ve never needed to implement a sort in an actual job, and if I did need to I would be looking up how to do it.
Yep and they get to hire people that were hinted about the answers or just went through a list of exercises of the kind. It starts to show when they have to design from scratch.
This is something I've been unable to articulate as succinctly as you have - thanks.
In the past I put it down my experienced approach and what I need from others: make it work (mediocre solutions that deliver 80% value are fine!), then make it better (reflect and refactor until readable/approachable/idiomatic) before finally (stretch goal) make it faster (break idiomatic paradigms, vectorize etc.)
Heh this just happened to me. I have to go through some loops to get a really good solution. I call it think by doing. I suck at very high level abstract things to find problems. But once I begin working on it and fleshing out details and seeing actual code that’s when my mind kicks in and finds problems and better solutions to the overall design.
Same. I always work on any given (hard enough) problem twice or three times. The first time I come up with some kind of prototype that may work or not, but it gives me foundation to work on the second prototype. The second one tells me how a final working and performant solution could look like, so I discard it and start from scratch. At the end I come up with the best possible solution I can provide.
Sometimes it takes fewer steps, sometimes more. And more often than not I let some time pass between attempts (maybe I go for a walk in between or I let a full day pass to work on something else).
This is never enough time to ask clarifying questions, diagram things, and get a good solution out unless it's similar to a problem I've already solved.
Of course not - interviews aren't about assessing actual problem-solving ability (in the face of, you know, actual real problems). But rather your ability to recite stock answers to made-up problems the interviewer found on some website somewhere. That, and your ability to politely tolerate their horrible time management skills, laugh at their jokes -- and feign belief / interest in their product.
Same way for exams, too, especially when essay writing is included. Good ideas comes in a flash, you don't know how, you don't know when. Most of the time, if you can come up with a great solution and can express it in a clear and structured way the moment you hear the problem, that just means you're familiar with the topic or it is something you've solved before.
That's why I always ask for a very simple programming task (same for each candidate), but somewhat vaguely specified, solvable in different ways. Just like on real job, lots of inputs are not needed, some are missing.
Experienced candidates give two solutions in seconds, juniors cannot figure out the task, and overqualified are visibly annoyed by being asked to come to a whiteboard.
Intelligence isn't a factor of just speed, but open-mindedness. A willingness to look at something from every angle and solve with a unique solution. This is my big gripe with the intellectual crowd - because they want to be smart solely for being smart's sake, so they'll sacrifice the due diligence it takes to correctly solve a problem in order to "get further" and appear smarter, and it misleads a lot of people on what true intelligence is.
>This is my big gripe with the intellectual crowd - because they want to be smart solely for being smart's sake so they'll sacrifice the due diligence it takes to correctly solve a problem in order to "get further" and appear smarter, and it misleads a lot of people on what true intelligence is.
That's a remarkable generalization. In reference to the article, perhaps you should have thought longer about it.
The book Disciplined Minds discusses how the more educated and professional workers are more often than not the more conservative thinkers, somewhat by virtue of having been institutionalized and thus tunnel visioned in what's a "right" answer. So the generalization is not off base and not without precedent.
Adding to that there is indeed what is called “Divergent thinking” [1], it is a way to explore thoughts in a diverse way and the ability to come up with creative solutions.
This is different from the more linear directed thoughtpatterns promoted in institutions. I often find people in the HN crowd to be more in the latter crowd than the former, but nonetheless intelligent.
When I speak to artists or people in more creative fields, I find that, typically, the conversations are more improvisational in nature. The conversation just ebbs and flows naturally, with energy and a lot of spontaneous thought building. The strange book Impro is a good read for this.
Whereas, when I speak with engineers or scientists, it feels like the conversation has a much higher chance of lurching, especially when you start to veer off the beaten path.
I consider myself to be a bit more divergent than most, but being in a technical field is a bit of an impedance mismatch. I think a component of divergent thinking is sometimes extreme thinking, wondering about what if and ignoring, for the time being, how to get there.
I hear that. I usually have the same, I studied art and all of the people I met in that sphere are different from a general crowd, and quite a contrast to the offices I later worked in as a front end dev or designer. I usually ended up with meeting like minded people from other departments rather than my own (which often was interpreted as not being loyal to any team in the department —-ack office politics, what a minefield!—-
The book impro, who is it’s writer? I see a couple of results coming up.
I'm not sure what group specifically you're referring to derisively as the "intellectual crowd." I'm guessing that this is different from the "intelligent crowd," but I certainly regard the college professors and such I know as an intellectual crowd, and they are absolutely open-minded, would take their time solving problems, and would consider other opinions.
(Not all of them, of course, but in general they are at least as intellectually-curious and open as anyone else I know.)
There is a certain type of person that clearly gets a sort of intrinsic pleasure from being correct. This leads to a lot of wasted time as this goal only serves to help one “win” in a competitive, social environment. As such, they often miss the forest for the trees.
I gather you may not know any of these types yourself but they’re certainly abundant here on HN, dismissing Dropbox as easily replicated with rsync and other such sentiments.
Sure, but I guess my point was the use of the term the "intellectual crowd" (used, as above, unironically, without scare quotes, etc).
"Intellectual" is a fine word for an intelligent person who does the kind of thinking college professors do. Indeed, Wikipedia defines one as "a person who engages in critical thinking, research, and reflection."
We similarly use the term "anti-intellectual" to refer to those in our society who choose not to engage in this kind of critical thinking.
I dislike turning it into an insult, so think we should use a different word to refer to such people.
Ironically, you’re doing exactly what the parent is describing: being pedantic to prove a point/win an argument because the OP was too hasty and forgot to append “pseudo” to his “intellectual.”
I’m certain most of us know what the parent is talking about on an intuitive, vs verbal level (i.e. the idea was communicated, even if the words used to communicate it were not 100% on point)
> There is a certain type of person that clearly gets a sort of intrinsic pleasure from being correct. This leads to a lot of wasted time as this goal only serves to help one “win” in a competitive, social environment. As such, they often miss the forest for the trees.
Yes.
> dismissing Dropbox as easily replicated with rsync
This is a strawman of the actual post. Please don't use it as an example like this.
There are also those types of people that get intrinsic pleasure from being needed and being the principle engineer of a technology and shunning and abstaining the use of anything that they aren't the primary contributor to. The types of people who sprint towards having solutions in hand without bringing anyone else along because they never intended to give up that control. These people drive me nuts and yet they are also the kind who can be very considerate of the needs of software, but they seem to not value other people's considerations. They are insular and therefore myopic.
A good example of an "intellectual crowd" are the Linux neckbeards who deride users for daring to ask how things are done and not liking the Holy And Divine Terminal(tm).
A good example of an "intelligent crowd" are the Windows wizards who will helpfully advise how something is done so the user can get on with their day.
This is a perversely negative take where you pick a team and assign negative characteristics to the opposing team to ameliorate your own frustration. You don't HAVE to use the terminal but Linux is fairly unsuitable for users who regard themselves as power users who are simultaneously are apt to shy away from terminal usage or text files. You should probably stop being angry and the people who told you this. They probably aren't reading your words here.
as someone that loves linux for a server and only uses terminals on them nowadays, wishes it was better as a desktop machine, really dislikes windows for most things outside of games(even though they have gotten better at their terminal game with wsl2)... mac is great for a lot of power user things. way more configurable than windows while being a first class citizen in the gui world. the power of the message passing system of cocoa is really not matched in windows or linux. it's a sweet spot in gui computing imo
I'm a Windows wizard and couldn't care less about Linux neckbeards, I already tried to make Linux a part of my arsenal only to meet repeated failures. Linux isn't suited for me, and probably most users at that, and that's fine.
That doesn't mean I won't take easy potshots when the occasion arises, though. If they (Linux neckbeards) don't like it, they can work on improving their act and reputation.
As a hater of all three mainstream operating systems, I can say you've managed to upgrade my opinion of linux neckbeards, and downgrade my opinion of windows neckbeards all in one post. Incredible work.
The "thought time" required to actually get to the root cause of an issue can be rare due to both internal and external pressures, some of which are real and some only perceived.
I'm 6 months into my current role and only just starting to feel the confidence and comfort to question the approaches to problems we've dealt with in that time, in order to, hopefully, modify the approaches we take in future in the hopes of improving the quality of the output.
It takes time to "find the water level" and also working through applying that knowledge to each problem, and if time is 'pressurised' it can lead to suboptimal resolutions. On the flipside, no one will wait forever - and it feels as if the world is currently oversensitive to waiting time.
It never ceases to amaze me to see how often what is necessary becomes a necessary evil.
Dialogue is a necessity for the correct development of knowledge. To engage in dialogue we have recourse to language and a vocabulary of discourse. As knowledge is gained, dialogues branch off and specialize. The system of thought inherent to the ~unique arrangement of the elements of these dialogues partition thought into acceptable (an opening) and unthinkable (a closing).
Throughout history you will find minds that navigated these intellectual currents by stepping away from their dominant belief system and gaining knowledge of the universality of meaning, and saw hidden (filtered) vistas previously unseen, and then step back into their home grounds to contribute to the development of the field, in a positive manner, adding new elements into vocabulary of the dialogue. They extend it, and create the possibility of synthesis in the future.
Equally, you will find that the further necessity of establishing schools, cults, churches, and institutions, which lend social prestige to its members and satellites, introduce incentives contrary to that of pure love of knowledge, and this attracts a certain type of people, beyond the already present danger of vanity and self regard.
What is to be done about it?
Helpfully suggest that tolerance of this necessary evil may be the remedy for your gripe.
There is almost no greater pleasure than having a very difficult problem to solve, or systems to design, then going to do something enjoyable like having a beautiful sleep, swim, or hike and then letting the answer come to you.
There is almost nothing to be done but just wait patiently.
The problem is this type of intelligence is hard to define or quantify. Its like asking the question " what is art and what is not art".
Data driven hiring practices require hard definitions. One of these hard definition of intelligence is IQ. IQ is very correlated with job success and also various other skill sets related to job success.
From the company perspective, successful hiring using a data driven scientific approach is the right call simply because its the best metric we have on intelligence.
Obviously their are aspects to intelligence that currently aren't quantified but is it wise for a company to bet their future on gut feelings that are subject to bias and aspects of intelligence not in the realm of science?
Unfortunately no.
I'm pretty sure the Google interview process is somewhat of a data driven process but I can't be sure. Are any googlers in the know? Are specific interview question and answer pairs measured and correlated with the success of the employee? Or is it all qualitative judgement?
IQ, I believe, is actually not legal to measure for an occupation. But we know that this is the metric that faangs are actually attempting to replicate.
This is quite true. It's awful to have a person on a team that produces code at an quadruple industrial speed. Then the part of the team that actually cares about the project will have to sort that out later (or, worse, live with it and pay the debt with accumulating interest).
Maintaining/fixing/managing the code that the star developer produces is very ungrateful work.
That's a binary take if I've ever heard one. The quadruple speed also means products hit the test groups sooner and one can iterate on it faster. Nothing in the story implies the 'star developer' is done once the code hits production, but that's the assumption made. Meanwhile, the 'part of the team that actually cares' may as well be paralyzing themselves through overanalyzing what-ifs without gathering enough information, with the most extreme cases bike-shedding weeks worth of development time.
Surely a group of people who deem themselves 'intelligent' can broaden their perspectives a little?
When it takes 3-6 months to unfuck someone’s caffeine-fueled, no-sleep weekend bender that got squeezed in under the radar, the value that person is adding to the team and the company is quite questionable.
And no, I am not exaggerating
the time needed to fix. The weekend bender, maybe. Average case is started on a weekend and in production two weeks later. The code did not improve over those two weeks.
I’ve dealt with this half a dozen times (maybe more) in my career. Enough that I want to struggle the next “rockstar” that shows up in Slack. They generate problems and support issues faster than a room full of monkeys on typewriters.
I get even more cranky when they decide to use the opportunity to learn Go or Haskell, a programming language no one else on the team knows. And of course they fuck it up because they haven’t used a statically-compiled, strongly-typed (or functional) language before.
I’m generally a careful programmer, but I can definitely write fast and cut corners if necessary. The difference is I know what corners to cut and how to document them.
It might take me 3 weeks instead of 2, but the reduced support cost is far worth the extra week of development.
Read my other comment, as your story is a far-too-often-used extreme used by the other extreme party to justify bizarre situations. For every one of those anecdotes is another anecdote of a team of seniors/architects pissing away half the development time only to come with an inadequate solution at the end of it. Guess what, it leads to the same 3-6 months of 'unfucking' with said feature now having to be juggled in prod, where it could have taken half a day of user-testing in a safe environment. When both extremes lead to the same problem, the anecdotes of 'how going fast destroyed my mental sanity' are not an excuse to endlessly bash the other extreme.
The key problem is always the same. The business wants to move as fast as possible, and developers are extremely concentrated in either the overly defensive "let us discuss ad nauseam" camp or the willing/passive "let's develop something and deliver it" camp. I don't agree with either, but frankly, I've had far more trouble convincing the former of their problem (analysis paralysis and wasting time) than the latter of theirs, and the former group is extremely convinced they have the high ground over the latter.
>I’ve dealt with this half a dozen times (maybe more) in my career.
And I've dealt with 'seniors' willingly sitting in meetings not achieving anything and pushing silly refactors more than half a dozen times only to run into performance issues, bugs and terrible deployments. User complaints don't lie, the grass ain't greener on the other side.
> hit the test groups sooner and one can iterate on it faster.
No, as far as the star dev goes, he's done with the project and has moved onto the next one. He's far to valuable to the company to be fixing bugs. The buggy code is already in production because he promised it was done.
The fact that others have to fix the problems implies that the star dev is done.
I wrote about a specific problem, not a generalization that all fast phased development is bad. Also, nothing in my story implies that I'm justifying overanalysing.
I've seen cases that if code is not ready by Monday then the company goes bust. The code is shipped riddled with bugs. Totally justified in that case.
That's not an excuse when the same thing happens the other way around:
"Let's have discussions until 2 weeks before the deadline for something that needs 2 weeks of development time!"
"..wait, why are we having performance issues? Why did we not think of this one case that's occurring every 5 seconds?"
People are very eager to take article's example and use it to slam individuals they have a vendetta against, while looking away from the other extreme which has the exact same problem. Going too fast is a problem. So is going too slow and LARPing as a clairvoyant, getting close to a deadline and then business forces you to get disciplined and deliver something not battle-tested.
The more experience I have had the more it seems like people won't know ahead of time what has to be done. So if there's a lot of planning involved without getting the thing to customers, there's whole a lot of speculation where 90% of the planning gets completely turned on its head anyway, when finally actual customers are able to use the thing.
And then slow builds and decisions would have to be rewritten anyway. Usually with many assumptions baked in.
So I highly prefer fast iteration where you get at least something out for the customers to use as soon as possible.
From article: "Participants were asked to identify logical rules in a series of patterns"
The more intelligent you are, the more different rules you can come up with for a pattern. It then becomes a task of figuring out which rule the interviewer thinks is the (only) correct one.
Magnus Carlsen does not move his pieces faster than bad chess players. He thinks thru more creative options and see more useful "edge cases" than the bad players.
You could easily reply that "dealing with technical debt" rather than learning about the existing code base is "jumping the conclusions," the conclusion being a rewrite.
A lot of this thread is this sort of thinking, that the comment author is the bright one and everyone else is a dunce.
A product often evolves from something with a very small use-case to something very large. Developers are often critical because they dont consider the resource and time constraints in which a product was originally developed with.
> Intelligent Brains Take Longer to Solve Difficult Problems
I find such summary ambiguous. Difficult for who? Isn't it very common that a difficult problem for me is a piece of cake for thee, like the PDE that Bezos couldn't solve for hours yet his classmate could solve in a matter of seconds?
In 1697 Jean Bernoulli challenged the mathematicians and scientists in Europe to solve the brachistochrone problem. Bernoulli was particularly proud of his solution after working on it for weeks. Yet Newton, who was 55 years old at that time and hadn't worked on science or math for years, worked out a brilliant solution overnight and submitted the solution anonymously. Reading the solution, Bernoulli famously said "I I recognize the lion by his paw". Not only did Newton solve the problem, he also invented the Calculus of Variations.
> I find such summary ambiguous. Difficult for who?
What is "solve"? The example given was finding a route on a map. Is any route a valid solution, or only the best one? Does the time differ for finding a route of the same quality, or does it differ only for how long it takes until the brain is satisfied with the solution?
This is an issue for clever people on the LSAT, where there is a technique to solving the problems that takes practice, and when you do a course on it, the thing STEM people tend to have to unlearn is solving the problem as a class of problem instead of just recognizing which question form it is and grinding through it fastest. The other trick is to recognize which ones are designed as a time suck. When I saw my first set of logical reasoning practice questions I thought, "ah, a state machine," while the other students had already put down their pencils.
Abstraction solves a lot of hard problems, but it is also costly.
Very good points. I think this is why I loved mathematics in high school, or specifically my mathematics teacher. Because he seemed to recognise this in me and instead gave me more abstract things to work on. I really struggle with geometric proofs for some reason, they just don't mesh with my brain. I'm all about symbolic stuff.
He actually ended up teaching me some calculus so I could grok trig identities, even though we were still in the precalc year. And let me use it on the tests to prove stuff that would have been expected to be proved geometrically.
The other big gripe I have with the way kids are tested is the way people are locked out of life because they're only good at one or two subjects to the extent they fail some of the others. Congratulations, you have failed at school because you, a teenager, can't meet our minimum requirements for being able to write inane, shallow analysis of 19th century poetry, can't run n meters in less than m minutes, and have failed to learn German. Good luck pursing your prolific talents with no high school diploma kthxbye.
Norwegian public school system. Certain subjects are required to get a diploma, which is pretty much a hard requirement to even be allowed to apply to a Norwegian university. Those include PE, Norwegian writing(two separate orthographies btw and you need grades in both!) and speaking, English, a 2nd foreign language, history, social studies, some math, and first year science class. Then there's addon elective stuff. I did theoretical math, physics, chem and biology. And I pretty much nailed those subjects
What's even worse though, you can show up, pass the final exam for a subject and still fail the subject due to "insufficient attendance" throughout the year. Which is what happened to me. I was skipping class too much to write code in my room, which ironically meant I couldn't get into a CS course even though I could code circles around the well-behaved neruotypical kids who showed up for class and did their homework.
>Abstraction solves a lot of hard problems, but it is also costly.
This may explain what happened to me. Of the various standardized tests that I have taken in life (SAT in 8th grade, SHSAT, PSAT, SAT, ACT, LSAT, GMAT), the LSAT is the only one that I did not score in the 99th percentile on, and its logic games section was my weakest. I have never had any test prep training of any kind other than taking old exams; if I had taken an LSAT class perhaps I might have approached the section differently.
Exams are designed to make bulk assessment easier. Ideally you would give students a day to do what is in a 2 hour exam and access to internet and papers - but making that work would be very expensive to avoid cheating.
At work you get stuff done rather than answer questions in a obscenely short amount of time
This seems to conflict with how IQ tests are issued. They're always pretty restricted in time, and I suspect they're designed so that someone with 100 IQ is not supposed to get through all of the questions. Not to claim I'm some super intelligent guy but I always felt like IQ tests fail to measure the kind of cognitive tasks that I'm good at, which is to hold a problem in my mind for a long time (in my line of work that's often days or weeks) and then come up with a novel solution.
> To simulate the mechanisms of the human brain, Ritter and her team use digital data from brain scans like magnetic resonance imaging (MRI) as well as mathematical models based on theoretical knowledge about biological processes. This initially results in a “general” human brain model. The scientists then refine this model using data from individual people, thus creating “personalized brain models.” […] “We can reproduce the activity of individual brains very efficiently,” says Ritter. “We found out in the process that these in silico brains behave differently from one another – and in the same way as their biological counterparts. Our virtual avatars match the intellectual performance and reaction times of their biological analogues.”
Huh, I hadn't heard of this before. Does anyone know more about how exactly those "in silico" brains work and how they compare to their real-world counterparts? I mean, the article makes it sound as if the researchers fully understood how the brain works and had managed to create a faithful digital copy, which I find difficult to believe.
EDIT: The original paper says
> To study neuronal processing in silico we created BNMs [brain network models] for the 650 subjects using a tuning algorithm that fits each participant’s simulated FC with their empirical FC (Figs. 2 and 3). The BNMs use coupled neural mass models to simulate the electric, synaptic, firing, and hemodynamic (fMRI) activity of a 379-nodes whole-brain network. Each node consists of one excitatory and one inhibitory population that mutually and recurrently interact. To simulate long-range white matter coupling, the neural masses were connected by each participant’s SC, which were estimated by dwMRI tractography. Importantly, we added feedforward inhibition to increase biological realism
Sounds like they used small neural networks for simulation and adjusted the weights between the neurons to what they saw in participants' MRI measurements.
I wouldn't think someone who took calc for engineers would be able to work through a problem concerning group theory very easily if they were just being introduced to the topic--but they could probably solve some calculus problems (relatively) quickly since they are more used to doing them.
All I'm saying is I think it has more to do with familiarity of material than "intellect." Intelligence to me is being able to rapidly comprehend and assimilate new systems of logic and signification as they are approached. Biology is going to have different rules from Set Theory which is going to have different rules than Political Science. Someone might note that these things are all interrelated: which they are, of course. But I think intelligence here would be noticing the contradictions that appear when they are set in relation, not simply trying to understand how they all stand together in some grand, unified fashion; nor (on the other hand), making humble claims (like formalism) which are not truly held by anyone.
We were given a problem involving the movements of a chess knight over a weird non-chess board to try to reach a particular point from a particular start in 4th grade. At the time I ran it backward and believed this showed it to be unsolvable. But I also believed the teacher would not give us an unsolvable problem without somehow indicating that it couldn't be solved (as doing so would violate the implied rules of the classroom).
One student solved it in class, but the rest of us weren't told what the solution was. I tried solving it a bit in high school but still couldn't come up with a solution.
I really hope there is a solution that I couldn't find, and not that we were expected to discover that there is no solution. I expect that problems in the real world may not have a solution, but if you're going to pull that sort of thing in a 4th grade classroom (even a gifted one) I expect some setup so that the kids know this is a possibility.
"Therefore, taking decisions on higher-level problems must be held out until evidence from sub-problems was integrated to not prematurely jump to a conclusion."
Lower response time indicates jump to the conclusion that happened to be correct. The percentage of correctly solved higher-level problems was predictably lower for people with lower g-factor.
That is the most egregious cookie popup I've seen. The worst part is it's not immediately obvious what an indifferent user has to click on quickly get rid of it, necessitating reading and thinking.
"Hey, waait a minute! Is the article trolling me with a 'difficult problem' here? which I will now proceed to take a long time to 'solve'? because I'm 'intelligent'? well, screw you, troll - I can solve this quickly!", and so, I hastily clicked on something in order to make the popup go away.
The popup does actually feel like a good illustration of the basic phenomena. Average person says "oh look, a cookie popup" and clicks through, possibly choosing randomly between "confirm" and "select all". (People with lower familiarity with cookie popups or the language might get completely stuck)
HNer isn't at all intimidated by the wall of text and knows exactly what it mean but reads every word to check they haven't snuck any particularly egregious privacy violations and goes down the rabbit hole of evaluating the likely implications of blocking 'necessary' cookies and the virtues of doing that via the cookie popup or browser plugin before making their selection...
Are you complaining about the lack of dark patterns that push you to accept all cookies? When that cookie banner opened for me, I thought "finally, one of the moral ones" because all the non essential cookies are turned off by default, and you have two options with the same visual weight to either accept or reject the others.
Have you seriously never seen a worse one? Because compared to 99% of all cookie popups I know this one's extremely user friendly. It's the second best variant after the ones explicitly showing an identically styled "reject all" button.
My only complaint is the selection looking like a link (colored/underlined), which my brain associates with GET, which should not change state, but a change of state is required to store the cookie preference.
Could we please get an ISO for usability, and regulation that requires compliance?
It's the best one I've ever seen. Completely free of dark patterns (except maybe the fact that "Select All" and "Confirm Selection" are arguably the wrong way round) and literally the only one I've encountered where I could reject all but necessary cookies with a single click. All the non-essential ones are off by default, and they're not advertising ones anyway.
People should differentiate between introvert, knowledgeable, and intelligent. I most likely qualify for the first two but I wouldn't even begin to guess on how to know whether I'm in the third league.
It's about IQ, not "Intelligent Brains" which is editorial about the validity of IQ sneaking into the headline. It's not hard to know your IQ, there are tests.
Or anybody who went to school and saw how well they learn compared to the average student should have an idea. IQ was originally meant as the predictor of how fast you learn after all.
If the article is true I would assume that the most highly intelligent reader would have a great deal of difficulty commenting on the subject in a reasonable about of time, and would most likely end up short circuiting the effort in favour of doing something else …
Solving difficult problems well typically involves some form of root cause analysis. A novice looking at a broken thing may decide to simply replace it and move on with the day. You can mindlessly replace widgets very rapidly. A master looking at the same might be more inclined to ask "why" a few times and set up some additional calls with the customer.
I don't think this really has anything to do with "intelligence" as much as it does patience.
The article uses strange language to couch the results. Making an error isn't solving a problem at all. It should read that higher IQ leads to more reliable problem solving. Which would be less click-baity, admittedly. I understand why researchers would make the time variable the focus, but it isn't the story.
Who would you want to be your airline pilot: the person who solves 70% of problems quicker or who solves close to 100% of the problems slower? The ability to error check has a time cost but also is of infinite value for any position of consequence.
Good heavens, for 10 years after college I was having "aha" moments about physics and math. Looking back I don't see how it could have been any other way, and it's crazy to think you can recapitulate 300 years of science in 4 years into the brain of an 18-year-old. But we act like that's what we're doing. Maybe that's what phd programs and postdocs are really for, not so much learning more but letting what you did learn actually soak in.
This isn't a particularly shocking result but it's great to see validation of a theoretical model put to practice using computing. So they were able to match a similar result in their model of intelligence and mental computation time between the real and simulated participants.
Makes sense: the IQ tests train you to think quick but double check to be sure. To do well at them (unless genius) requires meta stuff like how much time to give to a question, how much to check the answer, and so on. Time is limited.
Feynman botched the Mensa IQ test. My hypothesis is either he did it as prank or he just thought about another million possibilities for each item that others couldn't even imagine.
Mensa? Feynman reportedly said that his high school IQ was 125 during his "Address to Far Rockaway High School" (1). I can find nothing about him taking Mensa tests.
Either way, integrating many different paths from multiple directions to reach a solution (hah!) is something intelligent people are more likely going to do which takes a lot of time and requires building abstractions.
I guess you want to say that it’s a poor metric for intelligence.
Not so sure. IQ is measured in standardized tests. Participants should have the same amount of time to answer the questions. If intelligent people take longer to reach the correct answers than non-intelligent, then, it seems paradox.
The idea could be to prolong the test. So we better see who reaches the correct answers without much time pressure (but still with the same amount). Or go even further and ask really difficult questions without any limit.
These would probably also measure the ability to concentrate, or motivation to continue, … which might not be what you want for an IQ test.
However, if your question would be true, designers of IQ test could fix them in light of this research: they plan for enough time so that even the most intelligent have time to answer the questions. It’s of course a problem to find a couple of really intelligent people if your test is flawed in the first place.
IQ tests have problems of varying difficulty and as the article mentions easier problems are solved faster. So on average the time limit should not be a problem.
The title should be "high IQ" not "intelligent". Those get equated far to often, while real intelligence is far more than just solving logic puzzles (even if that's an important part of of it).
There are many ways to be smart, and I try to be grateful about the ways in which I'm smart and then appreciate others in the ways they are smarter than me. It's very hard to be smart in everything, in my experience. From how to be funny, likeable, handle tough social situations, decision making about life plans, handling stress, and different challenges in engineering work - from simple tasks to project planning.
For a very long time, I just have not been smart enough to go to sleep in time. (Metacognition related "intelligence"?)
when tackling a large problem, in the beginning I find it hard to concentrate because I dont know "the best way", but even from the beginning I can understand that you could handle it about 99 different ways. I want to chase down nearly all of them so I can decide the best one, but sometimes its better to just get something crappy done 100%, then you can go back and iterate. otherwise you might get stuck on side quests forever:
Intelligent people have wider knowledge, they can see the problem from different angles, different edge cases. It takes time. On the other there is The Dunning–Kruger effect where less intelligent people jump to results too quick.
In my view, we need to stop putting all notions of intelligence on a pedestal. In my opinion, it interferes with productive science. It's useful to know that mentally rotating an object is a task that allows you to sort people by IQ, roughly. It's less useful to have studies that say "aww it's okay if you take long to solve hard problems, it's actually a sign of intelligence." It just creates cope.
* and the solution they come up with is correct more often.
The article title refers to something that's been long known even in pop science since Daniel Kahnemann's "Thinking Fast and Slow". In fact, the original paper[0] even cites Daniel Kahnemann's work:
> Simulation results indicate that decision-making speed is traded with accuracy, resembling influential theories from the fields of economy and psychology on fast and slow thinking.
Kahnemann's work might be summarized (very roughly) as follows: "System 1" often quickly suggests an intuitive (and frequently wrong) answer, whereas "System 2" is the part that does the slower, more rational, and conscious thinking. "Intelligent" people tend to be those who control their System 1 and thus their urge for intuitive answers more effectively.
And indeed this is what the article says, too:
> Resting-state functional MRI scans showed that slower solvers had higher average functional connectivity, or temporal synchrony, between their brain regions. In personalized brain simulations of the 650 participants, the researchers could determine that brains with reduced functional connectivity literally “jump to conclusions” when making decisions, rather than waiting until upstream brain regions could complete the processing steps needed to solve the problem.
> “In more challenging tasks, you have to store previous progress in working memory while you explore other solution paths and then integrate these into each other. This gathering of evidence for a particular solution may sometimes takes longer, but it also leads to better results.
However, if I understand correctly, the thing about the research here that's actually novel is that they now have a better understanding of the neural processes underlying System 1 vs. System 2 ("we identified a mechanistic link between functional connectivity, intelligence, processing speed and brain synchrony for trading accuracy with speed in dependence of excitation-inhibition balance") and that they in fact simulated the brain digitally, see my other comment.
This is interesting, but not surprising when you think about it. My whole career I've noticed there are always people who think as soon as a problem is mentioned, it needs an instant solution - and they are quick to volunteer one. Others say "Hold on a moment, let's back up and start from the beginning". They are calm and methodical and careful to withhold their conclusion until all data is gathered, and have removed the impossibilities from the possible solution set. They usually are the ones to solve the problem in the end I've noticed.
That doesn't work well in interviews, especially with how terrible most interviewers at time management. I sometimes get 10 minutes for a system design problem because the interviewer was expected to get signals on my non-technical competencies as well as system design.
This is never enough time to ask clarifying questions, diagram things, and get a good solution out unless it's similar to a problem I've already solved.
It's often OK to not solve the problem as long as you give an interviewer insight into how you think, but some interviewers expect a miracle.