4 ms·

I sometimes feel like i'm Bryan https://en.wikipedia.org/wiki/Impostor_syndrome https://en.wikipedia.org/wiki/Impostor_syndrome

PaulRobinson 10y ago
Unless your only solution to a coding problem is to find somebody else who has solved, or will solve, the issue for you, you are not an imposter. I once was recruiting for a startup. The CEO and his partner who was interim CTO (I was coming on-board as CTO), had lined up a candidate. Conversation went like this: Me: Before we go through a coding exercise, I'd like to talk to you about how you might go through solving a problem we set you, I just want to see if you have a process. Candidate: OK Me: So let's suppose I give you a problem that involves routing, and identifying the shortest route between two points on a directed graph. What's your first stab? Candidate: So, first I'd look for a gem [we were a Ruby shop] to see if this exists already. Me: OK, let's assume that the data structure is proprietary, we are going to import and maybe translate it, and as a result it's unlikely that for this specific type of problem there is no gem. What next? Candidate: I'd have a look at Stack Overflow. Me: OK, there can be good things on Stack Overflow, but like I say this, is proprietary - the best you're going to get is inspiration. Candidate: Hmmm. Me: How about doing a search through some data structure and algorithm books? What sort of thing might you look for? Candidate: In my experience, everything is either a gem or on Stack Overflow. Me: What if it isn't? Candidate: It always is. This is the most egregious example I'd seen of what Jeff Atwood had identified a decade ago: programmers who can't progam - https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/ I wrote an email to the CEO and his founder that afternoon. The subject line simply read "[Candidate] interview: can't actually write code". If you don't know how to start chipping away at a problem, if you don't have a fire in your belly to go dig in, then you're a fraud. Nobody has all the answers. Nobody has memorised AOCP and every DS&A book written. The trick to not being an imposter is knowing you don't know, but that you have the means to figure it out even if nobody else has before. You want to go dive into the books, into the theories, into discussions with colleagues and everybody else you can find who might have a handle on it. If you've got the appetite to learn at each step, you're not an imposter. You're in the same group of people as the pioneers of computing who didn't have any text books or resources to lean on, and nobody gets to call you an imposter, least of all yourself. And yes, I get imposter syndrome myself sometimes, and sometimes have to remind myself of this, in a mirror, whilst worrying I'm about to get fired for not knowing it all perfectly.
- ubernostrum 10y ago
  I've done this to annoy recruiters and interviewers, and to make a point about the stupidity of popular interview processes. I also contribute to things like Django precisely to enable me to work this way day-to-day -- I don't want to reinvent basic things over and over again, I want to pull a well-tested piece of code off the shelf and use it. And I'd likely no-hire anyone who insisted on doing real work the way we insist people work in interviews.
  - AstralStorm 10y ago
    Depends on what you're doing, if the problem domain is relatively exotic, you might want people who can handle work from scratch. Web pages and data warehouse are not such areas. Another useful skill to verify for non junior hires would be navigation through complex code, approaches to maintaining and improving code quality. Without enough people skilled in this, anything not tiny will drown in technical debt over time.
- arvinsim 10y ago
  > Nobody has all the answers. Nobody has memorised AOCP and every DS&A book written. The trick to not being an imposter is knowing you don't know, but that you have the means to figure it out even if nobody else has before. You want to go dive into the books, into the theories, into discussions with colleagues and everybody else you can find who might have a handle on it. That is true. But if you look at the way some companies does interviews, they do seem to expect you to memorize a lot programming trivia. If am to be honest, I have forgotten how to implement the shortest route from using a directed graph from scratch. But I am confident that I can easily reconstruct the implementation after I review the actual algorithm since I have done it before. I never had to implement it myself in production in all of my years of programming. But then again, maybe I am just stuck on one of those programming jobs that are considered 'menial'.
  - PaulRobinson 10y ago
    Exactly, so the way that interview should have gone is something like: Candidate: I'm not sure, I think I remember something about A* or something. Me: Cool, that sounds familiar to me as well. How about we go google it up and then have a look at implementing it. Here's some source data that comes from our supplier, let's pair on getting something working... And an hour later, we would have built something trivial but useful, and I'd be happy.

