5 ms·

When I went to my first job interview after years building my own software product, I brought all kinds of examples of code I wrote which I felt showcased my ta

When I went to my first job interview after years building my own software product, I brought all kinds of examples of code I wrote which I felt showcased my talent (including an effective API I created for one of their services that lacked one, and code examples of mine that had been published in a textbook). The interviewers had zero interest, and just wanted to discuss superficial / artificial whiteboard-type problems and (in retrospect) how to hose more ad revenue out of users by upending expected browser behavior. I can appreciate how some of it offered a glimpse into how I approach problem solving, but the process (not just that aspect) left a sour taste, and over a decade later I'm so glad I didn't wind up in a career position there. If you want to attract top tier talent, as an employer you should also work to make your interview process fun and challenging, and showcase what sets you apart from you competitors. Too often firms loose sight of the fact that in the interview, they are being evaluated too.

theogravity 2y ago
I'm absolutely terrible at interviews, especially whiteboarding, and the best ones either involve taking a tour of my own code, or them showing parts of their codebase and me asking questions around it; or, take homes and I have a chance to explain what I built. I don't have the memory capacity that others do to just stuff leetcode challenge algorithms that I'll never use in my head.
- aoeusnth1 2y ago
  In my experience leetcode is not really memory heavy (except in the competitive programming scene). It’s about being able to think of a naive solution to a problem, recognize why it is inefficient, and figure out how to make it efficient, usually with DP or graph approaches.
  - theogravity 2y ago
    > DP or graph approaches I don't use either in my day-to-day. I also have memory issues around just memorizing these things. I can probably do it if I can look up how it works and then translate it. I have a really bad memory and I don't know if it's related to being aphantasic or not (no mental imaging capacity).
    - aoeusnth1 2y ago
      Again, it’s not really about “just” memorizing them, it’s about internalizing how they work to the point where they are second nature. Like being able to apply calculus to everyday life, once you have internalized it, it changes how you think about things and analyze problems. Learning calculus through memorization will not help with that.
      - theogravity 2y ago
        > internalizing how they work And how long do you expect that to take? Do you think I haven't tried doing that before? It just doesn't register unless i'm literally doing it every day. And with so many algorithms out there there's not enough time to internalize all that. I don't have that kind of memory everyone else seems to have.
        Izkata 2y ago
        > And with so many algorithms out there Their point is that this is wrong. They're saying there's a few underlying principles that apply to most of these, and those are what you have to internalize.
        Jensson 2y ago
        Yeah, a few concepts like hashing, "divide and conquer" and dynamic programming is enough to solve most problems. If you understand and know how to use those and a few more well you easily ace interview questions because those are the building blocks for almost all useful simple algorithms that you get asked about in interviews.
    - xigoi 2y ago
      If you think these things are about rote memorization, you’re doing them very wrong.
parpfish 2y ago
I see two problems with bringing in your code for an interview: - I don’t know how long it took you to do it, and being able to do things in a reasonable amount of time is part of all jobs. Also, I don’t even know if you’re the one who wrote it or if you are passing off somebody else’s work - it’s unstandardized across interviewees, so how do you compare? Person A wrote a more elegant solution, Person B solved a more challenging problem, and Person C did all their best work on propriety stuff they couldn’t share so they had to share show you a throwaway side project they did in one weekend
TN1ck 2y ago
Absolutely agree, I'm always afraid of loosing out on someone great. Even the screening of CVs themselves is an incredible hard task as the best engineers are often humble and maybe not portray their strengths enough. What I do to make the live coding challenge a bit nicer: * I use codesandbox.io (not affiliated) as a live coding environment which is a VSCode editor that executes your code whenever you save. This makes it much more realistic how one would solve it real life. * I have them share their screen and make it clear that they can google whenever needed and that it's expected (who remembers the exact incarnations for reading a file or some API) * I only do one challenge, which most candidates finish in less than 30min. We then talk about refactoring it, building an API design around it etc. * The challenge itself is building a solver for a text based game, which imho is a fun task and is literally reading a file and filtering the content with some ifs. Any recommendations for improvement are welcome.
- nomel 2y ago
  I think executing code makes things too strict, and can lock up/shut people down, since forgetting a library function name means you're completely stuck, which causes a feedback loop of nervous. Interviews are high stress. Absolute precision, required to run code, is not a good fit for high stress, in my opinion. You'll filter people that haven't don't a lot of interviews more than anything. I keep the problem relatively simple. I tell them that they can use whatever language, don't worry about silly typos, or exact syntax, and if you forget a library name just make one up. It's trivial to see if someone can code without executing the code. If I notice obvious problems, I'll describe the incorrect behavior, like if there's an infinite loop: "I see a problem. When you run the code, you see that it never ends".
  - jgwil2 2y ago
    > forgetting a library function name means you're completely stuck Just let them use Google to find documentation, as they would in a real job setting.
    - nomel 2y ago
      No need. I explicitely tell them that I don't care if they remember exact library/function names, and to just make them up and tell me what they do, if they don't remember. If you require specifics like that, you'll filter out anyone who hasn't worked on that specific very recently. Those sorts of things aren't something you should need to worry about keeping in your head for long.
