14 ms·

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 i

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.

ta988 3y ago
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.
deepGem 3y ago
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.
- the_mar 3y ago
  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.
- irrational 3y ago
  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).
  - laserbeam 3y ago
    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.
    - irrational 3y ago
      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.
  - zo1 3y ago
    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.
    - prox 3y ago
      Isn’t the portfolio they came with a huge indicator? Like did this person do well at X or Y. Even when fresh out of school one should see what someone is capable of.
- smcleod 3y ago
  Who is doing interviews across months? I haven't heard of them being more than two weeks apart at most. Do they pay you for your time for those long multi-hour interviews?
  - hectormalot 3y ago
    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)
    - hsbauauvhabzb 3y ago
      But without paying companies will only get the candidates desperate enough to sit through all the interview rounds.
      - 3np 3y ago
        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.
      - fpig 3y ago
        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.
- thaumasiotes 3y ago
  > 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".
  - vineyardmike 3y ago
    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.
    - thaumasiotes 3y ago
      > 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.
slily 3y ago
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.
- nicoburns 3y ago
  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.
tstrimple 3y ago
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.
- dontlaugh 3y ago
  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.
lmarcos 3y ago
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). At interviews they stop me at my first attempt.
Eliah_Lakhin 3y ago
Companies are usually looking for average candidates to do an average job.
skarlso 3y ago
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.
qxmat 3y ago
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.)
ronnykylin 3y ago
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.
jvanderbot 3y ago
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.
q7xvh97o2pDhNrh 3y ago
> 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.
- qumpis 3y ago
  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?
  - temporallobe 3y ago
    “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.
    - buttscicles 3y ago
      Psychological safety is what allows people to exchange ideas and be wrong without fear of it being used against them
    - wfme 3y ago
      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.
temporallobe 3y ago
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.
- lisasays 3y ago
  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.
- mehh 3y ago
  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.
deleted 3y ago
[deleted]
jaybrendansmith 3y ago
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.
- codethief 3y ago
  > I've learned to distrust my 'instant answer' 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.
lisasays 3y ago
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.
deepsun 3y ago
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.

ta988 3y ago

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.

deepGem 3y ago

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.

the_mar 3y ago
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.
irrational 3y ago
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).
- laserbeam 3y ago
  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.
  - irrational 3y ago
    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.
- zo1 3y ago
  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.
  - prox 3y ago
    Isn’t the portfolio they came with a huge indicator? Like did this person do well at X or Y. Even when fresh out of school one should see what someone is capable of.
smcleod 3y ago
Who is doing interviews across months? I haven't heard of them being more than two weeks apart at most. Do they pay you for your time for those long multi-hour interviews?
- hectormalot 3y ago
  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)
  - hsbauauvhabzb 3y ago
    But without paying companies will only get the candidates desperate enough to sit through all the interview rounds.
    - 3np 3y ago
      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.
    - fpig 3y ago
      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.
thaumasiotes 3y ago
> 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".
- vineyardmike 3y ago
  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.
  - thaumasiotes 3y ago
    > 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.

slily 3y ago

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.

nicoburns 3y ago
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.

tstrimple 3y ago

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.

dontlaugh 3y ago
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.

lmarcos 3y ago

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). At interviews they stop me at my first attempt.

Eliah_Lakhin 3y ago

Companies are usually looking for average candidates to do an average job.

skarlso 3y ago

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.

qxmat 3y ago

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.)

ronnykylin 3y ago

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.

jvanderbot 3y ago

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.

q7xvh97o2pDhNrh 3y ago

> 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.

qumpis 3y ago
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?
- temporallobe 3y ago
  “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.
  - buttscicles 3y ago
    Psychological safety is what allows people to exchange ideas and be wrong without fear of it being used against them
  - wfme 3y ago
    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.

temporallobe 3y ago

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.

lisasays 3y ago
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.
mehh 3y ago
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.

deleted 3y ago

[deleted]

jaybrendansmith 3y ago

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.

codethief 3y ago
> I've learned to distrust my 'instant answer' 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.

lisasays 3y ago

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.

deepsun 3y ago

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.