PaulRobinson 10y ago

Unless your only solution to a coding problem is to find somebody else who has solved, or will solve, the issue for you, you are not an imposter. I once was recruiting for a startup. The CEO and his partner who was interim CTO (I was coming on-board as CTO), had lined up a candidate. Conversation went like this: Me: Before we go through a coding exercise, I'd like to talk to you about how you might go through solving a problem we set you, I just want to see if you have a process. Candidate: OK Me: So let's suppose I give you a problem that involves routing, and identifying the shortest route between two points on a directed graph. What's your first stab? Candidate: So, first I'd look for a gem [we were a Ruby shop] to see if this exists already. Me: OK, let's assume that the data structure is proprietary, we are going to import and maybe translate it, and as a result it's unlikely that for this specific type of problem there is no gem. What next? Candidate: I'd have a look at Stack Overflow. Me: OK, there can be good things on Stack Overflow, but like I say this, is proprietary - the best you're going to get is inspiration. Candidate: Hmmm. Me: How about doing a search through some data structure and algorithm books? What sort of thing might you look for? Candidate: In my experience, everything is either a gem or on Stack Overflow. Me: What if it isn't? Candidate: It always is. This is the most egregious example I'd seen of what Jeff Atwood had identified a decade ago: programmers who can't progam - https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/ I wrote an email to the CEO and his founder that afternoon. The subject line simply read "[Candidate] interview: can't actually write code". If you don't know how to start chipping away at a problem, if you don't have a fire in your belly to go dig in, then you're a fraud. Nobody has all the answers. Nobody has memorised AOCP and every DS&A book written. The trick to not being an imposter is knowing you don't know, but that you have the means to figure it out even if nobody else has before. You want to go dive into the books, into the theories, into discussions with colleagues and everybody else you can find who might have a handle on it. If you've got the appetite to learn at each step, you're not an imposter. You're in the same group of people as the pioneers of computing who didn't have any text books or resources to lean on, and nobody gets to call you an imposter, least of all yourself. And yes, I get imposter syndrome myself sometimes, and sometimes have to remind myself of this, in a mirror, whilst worrying I'm about to get fired for not knowing it all perfectly.

ubernostrum 10y ago
I've done this to annoy recruiters and interviewers, and to make a point about the stupidity of popular interview processes. I also contribute to things like Django precisely to enable me to work this way day-to-day -- I don't want to reinvent basic things over and over again, I want to pull a well-tested piece of code off the shelf and use it. And I'd likely no-hire anyone who insisted on doing real work the way we insist people work in interviews.
- AstralStorm 10y ago
  Depends on what you're doing, if the problem domain is relatively exotic, you might want people who can handle work from scratch. Web pages and data warehouse are not such areas. Another useful skill to verify for non junior hires would be navigation through complex code, approaches to maintaining and improving code quality. Without enough people skilled in this, anything not tiny will drown in technical debt over time.
arvinsim 10y ago
> Nobody has all the answers. Nobody has memorised AOCP and every DS&A book written. The trick to not being an imposter is knowing you don't know, but that you have the means to figure it out even if nobody else has before. You want to go dive into the books, into the theories, into discussions with colleagues and everybody else you can find who might have a handle on it. That is true. But if you look at the way some companies does interviews, they do seem to expect you to memorize a lot programming trivia. If am to be honest, I have forgotten how to implement the shortest route from using a directed graph from scratch. But I am confident that I can easily reconstruct the implementation after I review the actual algorithm since I have done it before. I never had to implement it myself in production in all of my years of programming. But then again, maybe I am just stuck on one of those programming jobs that are considered 'menial'.
- PaulRobinson 10y ago
  Exactly, so the way that interview should have gone is something like: Candidate: I'm not sure, I think I remember something about A* or something. Me: Cool, that sounds familiar to me as well. How about we go google it up and then have a look at implementing it. Here's some source data that comes from our supplier, let's pair on getting something working... And an hour later, we would have built something trivial but useful, and I'd be happy.