Aurornis 2y ago
When bootcamps were first becoming popular, I started inviting graduates of a nearby bootcamp to interview. The first candidate had a few small but impressive sample projects in their GitHub, including some API development and other things that surprised me for someone with under a year of experience. I was impressed! Then the second one came in, who also had a GitHub portfolio with the same sample projects and the same API design (with minor differences). I felt dumb when I realized that those sample "side projects" were actually something that the bootcamp trained them to develop and put into their GitHub profiles. Obvious in hindsight, but remember this was when bootcamps were supposed to be the next educational revolution and everyone was on the "college bad" train. In a different interview, I mentioned one of my hobbies. The candidate boldly explained that he wrote a certain package for the programming language we used. I asked some more questions before realizing he was literally describing a project I had published! He immediately changed his story and claimed to have misspoken when he realized that we were on to something. These aren't equivalent to your story, obviously. However, these are some of the reasons why interviewers still want candidates to go through the standardized testing that every candidate receives. Comparing candidates on equal testing is also pushed very hard on us by HR. If you start judging different candidates based on entirely different standards, people get extremely fussy
nomel 2y ago
> The interviewers had zero interest I used to think the same when I started interviewing. Now I'm into the hundreds, and in my experience, that is the correct approach for a peripheral interviewer (not the direct hiring manager), and it's for your benefit. We have 45 minutes to prove to ourselves, and our managers, and their managers, that you are the right hire. No "feelings" or "hunches" allowed: clear tangible demonstration of competence for the requirements listed, that everyone can read, and be convinced. Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected. If I spend 30 minutes going over what you did, there are two problems: 1. Figuring out if they actually did the work, or maybe played some small part in a team, takes considerable time. It's not easy, because people are often running with inflated resumes, with the most interesting things usually being the inflation. People can have a good understanding of a project, without doing anything in that project, claiming the whole project for themselves. The path to being convinced that they actually did it ends up being very different for every candidate, and any exaggeration/lie you catch them in makes you question all of it. 2. It only gives a short amount of time to get some deterministic proof that represents the work: typing actual code to solve a problem. If something questionable comes up during then, in the little time left, you're not going to get a chance to prove it's not an issue. If that same issue shows up in anyone else's interview, without me being able to defend you, then that's it. So, I immediately jump into my "standard" interview. It's easy. An average person will finish on time. A great person will fly through it. It checks all the boxes, gives me the proof, and even expands out into a few things that I know are sometimes questionable for others. It gives a clear yes or no for the job requirements. THEN we go into the projects with the remaining time. If you're competent, you'll have a bunch of time left, but you'll also be a strong "yes" anyways. Any cool stuff you show me will change it from a "yes" to "we need this guy, throw money at him". If you don't like interviews, you have to blame the liars that make them the way they are. There are so many liars.
- ryandrake 2y ago
  > Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected. This is a very good thing because it helps to prevent bias from sneaking in, either positive or negative. Too many interviews are vulnerable to rapport and charm. "I really like and want to work with that cool bro" should not be enough justification to hire someone. Also, (at least at larger companies), when you provide feedback, you need to also reference evidence from the interview. You can't just say "Candidate X can definitely code." You have to say "Candidate X showed, through their implementation of the Linked List Reversal problem and the Towers of Hanoi problem, that they could think through a problem and express it effectively in code. Here are some examples from the code itself that show this...."

