Funny story, in 15 years of professional software development I never experienced the sense of imposter syndrome until very recently when I decided after 12 years at one employer (on many satisfying projects) I needed to consider expanding my employment options. AKA I started looking for a new job. Once I got a whiff of the putrid state of hiring in our industry today holy hell...
Sure, I’ve been successful at this for 15+ years, delivering at or above expectations at almost 100% rate with some great individual excellence tossed in for good measure. But I am 99% sure I’d never pass an interview for a new job doing exactly what I do now. Am I even a software engineer developer programmer whatever?
It has been a very disconcerting experience.
Anyway, I figure the feeling of being an imposter is just a natural subconscious reaction to what seems like an entirely alien definition of what my job is vs. what other employers seem to expect from someone doing my job. I’m sure I’m not the only one who has noticed this disconnect as so many links/threads on HN allude to.
It certainly has given me a good deal of anxiety, though, I don’t really see what choice I have but to accept this nonsense and try to prepare for it. Luckily I haven’t been feeling any depression or burnout or any other obvious mood impact from the whole experience, but, I could see that happening if I had less confidence in my ability to fill in my knowledge gaps, even if it’s for nothing beyond an interview.
Similar situation: I have a history of obtaining lower level positions and then quickly rising up to higher level engineering position within the same company (this has happened with two employers). I don't think this can reliably be used as a general strategy, I just have been lucky with employers. This doesn't give me a huge amount of confidence when considering my chances at getting a new job comparable to the level I'm at now.
Also the past few times I have seen the job posting for a position I've held, based on the job posting I'd assume I was unqualified. There's a bazillion buzzwords and technologies in our industry and it's difficult to account for how experience carries across related technologies (or not directly related technologies) in a job description. So employers end up just listing every technology you may touch and add an 'X years experience required'.
On the other hand, having worked with several engineers of varying backgrounds at my company and our partners I don't feel like an imposter at all in my actual abilities, knowledge, and performance.
This week I got to see the job posting for a replacement of a colleague of mine. The first requirement was 3 years of experience with a product we don't even directly use. I'm pretty sure the only reason it's in there, is that HR requires it for working in our department, even tough our specific team doesn't even touch it. The same line also requires "Java, Java script", while it's a backend Java position with literally no JavaScript work.
I already told my manager that with the maximum wage (shown in the posting) and the listed requirements, none of my peers would even try to apply. Even if they were an extremely good fit for the actual job.
By the time they've taken your skillset, added the skills team lead would like or wants to learn, the skills that are from a different role but manager thinks can be combined few can still recognise their own job.
As a last pass CEO asks for 3 years experience of a tech launched last year that he's just finished reading an article about. :)
The worst is when it isn't engineers or any kind of technical leader performing any screening, but strictly an HR rep with no technical knowledge or experience outside of names of things (and the tools they personally employ) or an applicant tracking system that will immediately filter you out if your resume doesn't contain ~XX% of the required skills— or enough/too many years of experience according to the parameters in the posting.
And to so many people operating that way it just seems practical.
I feel lucky with how I got my current job— even though it's a very large company and they definitely do operate in those fashions, my resume somehow made it directly into the hands of the Senior Manager and Lead Engineer for the specific team at the time. They brought me in to talk— no whiteboards, no brain teasers— just some technical questions and personal/professional questions and I was hired inside of two weeks— onboarded a month later.
Applying and [if I even get to] interviewing at most other places previous has left me feeling much the same as yourself...
Every high performer at my workplace states regularly that they wouldn’t be able to pass the entrance exam at the place they currently work. It’s a cruel fucking environment.
In the last couple weeks I've had to decline 18 total hours of "challenges" and "work samples" from 4 different interview processes. I'm not sure at what point it became de rigueur to require applicants to complete on average 4.5 hours of work without pay, but I really, really don't think it's reasonable.
I've even offered to show them my current projects in lieu of work samples, and no go. Baffling.
I really don't get this interview process, and why it's so ubiquitous. I wouldn't care if an interviewee could pass a whiteboard fizzbuzz test if he/she provided some samples of projects they've done. That would tell me much more about your proficiency and methods.
I'd be much more interested in finding out if we would have a cultural fit. You can teach certain skills, but if your personality doesn't fit the culture it's going to be a bad experience for everybody.
But how do you determine if someone's a cultural fit without expending your time and their time? Just seems unavoidable to me, though that's what people often complain about here. Like they want to get a job without putting in any skin of their own.
https://hashrocket.com/ had a pretty extreme interview where they flew me out to Florida to pair-program with them for a week. It was a really pleasant experience. Every day I would pair-program with someone new on production code. By the end of the week I knew exactly if it was the job I was looking for. (Great group of people though and wish I'd known how to keep in contact with people professionally in my early 20s)
So unless everyone can afford to do that, you have to extrapolate from far more limited data.
Could you elaborate on how do you go about keeping in touch with people professionally. It’s a struggle for me to even keep in touch with friends. I guess I need to sustematize it somehow, because otherwise I just don’t keep in touch with anyone. I’m 30, so it’s an issue.
Me: "This project you've assigned me is asking me to implement a basic REST API with 2 endpoints. Well... you could take a look at my github profile, I have at least one project that includes a RESTful API considerably more advanced/complex."
Them: "We have to be fair to all candidates, so you need to implement the interview project like everyone else."
I've never had an employer short-circuit an interview process (as in skip some/all of the BS tech screening) based on having actual, real work samples available for review.
What was once a “more objective” way to hire has become a restriction by HR departments - they will not let anyone in unless you pass whatever the bar was, in the exact way that everyone else has taken it. Have seen this at a bunch of mid-enterprise companies.
On the contrary, when I was last looking for a job, I hit a snag in that a company wanted examples of current projects, but I had none because I don't really program outside of work
(I have other hobbies).
I wish I could add more to my anecdote, like how I solved this problem, but I avoided it entirely by taking a job offer from a different company the next day.
>I don't really program outside of work (I have other hobbies).
Oh, that's really no problem at all! Not everyone can just be at home in front of a computer all day, both at home and work, coding all day. What kind of a society would that lead to, haha. Anyway thanks for coming in, we'll be in touch.
Yep, also had that problem for years and finally saw something I could build with a reasonable chance of being useful, strictly to serve as an example. Hopefully it makes me the time back someday.
Funnily enough, nobody has asked to see it yet. They all want you to have side projects, but they don't actually want you to drone on about them for an hour. All this time I could have just been saying "Yes, let's talk about the intricacies of accounting for an hour, it'll be great" and passing that part of the interview through sheer aversive stimulus.
Once a potential employer baited me into writing a module that would determine a sentiment from given text and few more things. They liked what I did so they invited me to face 2 face interview. During the interview they had given me a task to integrate my code into their product's API and explain to his developers everything as I went along. I completed the task and their product's API has been enhanced. They thanked me and told me they'll give me a feedback in few days. After a week I got an email from them saying I am great, but I wouldn't be good cultural fit. Out of curiosity I checked their API month or so later and they had my code in production (or whatever left from what I did).
Have I got scammed?
Yea, I got tricked into doing something like that once. It is infuriating to see a new feature announced in a software product that's identical to an interview 'homework' assignment you had been given a month prior. "Wow, great solution! However, we've decided to go in a different direction..."
Whether they directly used my solution or gave that problem to several interviewees and picked the implementation they liked best I couldn't know. But I certainly felt used. There's a certain popular piece of software I refuse to use to this day because of my experience interviewing with them (fortunately, they have competition now).
Eventually you get to a point where your gut will tell you whether an 'interview project' is a toy problem or something that might actually be useful.
Bear in mind that if they didn't pay you, and there was no signed contract, they do not own your code. You may not be willing to hire a lawyer, but you could have some fun harassing them anyhow.
That said, do be sure it's your code... pretty much by definition, if you accomplished it during an interview, they could accomplish it in the same or less time themselves freshly and legally... for all you know, they'd already written it, just hadn't deployed it yet, and were using it as an interview question precisely because they had just written it themselves and it was fresh on their minds. Given the prevalence of NIH syndrome, this would even strike me as the most likely explanation unless you have some sort of really solid proof it's your code... generally, even when a programmer should take somebody else's two or three hour work they'd rather do it themselves!
There's some trade-offs here, because there does need to be some sense of how good a developer they are if you're hiring them as a developer: the distribution of skills is so broad at each "level" (junior, mid, senior, principal), and cultures so different you need some way of understanding if they really do have 5 years experience of LanguageX, or 3 months of it repeated 20 times...
What I prefer to do is ask them to show me some example code they think is "good" (ideally their own, but perhaps from an open source project), and some that is "bad" (ditto), and write a paragraph or two on _why_.
Colleagues prefer to ask people to do coding exercises, and that's fine, I won't criticise, I've done it before, but I hate the fact we are asking people to do toy problems that don't represent real World problems.
My favourite process that I don't get to do much now (I have to conform to somebody else's policies these days), is just to sit and talk through a candidate's favourite project or problem.
Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited.
Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.
And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.
All more useful to me and my assessment of somebody than asking them why manhole covers are the shape they are, how many windows there are in a nearby city or asking them to build a scaffold generated app that nobody would ever use.
> Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited.
> Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.
> And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.
I've seen your interviewing approach in action and it works brilliantly. This is pretty much a step-by-step of the way my last hiring manager interviewed and he never failed to build very strong dev teams.
If a company asks cookie-cutter questions and gives out cookie-cutter exercises to complete, then they shouldn't be surprised when they also make a number of bad hires that were just developers that knew how to pass these "tests".
On the other hand, as you say, if you sit down, ask them to talk about their experience, and shut up and listen, you're going to learn really quick if they are a BS artist or actually know what they're doing.
I also really like your idea of working through problems with the interviewer. I imagine it gives the interviewer some pretty important insight into how well the person breaks down a complex task into some semblance of an architecture, as well as how good they are at keeping such an architecture clean and simple.
The only time that sort of thing makes sense to me is for very high level positions, and then at the level of achieving a mutual vision for the direction of that department (or even the whole company for a C level hire).
For lower levels such work should be compensated, the best solution there is to do some actual work, get paid for it and then the company can make up its collective mind if they want to hire the candidate or not.
I was discussing this with a friend just last week. He too believes it is wrong to ask for a home assignment. But I have serious anxiety problems so I find whiteboard coding tests terribly difficult. Same thing with pair programming -- it's fine when you know the other person as colleague, but impossible for me in a "judgy" interview situation.
Agree. The discussion with my friend was actually sparked by the home assignment someone asked him to do. That was easily a 10-hour job. That's way too much. He correctly declined.
An 8 hour onsite interview costs me 8 hours and it costs the company 8 hours, so they're not likely to bother with it unless they think I'm in with a good enough chance to be worth the investment.
A 5 hour homework assignment costs the company nearly nothing, but it still costs me 5 hours. This means the company has no incentive not to waste my time.
No, no it would not be okay. A couple hours over a couple different days, followed by either contract to hire or a short paid sample is how I hire, if and when I do it.
There's no substitute for actually working with someone.
When you spend 5 hours on an assignment alone, stressed because you need a job & your time is short, only to not get a response after several email follow ups, you will see the logic.
I wouldnt do this for the same reason i worked at a gas station over taking an unpaid internship:
If the company isnt willing to make some investment in you, they arnt worth investing your time into.
B) for sure. i haven't had that used as an interview technique on me, but i've been on the interviewing end of that, and the feedback from the candidates was great. additionally, we felt it gave a great sense of what it'd be like to work with them, and based on the people we've hired so far using pairing as a component of the interview, it's a better predictor than anything else i've ever seen.
we also ask for a presentation on prior work or a prior project, we do some architecture whiteboarding, and we have talkier personnel type parts. but currently, the hour and change pairing exercise is the only programming exercise, and we were happy enough with the results last summer that we're doing it again for an upcoming round of interviews. our setup was a PM, a tech lead, and a "driver" (the person at the keyboard, which is what i was in the exercise). interviewee is the "navigator" (and by not having to type, we get rid of some of the stage fright for syntax errors and such, and just get to see their thought process since it's a pretty compressed timeframe). best microcosm of real work i've seen. one important thing is to give the same exercise each time (one possible risk in our case was that we gave the candidate 3 possible things to choose from, but settling on what we thought was the best choice was part of the test, and all the candidates ended up passing that part, so we never had to compare WIP from two different coding exercises).
apologies for rambling or repetition, dashing this off before i go to bed. but i'm a big fan of this interview approach, and i think it's probably the best thing we've hit on so far in this field, for positions where that would be a reasonable microcosm of what day-to-day work is like. i think it's much better than making someone code on a whiteboard, or giving them a take home or solo exercise, because you get so much more info about other things besides how well they can bang out a single well spec'ed piece of code.
We used to do C for open source stuff that we contributed to at our organization. Seemed like a good comprise because it isn't a completely futile exercise for the person going for the job.
> Cheaper than a bad hire, stops you missing out on good hires who think "fuck that".
Does it? If I have a developer job then I'm paid well and don't really care about the money which I have enough of, I care about the time which I have very little of.
If you're in the top 0.01% of companies to work for (and the applicant knows that) then it's probably a worthwhile time investment, but for the other 99.99% it's a waste.
If you are interviewing with a company, asking you to spend time in exchange for money is reasonable. If you feel you are above that exchange, personally, that is an effective filter for a potential problem employee.
> If you are interviewing with a company, asking you to spend time in exchange for money is reasonable.
These tests are typically a pre-interview step and they don't really work well for much apart from that. So at this point I'm not interviewing with the company and all I know is that they have an interesting job ad. Considering how far from reality job ads can be I'm not going to waste hours based on one.
In A both the interviewer and the interviewee are giving a similar amount of time. In C, only one is giving time. To compensate, the other should give money.
In C the interviewer is also spending time reviewing the assignment. Maybe not the same amount, but if you also have a handful of your current devs review it and give their feedback, the company time spent on it might not be trivial.
Also there is usually more than one person sitting with the interviewee when they come in, so the company time spent is multiplied at that stage.
The danger with pair programming is you easily get a partner who sees the activity as a competitive exercise / dick measuring activity* , and some engineers find enjoyment in proving to everyone else (including new hires) their superiority.
*excuse my language, but it is the most accurate description I could come up with.
i'd posit that if an employer can't find a decent pool of current employees to potentially pair program with an interviewee, they have deeper problems than getting that upcoming interview right, and need to correct for some past hiring mistakes ASAP.
i would definitely be looking for employment elsewhere if i my co-workers were so unpleasant that i thought they'd turn every pairing session into a pissing contest (and i say that as someone who generally prefers solo programming as far as immediate enjoyment goes, but who finds that pairing is often useful and/or necessary).
That's actually another reason why pair programming is good: The interview is just as much a signal to the candidate as it is to the employer. If the developer he's pair-programming with is a douche, it's a good sign for the candidate to run and not look back.
Idiots have a negative impact on any type of job search. I have been in interviews where I showed a valid solution for a problem but failed because it wasn't exactly the one the interviewer wanted. On the other hand if I did pair programming with somebody and it worked well this would be a strong indicator for a healthy comonay culture.
I'm in this situation myself and I'm quickly reaching my breaking point.
In one instance, I submitted an "exercise", which I spent ~six hours on, one week ago and haven't heard _anything_ back -- not even a confirmation that the submission was successful. I had been on the fence about following up, but fuck that, I'm going to do it right now. Thanks for the nudge. ;)
Last year a applied for an Android position at an up and coming Banking startup in London. Loved the company and what they were building, but their pre face-to-face interview process comprised of probably around 2 days of work if one were to finish it all.
It's almost as if they were trying to get me to build a whole feature for them for free, as it involved a complex UI that I knew they wanted to add into the Android app.
Maybe companies that want that level of work done in their code "tests" could offer a small amount of compensation. I had already been screened on the phone, so they knew I wasn't a time waster.
This has bitten me in the past. When I worked at a certain company, you had to do a full 8 hours of whiteboard coding in order to transfer laterally. So I was permanently stuck in the team that hired me, despite having the best possible performance reviews year after year. All because I can't think very well when I'm anxious and someone is looking over my shoulder judging me. I can solve algorithm problems just fine when I'm left to concentrate.
I'm going through it. My past self from 12 years ago would have cleared every one of those interviews. I don't believe for one second that that former self was a better Engineer. But it's hard to not feel anxious.
I learned my lesson. I took a job after working for 12 years as what for all intents and purposes was a junior developer (making a little bit more because wage stagnation is real). I've had 5 jobs since then and kept learning.
The hiring process has become part of the bargaining process- its job is not to proof your competence (Hey, i can memorize algorithms and T.S. Eliot poems) - but to negotiate your self-worth down so the company can hire you for cheap.
I've spent much of my career as a contractor and even before that I often changed jobs often early in my career since I had a good reputation in the industry I was in so I got approached often. You have to realise that it's a numbers game and it's not you, if a company overlooks you because they are not asking you the right questions then it's their loss. I often land in interviews at companies where their expectations are set by how young graduates see the industry and the role, which usually totally overlooks more experienced, professional and reliable candidates. I also now believe that the first interview I land won't lead to a job, since this has been true so many times. It helps, since I am probably a bit too nervous at my first interview in a while, but I also don't beat myself too hard over it and by the second place I interview at I am more relaxed. Also, don't write off jobs based on the job spec or the recruiter, actually upload your CV to a job site or apply for a lot of jobs advertised by agencies, even if it's not the best fit. It just warms up your job hunt nicely, you get used to talking to people outside of your company, you get used to articulating your strengths, passions and preferences and along the way you may discover a job that is a lot more suitable for you than you could have imagined.
I’m at a startup with about the same number of junior developers (which includes myself) to senior developers and I thought I was going to feel imposter syndrome but I haven’t felt it. I think it’s because we are a good team and ego isn’t there and we are working on really cool problems.
Years back I worked at a company called Red Gate for nearly 10 years. Latterly, old-timers at the company - including myself - used to joke that we'd never get through the present-day tech interview.
The impression was only heightened by a stint in recruitment where I realised, out of the hundreds of software engineer applications I was reviewing every month, >80% were rejected at first sift, and 80% of the rest were rejected at the coding assessment stage. If you actually made it to first interview there was a 40% chance you'd be offered a job, which is not terrible odds compared with where it had been. We'd hire about one out of every hundred applicants [1].
When it came time for me to move on I was, of course, terrified, because I hadn't updated my CV or gone for a job interview in 10 years, and I now knew from an insider's perspective exactly how ruthless the process can be.
[1] I did actually change the hiring process to try to give candidates a more humanised experience[2], but this didn't change the 100:1 ratio.
[2] Part of the motivation here was selfish: I realised that the way we had been doing it was making me short-tempered and miserable, and turning me into a worse human being.
Sure, I’ve been successful at this for 15+ years, delivering at or above expectations at almost 100% rate with some great individual excellence tossed in for good measure. But I am 99% sure I’d never pass an interview for a new job doing exactly what I do now. Am I even a software engineer developer programmer whatever?
It has been a very disconcerting experience.
Anyway, I figure the feeling of being an imposter is just a natural subconscious reaction to what seems like an entirely alien definition of what my job is vs. what other employers seem to expect from someone doing my job. I’m sure I’m not the only one who has noticed this disconnect as so many links/threads on HN allude to.
It certainly has given me a good deal of anxiety, though, I don’t really see what choice I have but to accept this nonsense and try to prepare for it. Luckily I haven’t been feeling any depression or burnout or any other obvious mood impact from the whole experience, but, I could see that happening if I had less confidence in my ability to fill in my knowledge gaps, even if it’s for nothing beyond an interview.