theogravity 2y ago

I'm absolutely terrible at interviews, especially whiteboarding, and the best ones either involve taking a tour of my own code, or them showing parts of their codebase and me asking questions around it; or, take homes and I have a chance to explain what I built. I don't have the memory capacity that others do to just stuff leetcode challenge algorithms that I'll never use in my head.

aoeusnth1 2y ago
In my experience leetcode is not really memory heavy (except in the competitive programming scene). It’s about being able to think of a naive solution to a problem, recognize why it is inefficient, and figure out how to make it efficient, usually with DP or graph approaches.
- theogravity 2y ago
  > DP or graph approaches I don't use either in my day-to-day. I also have memory issues around just memorizing these things. I can probably do it if I can look up how it works and then translate it. I have a really bad memory and I don't know if it's related to being aphantasic or not (no mental imaging capacity).
  - aoeusnth1 2y ago
    Again, it’s not really about “just” memorizing them, it’s about internalizing how they work to the point where they are second nature. Like being able to apply calculus to everyday life, once you have internalized it, it changes how you think about things and analyze problems. Learning calculus through memorization will not help with that.
    - theogravity 2y ago
      > internalizing how they work And how long do you expect that to take? Do you think I haven't tried doing that before? It just doesn't register unless i'm literally doing it every day. And with so many algorithms out there there's not enough time to internalize all that. I don't have that kind of memory everyone else seems to have.
      - Izkata 2y ago
        > And with so many algorithms out there Their point is that this is wrong. They're saying there's a few underlying principles that apply to most of these, and those are what you have to internalize.
        Jensson 2y ago
        Yeah, a few concepts like hashing, "divide and conquer" and dynamic programming is enough to solve most problems. If you understand and know how to use those and a few more well you easily ace interview questions because those are the building blocks for almost all useful simple algorithms that you get asked about in interviews.
  - xigoi 2y ago
    If you think these things are about rote memorization, you’re doing them very wrong.

parpfish 2y ago

I see two problems with bringing in your code for an interview: - I don’t know how long it took you to do it, and being able to do things in a reasonable amount of time is part of all jobs. Also, I don’t even know if you’re the one who wrote it or if you are passing off somebody else’s work - it’s unstandardized across interviewees, so how do you compare? Person A wrote a more elegant solution, Person B solved a more challenging problem, and Person C did all their best work on propriety stuff they couldn’t share so they had to share show you a throwaway side project they did in one weekend

TN1ck 2y ago

Absolutely agree, I'm always afraid of loosing out on someone great. Even the screening of CVs themselves is an incredible hard task as the best engineers are often humble and maybe not portray their strengths enough. What I do to make the live coding challenge a bit nicer: * I use codesandbox.io (not affiliated) as a live coding environment which is a VSCode editor that executes your code whenever you save. This makes it much more realistic how one would solve it real life. * I have them share their screen and make it clear that they can google whenever needed and that it's expected (who remembers the exact incarnations for reading a file or some API) * I only do one challenge, which most candidates finish in less than 30min. We then talk about refactoring it, building an API design around it etc. * The challenge itself is building a solver for a text based game, which imho is a fun task and is literally reading a file and filtering the content with some ifs. Any recommendations for improvement are welcome.

nomel 2y ago
I think executing code makes things too strict, and can lock up/shut people down, since forgetting a library function name means you're completely stuck, which causes a feedback loop of nervous. Interviews are high stress. Absolute precision, required to run code, is not a good fit for high stress, in my opinion. You'll filter people that haven't don't a lot of interviews more than anything. I keep the problem relatively simple. I tell them that they can use whatever language, don't worry about silly typos, or exact syntax, and if you forget a library name just make one up. It's trivial to see if someone can code without executing the code. If I notice obvious problems, I'll describe the incorrect behavior, like if there's an infinite loop: "I see a problem. When you run the code, you see that it never ends".
- jgwil2 2y ago
  > forgetting a library function name means you're completely stuck Just let them use Google to find documentation, as they would in a real job setting.
  - nomel 2y ago
    No need. I explicitely tell them that I don't care if they remember exact library/function names, and to just make them up and tell me what they do, if they don't remember. If you require specifics like that, you'll filter out anyone who hasn't worked on that specific very recently. Those sorts of things aren't something you should need to worry about keeping in your head for long.

Aurornis 2y ago

When bootcamps were first becoming popular, I started inviting graduates of a nearby bootcamp to interview. The first candidate had a few small but impressive sample projects in their GitHub, including some API development and other things that surprised me for someone with under a year of experience. I was impressed! Then the second one came in, who also had a GitHub portfolio with the same sample projects and the same API design (with minor differences). I felt dumb when I realized that those sample "side projects" were actually something that the bootcamp trained them to develop and put into their GitHub profiles. Obvious in hindsight, but remember this was when bootcamps were supposed to be the next educational revolution and everyone was on the "college bad" train. In a different interview, I mentioned one of my hobbies. The candidate boldly explained that he wrote a certain package for the programming language we used. I asked some more questions before realizing he was literally describing a project I had published! He immediately changed his story and claimed to have misspoken when he realized that we were on to something. These aren't equivalent to your story, obviously. However, these are some of the reasons why interviewers still want candidates to go through the standardized testing that every candidate receives. Comparing candidates on equal testing is also pushed very hard on us by HR. If you start judging different candidates based on entirely different standards, people get extremely fussy

nomel 2y ago

> The interviewers had zero interest I used to think the same when I started interviewing. Now I'm into the hundreds, and in my experience, that is the correct approach for a peripheral interviewer (not the direct hiring manager), and it's for your benefit. We have 45 minutes to prove to ourselves, and our managers, and their managers, that you are the right hire. No "feelings" or "hunches" allowed: clear tangible demonstration of competence for the requirements listed, that everyone can read, and be convinced. Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected. If I spend 30 minutes going over what you did, there are two problems: 1. Figuring out if they actually did the work, or maybe played some small part in a team, takes considerable time. It's not easy, because people are often running with inflated resumes, with the most interesting things usually being the inflation. People can have a good understanding of a project, without doing anything in that project, claiming the whole project for themselves. The path to being convinced that they actually did it ends up being very different for every candidate, and any exaggeration/lie you catch them in makes you question all of it. 2. It only gives a short amount of time to get some deterministic proof that represents the work: typing actual code to solve a problem. If something questionable comes up during then, in the little time left, you're not going to get a chance to prove it's not an issue. If that same issue shows up in anyone else's interview, without me being able to defend you, then that's it. So, I immediately jump into my "standard" interview. It's easy. An average person will finish on time. A great person will fly through it. It checks all the boxes, gives me the proof, and even expands out into a few things that I know are sometimes questionable for others. It gives a clear yes or no for the job requirements. THEN we go into the projects with the remaining time. If you're competent, you'll have a bunch of time left, but you'll also be a strong "yes" anyways. Any cool stuff you show me will change it from a "yes" to "we need this guy, throw money at him". If you don't like interviews, you have to blame the liars that make them the way they are. There are so many liars.

ryandrake 2y ago
> Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected. This is a very good thing because it helps to prevent bias from sneaking in, either positive or negative. Too many interviews are vulnerable to rapport and charm. "I really like and want to work with that cool bro" should not be enough justification to hire someone. Also, (at least at larger companies), when you provide feedback, you need to also reference evidence from the interview. You can't just say "Candidate X can definitely code." You have to say "Candidate X showed, through their implementation of the Linked List Reversal problem and the Towers of Hanoi problem, that they could think through a problem and express it effectively in code. Here are some examples from the code itself that show this...."