Ask HN: Is it possible to get pigeonholed to certain company sizes/cultures?
59 comments
A master's degree will not materially improve your employment prospects but will cost a lot of money and years of opportunity cost.
You should devote approximately one week to reading about how to interview better and practicing and then get as many interviews as you can at companies which are large enough to offer a competitive benefits suite. If I were in your situation I'd optimize for brand-name ones first, since the last name on your resume dominates people's impression of it. ("Worked for ten years at university IT departments and small software companies then Yelp" rounds to "ex-Yelp employee" according to basically every recruiter I've ever spoken to, and there are a lot of companies which round to Yelp.)
Even if one thought that one was below the supposed bar for large companies, they're sufficiently imprecise regarding interviewing that you have at least a 20% chance of an offer given ability to get onto a phone screen and pass the local version of FizzBuzz. Make it your mission to get failed out of their interview loop twenty times; it's virtually impossible.
P.S. One does not have to change one's personality to present differently for twenty minutes on a phone call if one believes that one's perceived personality is causing the phone rejections.
You should devote approximately one week to reading about how to interview better and practicing and then get as many interviews as you can at companies which are large enough to offer a competitive benefits suite. If I were in your situation I'd optimize for brand-name ones first, since the last name on your resume dominates people's impression of it. ("Worked for ten years at university IT departments and small software companies then Yelp" rounds to "ex-Yelp employee" according to basically every recruiter I've ever spoken to, and there are a lot of companies which round to Yelp.)
Even if one thought that one was below the supposed bar for large companies, they're sufficiently imprecise regarding interviewing that you have at least a 20% chance of an offer given ability to get onto a phone screen and pass the local version of FizzBuzz. Make it your mission to get failed out of their interview loop twenty times; it's virtually impossible.
P.S. One does not have to change one's personality to present differently for twenty minutes on a phone call if one believes that one's perceived personality is causing the phone rejections.
1 week isn’t enough for big companies. The person is 10 years out of college - 1-2 months would work a lot better.
>A master's degree will not materially improve your employment prospects but will cost a lot of money and years of opportunity cost.
I don't like "don't do it" advice without any compelling reasons. It is better for me to try and fail than to regret not having tried it. I am going to seek people who will support my desired path.
What if I wanted to work at NASA or Intel? Getting an internship from one of these companies is hard enough. But not impossible, and worthwhile building valuable connections from your internship for referrals to a full-time job.
But going to work there with no formal CS background, no inside referrals, with a non-STEM degree, with tenuous experience is much, much harder.
So there is my argument for wanting a higher education. At least I stated my argument.
I don't like "don't do it" advice without any compelling reasons. It is better for me to try and fail than to regret not having tried it. I am going to seek people who will support my desired path.
What if I wanted to work at NASA or Intel? Getting an internship from one of these companies is hard enough. But not impossible, and worthwhile building valuable connections from your internship for referrals to a full-time job.
But going to work there with no formal CS background, no inside referrals, with a non-STEM degree, with tenuous experience is much, much harder.
So there is my argument for wanting a higher education. At least I stated my argument.
> I don't like "don't do it" advice without any compelling reasons.
The compelling reasons 'patio11 offered were that it will cost a lot of money and years of opportunity cost. If you don't find those compelling, then that's your prerogative.
The whole NASA or Intel thing... I think you hit the nail on the head with "building valuable connections". I think you need to do this regardless of where you want to work. If you decide you want to work at one of these places or some place like it, make sure that you understand what is and is not required for the job. A certain degree may be required (explicitly), there may be age expectations (most likely illegal, but it happens), and/or there may be soft skills that you may not have yet and may never acquire (a very real requirement to get hired that is often overlooked by many people looking for specific jobs).
FWIW, 'patio11 has some high quality experience with the engineering hiring market and has written some seminal texts about it. Rather than blithely reject his advice (as you seem to do here), I humbly suggest that you engage with him in a more constructive way, perhaps by engaging with questions (e.g., about his thought process, about specific details on career direction that you failed to mention in your original post, etc.).
Also note, as a general rule, people with highly-informed and high-quality advice typically aren't looking for an argument, a debate, or (worse) a moving target of discussion -- you seem to have taken your reply one or more of these directions. The way you engage with people matters, and I wonder if this is a limiting factor of your career development.
Regardless, best of luck in your search. I hope you keep us updated with your status.
The compelling reasons 'patio11 offered were that it will cost a lot of money and years of opportunity cost. If you don't find those compelling, then that's your prerogative.
The whole NASA or Intel thing... I think you hit the nail on the head with "building valuable connections". I think you need to do this regardless of where you want to work. If you decide you want to work at one of these places or some place like it, make sure that you understand what is and is not required for the job. A certain degree may be required (explicitly), there may be age expectations (most likely illegal, but it happens), and/or there may be soft skills that you may not have yet and may never acquire (a very real requirement to get hired that is often overlooked by many people looking for specific jobs).
FWIW, 'patio11 has some high quality experience with the engineering hiring market and has written some seminal texts about it. Rather than blithely reject his advice (as you seem to do here), I humbly suggest that you engage with him in a more constructive way, perhaps by engaging with questions (e.g., about his thought process, about specific details on career direction that you failed to mention in your original post, etc.).
Also note, as a general rule, people with highly-informed and high-quality advice typically aren't looking for an argument, a debate, or (worse) a moving target of discussion -- you seem to have taken your reply one or more of these directions. The way you engage with people matters, and I wonder if this is a limiting factor of your career development.
Regardless, best of luck in your search. I hope you keep us updated with your status.
>The compelling reasons 'patio11 offered were that it will cost a lot of money and years of opportunity cost.
Your return on investment on a Masters CS degree will come over time.
For example, once you finish the degree, you should be in a better negotiating position in your current company when discussing promotions as you have demonstrated a willingness to follow through with personal development in service of the company.
If you lose your current job, having a CS degree is great future risk mitigation. While a portfolio and experience sounds good enough, you'd have to jump more hoops through HR without a CS degree. But once you have it you could get a job almost anywhere you want.
>FWIW, 'patio11 has some high quality experience with the engineering hiring market and has written some seminal texts about it.
This is important to know. However, I think it would be better of patio11 to open his comment by stating a short summary of this experience in order to lend more credence to his suggestions.
>there may be soft skills that you may not have yet and may never acquire
I'm curious about this. Especially on the "may never acquire" part. You mean that there are some soft skills that some people would never attain? That's interesting to me and I'd like to know why.
Your return on investment on a Masters CS degree will come over time.
For example, once you finish the degree, you should be in a better negotiating position in your current company when discussing promotions as you have demonstrated a willingness to follow through with personal development in service of the company.
If you lose your current job, having a CS degree is great future risk mitigation. While a portfolio and experience sounds good enough, you'd have to jump more hoops through HR without a CS degree. But once you have it you could get a job almost anywhere you want.
>FWIW, 'patio11 has some high quality experience with the engineering hiring market and has written some seminal texts about it.
This is important to know. However, I think it would be better of patio11 to open his comment by stating a short summary of this experience in order to lend more credence to his suggestions.
>there may be soft skills that you may not have yet and may never acquire
I'm curious about this. Especially on the "may never acquire" part. You mean that there are some soft skills that some people would never attain? That's interesting to me and I'd like to know why.
A few responses:
1. “Your return on investment on a Masters CS degree will come over time.” It might produce a positive ROI over time. It really depends on what you do, what you intend to do, and what you value.
2. Re: negotiation. Check out ‘patio11’s seminal text on this subject (other good articles on there as well): https://www.kalzumeus.com/2012/01/23/salary-negotiation/
3. Re: risk mitigation. A robust professional network is almost always more valuable and more resilient than a MS CS. I actually think that this is OP’s biggest opportunity/challenge.
4. Re: Summary of experience. I looked at your profile, and it seems like you’re relatively new here. ‘patio11 is one of HN’s most prolific posters. His posts have declined dramatically in frequency (due to work?) over the past year or so, but he is one of the grand hommes of HN. Check out this link: https://news.ycombinator.com/leaders. ‘patio11 is third, and that’s with a year plus of minimal commenting. Note that I have a very large scrapbook of smart things he has said in HN comments.
5. Remember that leader list, check out #1. ‘tptacek and ‘patio11 actually started a business together focused on the hiring of software engineers. It shut down for reasons unknown, but HN was (largely) rooting for them. It is still not entirely clear why they shut it down other than “hiring is broken” (i.e., employers claiming they want $TRAIT, but demure when a candidate with $TRAIT is presented to them, usually for something nebulous like an undeclared standard for culture fit). Anyway, both of these folks have a great deal of direct and indirect industry experience, and they have a habit of saying very smart things on a regular basis.
6. Re: soft skill limits. Short answer, cognitive biases. Slightly longer answer, first the problem needs to be acknowledged, and then — maybe — it can be solved. There are myriad psychological reasons (e.g, cognitive biases, mental disorders, etc.) for breakdown to happen at any step of this process. Is it possible to attain almost any soft skil, sure. Is it probable? Not for some people.
1. “Your return on investment on a Masters CS degree will come over time.” It might produce a positive ROI over time. It really depends on what you do, what you intend to do, and what you value.
2. Re: negotiation. Check out ‘patio11’s seminal text on this subject (other good articles on there as well): https://www.kalzumeus.com/2012/01/23/salary-negotiation/
3. Re: risk mitigation. A robust professional network is almost always more valuable and more resilient than a MS CS. I actually think that this is OP’s biggest opportunity/challenge.
4. Re: Summary of experience. I looked at your profile, and it seems like you’re relatively new here. ‘patio11 is one of HN’s most prolific posters. His posts have declined dramatically in frequency (due to work?) over the past year or so, but he is one of the grand hommes of HN. Check out this link: https://news.ycombinator.com/leaders. ‘patio11 is third, and that’s with a year plus of minimal commenting. Note that I have a very large scrapbook of smart things he has said in HN comments.
5. Remember that leader list, check out #1. ‘tptacek and ‘patio11 actually started a business together focused on the hiring of software engineers. It shut down for reasons unknown, but HN was (largely) rooting for them. It is still not entirely clear why they shut it down other than “hiring is broken” (i.e., employers claiming they want $TRAIT, but demure when a candidate with $TRAIT is presented to them, usually for something nebulous like an undeclared standard for culture fit). Anyway, both of these folks have a great deal of direct and indirect industry experience, and they have a habit of saying very smart things on a regular basis.
6. Re: soft skill limits. Short answer, cognitive biases. Slightly longer answer, first the problem needs to be acknowledged, and then — maybe — it can be solved. There are myriad psychological reasons (e.g, cognitive biases, mental disorders, etc.) for breakdown to happen at any step of this process. Is it possible to attain almost any soft skil, sure. Is it probable? Not for some people.
>A robust professional network is almost always more valuable and more resilient than a MS CS. I actually think that this is OP’s biggest opportunity/challenge.
You are actually right about that. I do not have a robust network. It could be a negative, but I also learn that you don't have to allow negative traits to define you, or your worth.
I have learned this from someone else who works as a software professional, who is bipolar and depressed. He also works at a fortune 500 making 6 figures, and takes on leadership responsibilities. He says that he hates himself, but loves his wife, and that despite being antisocial, it doesn't have to dominate him.
He also says his personality and social network does not affect his ability to work, and he works hard for his team. If he can do it despite his shortcomings, so can I. Dwelling on your negative qualities are a distraction, and incorrectly convinces you that your negatives have to commandeer your self-worth.
I will need to follow in this guy's footsteps. Forget about my lack of a network as something that defines me. I have to play to my strengths, and downplay my weaknesses.
You are actually right about that. I do not have a robust network. It could be a negative, but I also learn that you don't have to allow negative traits to define you, or your worth.
I have learned this from someone else who works as a software professional, who is bipolar and depressed. He also works at a fortune 500 making 6 figures, and takes on leadership responsibilities. He says that he hates himself, but loves his wife, and that despite being antisocial, it doesn't have to dominate him.
He also says his personality and social network does not affect his ability to work, and he works hard for his team. If he can do it despite his shortcomings, so can I. Dwelling on your negative qualities are a distraction, and incorrectly convinces you that your negatives have to commandeer your self-worth.
I will need to follow in this guy's footsteps. Forget about my lack of a network as something that defines me. I have to play to my strengths, and downplay my weaknesses.
If you got a phone screen from Amazon, et al, it means they saw your resume and thought your experience looked interesting. You were not filtered on the basis on your work history.
When these companies rejected you, it was almost certainly because of your interview performance, not your experience. The good news is that you can practice for interviews. There are many resources online. Good luck!
When these companies rejected you, it was almost certainly because of your interview performance, not your experience. The good news is that you can practice for interviews. There are many resources online. Good luck!
The feeling I get is that if my resume is good enough to get into the interviews, then it must be something about my presentation that has been conditioned from me due to working in smaller places. Like it could be something about the small company jobs might be making me talk differently about my job experience. And that could be turning off the big company hiring managers.
Kind of a like a farm guy trying to make small talk with someone who's only lived in a big city, it will be noticeable. It makes it harder for both people to find common ground. Does that make sense?
Kind of a like a farm guy trying to make small talk with someone who's only lived in a big city, it will be noticeable. It makes it harder for both people to find common ground. Does that make sense?
As someone who has participated in quite a few interviews for one of those big companies, it's doubtful that you're being pigeonholed because of your experience. However, one thing that I do see fairly frequently is candidates whose resumes look strong but, upon interviewing, show pretty strong evidence of "big fish, small pond" syndrome. That is, they performed well enough amidst their peers, but their peer group wasn't challenging them -- and they stagnated as a result, thinking that they knew more than they did. This often comes out during interviews when candidates speak confidently about solutions that are clearly sub-optimal without much apparent awareness of weakness, alternatives, and tradeoffs.
This has been a tough one in the past-interview discussion on many of the interview panels that I've been on. Given a bigger pond, would the candidate jump at the new opportunities and learn? Whether or not we decide to go that route often depends on a number of factors, both from the candidate and the current team dynamics (what's our internal junior/senior team ratio and what's our current mentoring needs/bandwidth?)
I have no way of knowing if this describes you, of course, but might at least be worth ensuring that during the interview you're not giving the above impression.
This has been a tough one in the past-interview discussion on many of the interview panels that I've been on. Given a bigger pond, would the candidate jump at the new opportunities and learn? Whether or not we decide to go that route often depends on a number of factors, both from the candidate and the current team dynamics (what's our internal junior/senior team ratio and what's our current mentoring needs/bandwidth?)
I have no way of knowing if this describes you, of course, but might at least be worth ensuring that during the interview you're not giving the above impression.
It sounds like your interview team is projecting their own biases onto the interview candidates. I have a hard time believing that you were able to unroll enough of the candidates' work experiences to arrive at your conclusions objectively.
I know this candidate too, and I've struggled with this hiring decision -- and I always tried to remain unbiased by reading as little as possible about the candidate before interviewing them (as in, don't even look at the resume). There's a certain lack of humility with always being the smartest person in the room in every conversation for several years that causes problems. Hell, I've been that guy in past lives.
FWIW, I've interviewed hundreds of people at major silicon valley companies. I wouldn't presume to diagnose someone's hiring biases (we all have them) without more data than you can find in a single HN comment.
FWIW, I've interviewed hundreds of people at major silicon valley companies. I wouldn't presume to diagnose someone's hiring biases (we all have them) without more data than you can find in a single HN comment.
That seems like a realistic interpretation to me, but nothing in particular about what you've written here is leaping out at me as an explanation, not that such a small sample would be terribly reliable anyhow.
You may want to see if you can find someone to meet in person to discuss this matter. Such things may only come out in person. Someone who has been in an interviewing position at a larger corporation would be ideal. You may have to troll some meetups or something for this, which isn't exactly a waste of time when it comes to trying to get a job anyhow, so it's efficient.
You may want to see if you can find someone to meet in person to discuss this matter. Such things may only come out in person. Someone who has been in an interviewing position at a larger corporation would be ideal. You may have to troll some meetups or something for this, which isn't exactly a waste of time when it comes to trying to get a job anyhow, so it's efficient.
" it was almost certainly because of your interview performance"
This will be a function of one's company culture.
FANGS have a pretty high operational bar that's sometimes hard to grasp from the outside, without internships, friends and networks of exposure.
BigCos have varying levels of professoinalism etc.
But both tend to have specific expectations that can be hard to grasp when from a smaller company.
At smaller companies I find people tend to generalize, and work on smaller projects obviously.
At BigCos there's much more opportunity for specialization, and sometimes huge codebases and if you've never worked on something like that it can seem unwieldy.
I think a frame of reference is important for setting interview expectations etc..
This will be a function of one's company culture.
FANGS have a pretty high operational bar that's sometimes hard to grasp from the outside, without internships, friends and networks of exposure.
BigCos have varying levels of professoinalism etc.
But both tend to have specific expectations that can be hard to grasp when from a smaller company.
At smaller companies I find people tend to generalize, and work on smaller projects obviously.
At BigCos there's much more opportunity for specialization, and sometimes huge codebases and if you've never worked on something like that it can seem unwieldy.
I think a frame of reference is important for setting interview expectations etc..
> FANGS have a pretty high operational bar that's sometimes hard to grasp from the outside, without internships, friends and networks of exposure.
Bingo. I think having an "inside" view of expectations is key to interviewing at these kinds of companies.
Bingo. I think having an "inside" view of expectations is key to interviewing at these kinds of companies.
Yeah, I truly agree with this. Couple the fact that I have a non-STEM degree and no internships. I picked up my first web dev jobs just from scouring Craigslist. Smaller companies that were open-minded enough to give a junior dev a shot. But I did stop using CL years ago and use better resources for job listings now.
So without any insider info on how big companies operate on a high level all the way down, outside of reading web articles or forum discussions, I have to put the pieces together on my own. My personal network is pretty diffused and fragmented, too. I know a person I met at a tech meetup years ago, he now works at Amazon. But he's too busy to reply and doesn't seem interested in being a referral.
As silly as it sounds I thought the small-to-big company would be the most logical career progression, as I even compare it to a music career at one point. In that you first have to produce and sell for an indie label before getting picked up by big shots such as Sony. But my reality is me spinning my wheels in the small co/startup circuit still waiting to "make it big".
So without any insider info on how big companies operate on a high level all the way down, outside of reading web articles or forum discussions, I have to put the pieces together on my own. My personal network is pretty diffused and fragmented, too. I know a person I met at a tech meetup years ago, he now works at Amazon. But he's too busy to reply and doesn't seem interested in being a referral.
As silly as it sounds I thought the small-to-big company would be the most logical career progression, as I even compare it to a music career at one point. In that you first have to produce and sell for an indie label before getting picked up by big shots such as Sony. But my reality is me spinning my wheels in the small co/startup circuit still waiting to "make it big".
> I have a non-STEM degree and no internships. I picked up my first web dev jobs just from scouring Craigslist. Smaller companies that were open-minded enough to give a junior dev a shot.
Given that, are you sure you're 100% on the technical side of interviewing...particularly algorithmic type questions? Whether you agree with the approach or not, they tend to be more common and given more weight with bigger companies.
Given that, are you sure you're 100% on the technical side of interviewing...particularly algorithmic type questions? Whether you agree with the approach or not, they tend to be more common and given more weight with bigger companies.
Amazingly, the only company in the tech hubs that has given me any algorithmic questions is Amazon. But I am not deluded enough to say I am 100% doing well on the technical side.
All the other companies with some reasonable amount of public exposure, (like Zillow, Coinbase, ArenaNet, to give a few examples) interviewed me on more holistic and technical concepts, such as how would you use an API to build a website, or how would you design a database, etc.
All the other companies with some reasonable amount of public exposure, (like Zillow, Coinbase, ArenaNet, to give a few examples) interviewed me on more holistic and technical concepts, such as how would you use an API to build a website, or how would you design a database, etc.
But bigger companies they are more willing to hire based on learning potential, correct? They can deal with the longer run of investing in an employee.
Quick learners can cross the Y-intercept of knowledge of those that know more but learn less quickly.
Quick learners can cross the Y-intercept of knowledge of those that know more but learn less quickly.
> operational bar
care to elaborate? or is this the soda fountain in the cafeteria?
care to elaborate? or is this the soda fountain in the cafeteria?
I dunno, I had no problem getting into big companies and excepting my current company (a FAANG), I have only worked for small companies in my whole career (almost 5 years of working at small companies).
The big things that seem to matter are your experience, and interview performance. People at big companies come from all walks of life as well as small companies, there really isn't that much of a difference in that regard. As someone currently interviewing candidates, I really don't care if someone worked for a small company or big one - I mainly care if someone made the most of that experience.
The big things that seem to matter are your experience, and interview performance. People at big companies come from all walks of life as well as small companies, there really isn't that much of a difference in that regard. As someone currently interviewing candidates, I really don't care if someone worked for a small company or big one - I mainly care if someone made the most of that experience.
Bounce your prepared interview answers off a wide variety of people you trust. This is not to get the perfect answer, but to get the impression you are giving off. I did this and I received some surprising reactions, sometimes contradicting opinions, all very informative.
As an example from myself, initially my answers were "too correct". If you tell someone what you think they want to hear, they pick up on that bullshit and they trust/respect you less. I then switched to more genuine answers, which has its own set of problems: sometimes people (mostly HR) actually do just want to hear the perfect answer, or they're judgmental and snobby about the genuine answer. However, at least I'm now actively deciding what impression I give.
Once you cut out the major errors in your interview answers, it just becomes a numbers game. After you interview with enough people, you'll just click with the right company.
As an example from myself, initially my answers were "too correct". If you tell someone what you think they want to hear, they pick up on that bullshit and they trust/respect you less. I then switched to more genuine answers, which has its own set of problems: sometimes people (mostly HR) actually do just want to hear the perfect answer, or they're judgmental and snobby about the genuine answer. However, at least I'm now actively deciding what impression I give.
Once you cut out the major errors in your interview answers, it just becomes a numbers game. After you interview with enough people, you'll just click with the right company.
Yeah, I don't consciously answer everything as how they want to hear. Nor do I want to. When I have a job interview, I just go to the interview. I've never done more than look up what the company does, and perhaps a quick refresh on basic algorithms.
That makes perfect sense, I think hiring managers and recruiters at large companies will want to hear that you are specifically looking to work in larger organizations. I also recommend spending time with employees of large organizations so that you can get a feel for how they communicate.
Whenever you're making a transition from one type of company to another, the hiring manager is going to be very concerned about whether you understand the kind of transition you're making, and are able to bridge that gap.
If you've been in an enterprise environment and are interviewing at a smaller company, they're going to be concerned that you're a hidebound cog who just sits there and waits for someone to tell them what to do (in triplicate), so they'll be looking for signs that you have initiative, that you don't think of things as "someone else's department," that you have the flexibility to roll with things that deviate from a strict process; if you've been at small companies and you're interviewing at larger ones, they're going to be concerned that you've just been ignoring all best practices and doing stuff with bubblegum and baling wire in a half-assed way.
My suspicion is that in those interviews, you didn't really allay those fears. Maybe you seemed impatient with process, maybe you came off like a cowboy, maybe you said things like "yeah, I know you're not supposed to make live code changes on production servers, but sometimes that's just the most effective way to get things done, you know?"
Or... maybe the company size thing is totally unrelated, and you just didn't wow them, who knows.
But it's not at all impossible to go between different types of companies, you just need to be aware of what's going to be different between them, and how you can be an asset to that type of company.
If you've been in an enterprise environment and are interviewing at a smaller company, they're going to be concerned that you're a hidebound cog who just sits there and waits for someone to tell them what to do (in triplicate), so they'll be looking for signs that you have initiative, that you don't think of things as "someone else's department," that you have the flexibility to roll with things that deviate from a strict process; if you've been at small companies and you're interviewing at larger ones, they're going to be concerned that you've just been ignoring all best practices and doing stuff with bubblegum and baling wire in a half-assed way.
My suspicion is that in those interviews, you didn't really allay those fears. Maybe you seemed impatient with process, maybe you came off like a cowboy, maybe you said things like "yeah, I know you're not supposed to make live code changes on production servers, but sometimes that's just the most effective way to get things done, you know?"
Or... maybe the company size thing is totally unrelated, and you just didn't wow them, who knows.
But it's not at all impossible to go between different types of companies, you just need to be aware of what's going to be different between them, and how you can be an asset to that type of company.
Hopefully I don't get downvoted, but here goes:
I've had the same job starting at a small startup, through growth and acquisitions, and I've been involved in hiring through the entire process.
Here's the dirty secret: startups try to be selective; but they're really desperate to hire. This is because startups are so mismanaged and risky that they have a lot of trouble getting someone competent to interview. When we were small, most people we interviewed were either incompetent or incapable of the challenge. Anyone competent got an offer.
As part of a mature organization, hiring is different. Most candidates can do the job, and actually want to work for us. (Unlike a startup, we now have good management and won't go out of business tomorrow.) Thus, we're more concerned with behavior.
My "competency test" interview has now evolved to more of a "tell me what I want to hear" interview. It's very effective, because almost all hires do the job well without wanting to perform useless refactoring because I didn't pick their favorite framework or brace style. It's also effective because I know I can communicate about higher level design topics.
I suggest, at a certain level, to just concentrate on telling your interviewers what they want to hear. This doesn't mean lying, or misrepresenting yourself. It just means that you need to understand who is in charge and play along with the same game everyone else is playing.
I'm also very clear about that when I interview a candidate. I now say something like: "This is a short interview and I try to ask questions that fit into the time. Some of the coding questions aren't real situations. The goal is to have a conversation about code, so if something is akward, just play along and do your best."
I've had the same job starting at a small startup, through growth and acquisitions, and I've been involved in hiring through the entire process.
Here's the dirty secret: startups try to be selective; but they're really desperate to hire. This is because startups are so mismanaged and risky that they have a lot of trouble getting someone competent to interview. When we were small, most people we interviewed were either incompetent or incapable of the challenge. Anyone competent got an offer.
As part of a mature organization, hiring is different. Most candidates can do the job, and actually want to work for us. (Unlike a startup, we now have good management and won't go out of business tomorrow.) Thus, we're more concerned with behavior.
My "competency test" interview has now evolved to more of a "tell me what I want to hear" interview. It's very effective, because almost all hires do the job well without wanting to perform useless refactoring because I didn't pick their favorite framework or brace style. It's also effective because I know I can communicate about higher level design topics.
I suggest, at a certain level, to just concentrate on telling your interviewers what they want to hear. This doesn't mean lying, or misrepresenting yourself. It just means that you need to understand who is in charge and play along with the same game everyone else is playing.
I'm also very clear about that when I interview a candidate. I now say something like: "This is a short interview and I try to ask questions that fit into the time. Some of the coding questions aren't real situations. The goal is to have a conversation about code, so if something is akward, just play along and do your best."
>startups try to be selective; but they're really desperate to hire
That is a paradox I am still trying to figure out LOL.
Ostensibly, startups are huge on culture fit. But also at the same time they want someone who knows a certain stack in and out, and can't attract those people all the time.
So startups and large companies are selective, in different ways?
And that is really gonna be a game changer for me, in turning my interview strategy into something that satisfies subjective needs.
I guess it's because so many candidates, as you say, can do the job because they perform well on an objective basis that larger companies have to reach into other less objective criteria to filter them out?
That is a paradox I am still trying to figure out LOL.
Ostensibly, startups are huge on culture fit. But also at the same time they want someone who knows a certain stack in and out, and can't attract those people all the time.
So startups and large companies are selective, in different ways?
And that is really gonna be a game changer for me, in turning my interview strategy into something that satisfies subjective needs.
I guess it's because so many candidates, as you say, can do the job because they perform well on an objective basis that larger companies have to reach into other less objective criteria to filter them out?
The hiring criteria of a large company isn't as subjective as you think. It just comes down to, "can you act like an adult and get along when you don't get your way?"
This isn't subjective at all! It just means that a technical interview is more than getting a correct answer; it also means that a technical interview is demonstrating that you can behave in a mature environment. That's why part of my interview turns into "tell me what I want to hear."
Because startups are horribly mismanaged, you can get away with certain forms of immaturity as long as you produce results. Larger companies don't put up with that.
This isn't subjective at all! It just means that a technical interview is more than getting a correct answer; it also means that a technical interview is demonstrating that you can behave in a mature environment. That's why part of my interview turns into "tell me what I want to hear."
Because startups are horribly mismanaged, you can get away with certain forms of immaturity as long as you produce results. Larger companies don't put up with that.
I'd like to be a fly on the wall on some "sample" in-person interviews to see what I have to do and how to do it.
Basically I ask some questions where the requirements are ambiguous, and the solution is non-standard. Other times I ask someone to write a simple task using an outdated API.
Why? Someone who can't figure out the ambiguous requirements will require a lot of handholding. I don't have time for that.
Someone who argues about the requirement to use an outdated API either doesn't get the point of the question, or will ask to refactor years of perfectly working code on the first day. The outdated outdated API goes through so many core concepts that it's an awesome interview question. Someone competent should move through it without any struggle!
Even worse is when I ask someone to write some manual SQL and they tell me that doing SQL by hand is outdated! Instant rejection! I want to know that you understand the underlying concept without relying on magic. Manual SQL is easy, if you're competent.
Or, I had someone tell me that passing values to a constructor in C# is outdated... Not when you're using immutables for thread safety!
That's what I mean by play along and tell the interviewer what they want to hear.
Why? Someone who can't figure out the ambiguous requirements will require a lot of handholding. I don't have time for that.
Someone who argues about the requirement to use an outdated API either doesn't get the point of the question, or will ask to refactor years of perfectly working code on the first day. The outdated outdated API goes through so many core concepts that it's an awesome interview question. Someone competent should move through it without any struggle!
Even worse is when I ask someone to write some manual SQL and they tell me that doing SQL by hand is outdated! Instant rejection! I want to know that you understand the underlying concept without relying on magic. Manual SQL is easy, if you're competent.
Or, I had someone tell me that passing values to a constructor in C# is outdated... Not when you're using immutables for thread safety!
That's what I mean by play along and tell the interviewer what they want to hear.
That sounds reasonable enough.
My last experience was more of a total non-adjustment to the actual candidate.
E.g. asking such bullshit vague questions that might work on a recent graduate because you could assume that's a software engineering 101 question but if you actually asked them what exactly they meant, even just the scope or language, or offering 3 different paths of which one you'd like to sketch out tot hem .. blank stare, repeating the question.
E.g. asking such bullshit vague questions that might work on a recent graduate because you could assume that's a software engineering 101 question but if you actually asked them what exactly they meant, even just the scope or language, or offering 3 different paths of which one you'd like to sketch out tot hem .. blank stare, repeating the question.
You should also look at this comment from https://news.ycombinator.com/item?id=17850955
"I could use this as a way into a discussion, and see how people carry themselves in such a (vaguely work-like) situation."
Looks like that poster has a very similar interview approach to me.
"I could use this as a way into a discussion, and see how people carry themselves in such a (vaguely work-like) situation."
Looks like that poster has a very similar interview approach to me.
Yes. It happens all the time and has certainly happened to me. I don’t have a simple answer.
It isn’t just small to big companies. I also had an problem moving from enterprise to a smaller web related company. In that case, I went back to college part-time and retrained. Hard work but it turned out ok.
I also did a series of government projects, which I really enjoyed, without thinking too much about it and then had a hard time moving away from that.
The truth is that whatever you do, someone is going to pigeonhole you. It is just human nature.
I try hard to build skills in what I want to do next and then try to work on projects that use those skills.
One other thing I did was to present papers at user group conferences – often about what I wanted to do in my next project!
It isn’t just small to big companies. I also had an problem moving from enterprise to a smaller web related company. In that case, I went back to college part-time and retrained. Hard work but it turned out ok.
I also did a series of government projects, which I really enjoyed, without thinking too much about it and then had a hard time moving away from that.
The truth is that whatever you do, someone is going to pigeonhole you. It is just human nature.
I try hard to build skills in what I want to do next and then try to work on projects that use those skills.
One other thing I did was to present papers at user group conferences – often about what I wanted to do in my next project!
I've interviewed people with your background and company sizes, and one general thing I've noticed is they are pretty good at their company stack and tools, capable of doing lots of things, can talk in depth about their previous work, and were successful in their jobs.
However, the drawback is bigger companies frequently want someone with experience to be a master of a few things, and less a generalist. Not defending it, but I've rarely seen a corporate hiring manager excited to hire an experienced dev based on them coming across as: "Oh I can learn anything! What do you need?"
If you have a bunch of companies on your resume that no one has heard of then it doesn't help. If you are getting interviews though then there are other factors at play that I think you are dismissing. Are you fluent in in-demand skills? Do you do side projects? Did you do interview prep, especially coding exercises? What would you say are your biggest strengths?
You probably need some capability of working with a team.
I'm going to assume you're a developer. Imagine working with a team of 5 to 10 developers. Plus a team of QAs. Plus a team of Ops. Plus a team of DBAs.
There's usually a process like working on code in a feature branch, passing it on for code review and then merging the feature branch into a development branch, where the QAs will deploy it to a staging server to check your changes (unless they deploy off the feature branch alone), and then eventually the development branch is merged to master for deploy to production.
So basically people aren't merging code to master or development out of the blue. People aren't typically sshing into production servers and changing code on the fly. Developers probably don't even get any access. And so on.
Anyways, not sure if you're already familiar with all that or if it gives you new insights into how working for a larger company might be different.
I'm going to assume you're a developer. Imagine working with a team of 5 to 10 developers. Plus a team of QAs. Plus a team of Ops. Plus a team of DBAs.
There's usually a process like working on code in a feature branch, passing it on for code review and then merging the feature branch into a development branch, where the QAs will deploy it to a staging server to check your changes (unless they deploy off the feature branch alone), and then eventually the development branch is merged to master for deploy to production.
So basically people aren't merging code to master or development out of the blue. People aren't typically sshing into production servers and changing code on the fly. Developers probably don't even get any access. And so on.
Anyways, not sure if you're already familiar with all that or if it gives you new insights into how working for a larger company might be different.
I would give you this advice:
Try to follow up with people that interviewed you, you might actually learn why you didn't make the cut. This might be harder with large companies, but even during the interview, a question like 'If this doesn't work out, I plan to apply again in 6 months or so, anything I should do in the meantime to have better chance of success' might tell you something you didn't already know.
Second, I heard that if you go through interviews, the chances to get a job can be quite low, I heard stories that went along the lines 100 applications -> 10 phone screens -> 1 onsite interview.
It might be easier going around meetups, open-houses or conferences and talking to people, you might learn about open positions that would fill sooner than they get to a public job-board :) Last job I got came from a conversation with a former high-school friend over a beer.
Try to follow up with people that interviewed you, you might actually learn why you didn't make the cut. This might be harder with large companies, but even during the interview, a question like 'If this doesn't work out, I plan to apply again in 6 months or so, anything I should do in the meantime to have better chance of success' might tell you something you didn't already know.
Second, I heard that if you go through interviews, the chances to get a job can be quite low, I heard stories that went along the lines 100 applications -> 10 phone screens -> 1 onsite interview.
It might be easier going around meetups, open-houses or conferences and talking to people, you might learn about open positions that would fill sooner than they get to a public job-board :) Last job I got came from a conversation with a former high-school friend over a beer.
Generally speaking, getting a job is about being & sounding like someone the interviewer(s) can relate with.
Let's say you work at a big company in an environment that does not prioritize testing. You are heading into an interview at a smaller startup that LOVES testing. When one of the startup interviewers asks you how you feel about testing, they want you to answer the question in a way that makes it sound like you'd be enthusiastic & competent at testing "all the things". If you say "I don't have time to write tests at work", you're almost certainly not going to get the job. If you say "I love testing, I write tests whenever I can, a certain employer I may or may not currently work for makes it hard to me to increase test coverage, and that's a factor in why I'm taking the time to interview with you", you're going to almost certainly get the interviewer's attention in a good way. The other part of selling yourself is that you, as far as this employer is concerned at least, really need to love testing.
Get it?
So what does it take for you to look & sound like the person who would get the job at Amazon, Cloudflare, or Coinbase? What does it take to be like what you sound need to sound like? Can you get that experience at work by taking initiative? For the experience you can't get at work, what can you do to get it outside of work? Do you need to buckle down and tear through Cracking The Coding Interview & LeetCode exercises? Do you need to work on a personal project that showcases the skills you can't develop at work? Figure those things out as best you can, push yourself super hard, and you'll get one of those shiny jobs that breaks you out of your current career paradigm.
Also, don't overlook the value of being really good at something people really need. That's a basic supply and demand thing. If you're a badass VB6 developer or MUMPS developer, those are simply not a hot skillset for almost any employer these days.
Let's say you work at a big company in an environment that does not prioritize testing. You are heading into an interview at a smaller startup that LOVES testing. When one of the startup interviewers asks you how you feel about testing, they want you to answer the question in a way that makes it sound like you'd be enthusiastic & competent at testing "all the things". If you say "I don't have time to write tests at work", you're almost certainly not going to get the job. If you say "I love testing, I write tests whenever I can, a certain employer I may or may not currently work for makes it hard to me to increase test coverage, and that's a factor in why I'm taking the time to interview with you", you're going to almost certainly get the interviewer's attention in a good way. The other part of selling yourself is that you, as far as this employer is concerned at least, really need to love testing.
Get it?
So what does it take for you to look & sound like the person who would get the job at Amazon, Cloudflare, or Coinbase? What does it take to be like what you sound need to sound like? Can you get that experience at work by taking initiative? For the experience you can't get at work, what can you do to get it outside of work? Do you need to buckle down and tear through Cracking The Coding Interview & LeetCode exercises? Do you need to work on a personal project that showcases the skills you can't develop at work? Figure those things out as best you can, push yourself super hard, and you'll get one of those shiny jobs that breaks you out of your current career paradigm.
Also, don't overlook the value of being really good at something people really need. That's a basic supply and demand thing. If you're a badass VB6 developer or MUMPS developer, those are simply not a hot skillset for almost any employer these days.
Then my goal, ostensibly, is to find a large company with interviewer(s) that are like and sound like me. Instead of trying to blend in, I will try the other approach. Try to find my "soul company" within the major big companies, so I don't need to artificialize myself. There are many big companies to choose from so it's very likely I just haven't found one who has a lot of people like me.
Would you say you have a specialization or are you more of a generalist?
Bigger orgs often tend to want specialists while early stage cos love generalists who can do a bit of everything.
Also, scale invites challenges that someone in companies of < 20 will not have encountered.
Hard to know without more specifics but sometimes comes down to the “different wars need different generals” mantra.
Bigger orgs often tend to want specialists while early stage cos love generalists who can do a bit of everything.
Also, scale invites challenges that someone in companies of < 20 will not have encountered.
Hard to know without more specifics but sometimes comes down to the “different wars need different generals” mantra.
In the first part of my career, I was usually told I was their second choice. But their number one pick chose another offer and I got that Fortune 500 job. So perseverance works.
Now a couple decades later, I have the problem that nobody believes anybody can be that good on the short offline tests. So I have to schedule skype interviews where the interviewers can see me and and verify that I know far more than they do.
The second problem is actually the more difficult problem to have, but there's a certain sense of accomplishment. I'll deal with it. :)
Now a couple decades later, I have the problem that nobody believes anybody can be that good on the short offline tests. So I have to schedule skype interviews where the interviewers can see me and and verify that I know far more than they do.
The second problem is actually the more difficult problem to have, but there's a certain sense of accomplishment. I'll deal with it. :)
I do not believe this is a thing. I've seen a lot of migration between company sizes.
I would, however, believe that you are presenting in such a way as to not harmonize with the expectations of the interviewer.
I've done a fair bit of interviewing on both sides of the table, with reasonable success - at least, I am mostly happy with it.
I am happy to talk to you 1:1 - email in profile.
I would, however, believe that you are presenting in such a way as to not harmonize with the expectations of the interviewer.
I've done a fair bit of interviewing on both sides of the table, with reasonable success - at least, I am mostly happy with it.
I am happy to talk to you 1:1 - email in profile.
Try getting a contract role with the type of company you’d like to join, then perform awesomely and be a great person to work with. If it’s a fit you’ll get converted to full time. Just be sure to target companies that are very actively hiring
Yes it can happen both ways: pigeonholed to small or large companies, but I don't believe you're stuck with it.
You might have a personal marketing problem, or you might have an interviewing problem.
Small companies can be great. I tend to think "startup" when I hear small company, but I think the same rules may apply. Your tech stack is probably more fluid and you can learn new technologies more easily. These are great skills to have. But... if you are not clear about what type of work you want to do and how your skills apply to that work, it is easy to turn off a larger company because they can't fit you into a role (a "box"). A good recruiter will try to shop you around the company a bit, but there's a limit as to how much time they are willing to spend doing that.
Story: I recently had a set of interviews for a large company (the recruiting process was a mess and a joke) where I was bounced from place to place and nobody (myself included) could figure out where I fit in the company. I feel that company was very tight lipped or unsure about the roles they were hiring for, so I had no better answer than "I'd be happy in either position" to which one of the hiring managers said I would be a better fit for a startup. I came into the process very wishy-washy about what I wanted. Considering this didn't happen with any of the other companies I applied to, I blame this company. Everything was secretive and somewhat adversarial. I ended up at a much larger company with a much better reputation.
Point: If you are not clear about what you want, you may get stuck in the small company loop.
The good news is that you are getting phone interviews at larger companies. Before you take an interview, research the company and its culture, don't just rely on what you know about the company. Focus on what you have accomplished at your companies, and not the tech stack you use. I've heard a lot of candidates tell me about the complexities of the open-source stack they've worked with, and that's great, but I want to know how they will help us in our mission. Those types of nitty-gritty answers would better fit smaller companies, in my opinion (unless I am specifically asking about how they did something).
Also, larger companies have a pretty standard interview process. Data structures/algorithms and coding phone interviews. You need to practice, practice, practice on Leetcode or some other platform and even re-read an algorithms book. Smaller companies tend to be more holistic and use take-home projects, have you participate in a hackathon, whatever, but to get into a larger company, you need to learn how to play the interview game rather than just being a great coder (irony intended).
You might have a personal marketing problem, or you might have an interviewing problem.
Small companies can be great. I tend to think "startup" when I hear small company, but I think the same rules may apply. Your tech stack is probably more fluid and you can learn new technologies more easily. These are great skills to have. But... if you are not clear about what type of work you want to do and how your skills apply to that work, it is easy to turn off a larger company because they can't fit you into a role (a "box"). A good recruiter will try to shop you around the company a bit, but there's a limit as to how much time they are willing to spend doing that.
Story: I recently had a set of interviews for a large company (the recruiting process was a mess and a joke) where I was bounced from place to place and nobody (myself included) could figure out where I fit in the company. I feel that company was very tight lipped or unsure about the roles they were hiring for, so I had no better answer than "I'd be happy in either position" to which one of the hiring managers said I would be a better fit for a startup. I came into the process very wishy-washy about what I wanted. Considering this didn't happen with any of the other companies I applied to, I blame this company. Everything was secretive and somewhat adversarial. I ended up at a much larger company with a much better reputation.
Point: If you are not clear about what you want, you may get stuck in the small company loop.
The good news is that you are getting phone interviews at larger companies. Before you take an interview, research the company and its culture, don't just rely on what you know about the company. Focus on what you have accomplished at your companies, and not the tech stack you use. I've heard a lot of candidates tell me about the complexities of the open-source stack they've worked with, and that's great, but I want to know how they will help us in our mission. Those types of nitty-gritty answers would better fit smaller companies, in my opinion (unless I am specifically asking about how they did something).
Also, larger companies have a pretty standard interview process. Data structures/algorithms and coding phone interviews. You need to practice, practice, practice on Leetcode or some other platform and even re-read an algorithms book. Smaller companies tend to be more holistic and use take-home projects, have you participate in a hackathon, whatever, but to get into a larger company, you need to learn how to play the interview game rather than just being a great coder (irony intended).
Out of the comments here so far, I really resonate with this the most.
In particular the paragraphs where you talk about how larger companies want you to be a specific fit for a role. I've noticed that a lot of times my enthusiasm for working at a company comes out like "put me anywhere you feel is best, I won't let you down!" and it never occurred to me that some managers don't like filling in a lot of the gaps themselves.
So if that comes across as being indecisive then it must be a clear sign that I do not know how I would fit in. Sometimes I do get a manager saying they want to hire for a specific department and I just roll with it. And when you describe your experience, then it sounds like going with a "just put me in wherever" attitude ironically makes you sound disinterested even if that was not the intention.
As far as studying up on the data structures/algorithm specifics, I've been around enough big company discussions to have realized it. I go against the common grain in that I actually prefer whiteboard interviews over take-home test projects, too. Because everything about the interview is transparent and both sides essentially invest the same amount of time and progress with it.
In particular the paragraphs where you talk about how larger companies want you to be a specific fit for a role. I've noticed that a lot of times my enthusiasm for working at a company comes out like "put me anywhere you feel is best, I won't let you down!" and it never occurred to me that some managers don't like filling in a lot of the gaps themselves.
So if that comes across as being indecisive then it must be a clear sign that I do not know how I would fit in. Sometimes I do get a manager saying they want to hire for a specific department and I just roll with it. And when you describe your experience, then it sounds like going with a "just put me in wherever" attitude ironically makes you sound disinterested even if that was not the intention.
As far as studying up on the data structures/algorithm specifics, I've been around enough big company discussions to have realized it. I go against the common grain in that I actually prefer whiteboard interviews over take-home test projects, too. Because everything about the interview is transparent and both sides essentially invest the same amount of time and progress with it.
Try consulting. It might be a transition that will give you the right mix of chaos and “get it done” while exposing you to bigco lingo and thought patterns.
Try asking for feedback on the rejections. Did you?
Yes. Most companies don't want to provide feedback due to liability reasons.
Only big exceptions are TripleByte and Enova. They told me that I come across as too "junior" in giving explanations despite my years of experience. The smaller companies are probably holding me back in career growth.
Only big exceptions are TripleByte and Enova. They told me that I come across as too "junior" in giving explanations despite my years of experience. The smaller companies are probably holding me back in career growth.
They told me that I come across as too "junior" in giving explanations despite my years of experience.
This is a really useful factoid for you. You should at least try reviewing one of your past performances for "opportunities to have sounded like a senior engineer" and then, during your next performance, dial that signal to parody levels.
If how to do this is not obvious to you, a trick: explicitly verbalize more of your reasons for not doing obvious alternate approaches. Bonus points if you can make those reasons sound like they were won by working on systems operating at scale.
This is a really useful factoid for you. You should at least try reviewing one of your past performances for "opportunities to have sounded like a senior engineer" and then, during your next performance, dial that signal to parody levels.
If how to do this is not obvious to you, a trick: explicitly verbalize more of your reasons for not doing obvious alternate approaches. Bonus points if you can make those reasons sound like they were won by working on systems operating at scale.
Disclaimer: You've only given us a few paragraphs to draw on, so we need to fill in the gaps and make some assumptions. You'll need to test whether those assumptions actually fit with who you are.
From your intro, my guess was that this would be a senior/junior mis-match. With 10 years of experience, employers will think of you as someone who should be a senior engineer, and they are likely to be evaluation you based on that expectation. That might be your expectation too - you didn't really say what sort of roles you were applying for, but if you're applying to "senior engineer" roles, then each company will have an implicit set of expectations about what a senior engineer can do. Some of those expectation might be made explicit in the role description, but many won't be. The role might talk about "mentoring junior developers" but there's an implicit expectation about the content of that mentoring - you have to know certain things in order to be able to teach others about them.
Those expectations will vary by company, and even by hiring manager. Some interviewers will think "A senior Java engineer must know spring+hibernate", but if you've spent your career working in the Hadoop ecosystem, then that's not likely to be true. Or "A senior engineer must understand the trade-offs of unit-testing vs integration-testing" (and be able to give the answer that they want to hear) but that's a question that is more relevant for certain project types, and not every engineer is going to have an opinion on that.
A likely problem here is that your 10 years of experience haven't given you the right set of skills to be able to answer their interview questions in ways that satisfy their (probably unreliable) interview filter. Maybe you really don't have those skills, or maybe you have them in some form, but not in a way that matches the interviewer's expectations.
Some time ago, when I was hiring into a medium/large bank, my expectations for a 10+ year engineer would be that you could be given a loosely defined problem, work your way through the details to understand the real task to be solved, design a solution (typically changes to be made to an existing system), implement and unit test that solution, assist in developing a system testing plan, assit in implementation, and understand the implications for support/operations. Each of those steps has a bunch of further detail that varies greatly by workplace, and interviews have "right answers" that assume you've done this enough times under similar enough conditions to be able to reach the same conclusions as they've reached.
As an anecdotal example. I remember hiring for a particular role, and one of the questions proposed a scenario where a particular business function was currently being driven from a spreadsheet, but they had outgrown that, and wanted to automate more of the workflow, and wanted to run a project to build a web-based internal system for that. How would you approach that? One of the candidates said something along the lines of "If they have a working spreadsheet, then I wouldn't want to change that. There's lots of risk in reimplementing it, so I would look at tools that could be used to put a web front end on top of the spreadsheet, and automate it that way." That was the wrong answer. It was a valid answer, and they explained why they wanted to take that approach, and "because risks" is somewhat reasonable, that team was not big on risk-taking. But whatever that candidate's experiences had been, they had led him to propose a solution that didn't fit with our expectations, and made what we considered to be the wrong trade-offs (and he persisted with that proposal even when we prompted him to go in a different direction). It's quite possible that some other company would say "Yes, that's exactly what we wanted to hear, you're hired!", but he wasn't the right person for us.
So - what's the solution?
You might try angling for a less senior role. It's hard when you have seemingly relevant engineering experience, to pitch yourself as a mid-level engineer, but you might need to find a way to do it. Then the expectations are lowered, you can get in the door, find out where your previous experience was leading you astray, and then be promoted to a senior role (or switch to a new company, now that you have the skills you need for the interview). You might need to trim your resume in the process so that you only mention the last 5 years of experience, and don't look too senior.
Alternatively, it might just be an interviewing issue. You might just need to translate what you do know from "small company" to "big company". Try something like https://interviewing.io/ and learn how to explain the skills you do have, in terms that big companies like.
--
edit: s/prompted/promoted
From your intro, my guess was that this would be a senior/junior mis-match. With 10 years of experience, employers will think of you as someone who should be a senior engineer, and they are likely to be evaluation you based on that expectation. That might be your expectation too - you didn't really say what sort of roles you were applying for, but if you're applying to "senior engineer" roles, then each company will have an implicit set of expectations about what a senior engineer can do. Some of those expectation might be made explicit in the role description, but many won't be. The role might talk about "mentoring junior developers" but there's an implicit expectation about the content of that mentoring - you have to know certain things in order to be able to teach others about them.
Those expectations will vary by company, and even by hiring manager. Some interviewers will think "A senior Java engineer must know spring+hibernate", but if you've spent your career working in the Hadoop ecosystem, then that's not likely to be true. Or "A senior engineer must understand the trade-offs of unit-testing vs integration-testing" (and be able to give the answer that they want to hear) but that's a question that is more relevant for certain project types, and not every engineer is going to have an opinion on that.
A likely problem here is that your 10 years of experience haven't given you the right set of skills to be able to answer their interview questions in ways that satisfy their (probably unreliable) interview filter. Maybe you really don't have those skills, or maybe you have them in some form, but not in a way that matches the interviewer's expectations.
Some time ago, when I was hiring into a medium/large bank, my expectations for a 10+ year engineer would be that you could be given a loosely defined problem, work your way through the details to understand the real task to be solved, design a solution (typically changes to be made to an existing system), implement and unit test that solution, assist in developing a system testing plan, assit in implementation, and understand the implications for support/operations. Each of those steps has a bunch of further detail that varies greatly by workplace, and interviews have "right answers" that assume you've done this enough times under similar enough conditions to be able to reach the same conclusions as they've reached.
As an anecdotal example. I remember hiring for a particular role, and one of the questions proposed a scenario where a particular business function was currently being driven from a spreadsheet, but they had outgrown that, and wanted to automate more of the workflow, and wanted to run a project to build a web-based internal system for that. How would you approach that? One of the candidates said something along the lines of "If they have a working spreadsheet, then I wouldn't want to change that. There's lots of risk in reimplementing it, so I would look at tools that could be used to put a web front end on top of the spreadsheet, and automate it that way." That was the wrong answer. It was a valid answer, and they explained why they wanted to take that approach, and "because risks" is somewhat reasonable, that team was not big on risk-taking. But whatever that candidate's experiences had been, they had led him to propose a solution that didn't fit with our expectations, and made what we considered to be the wrong trade-offs (and he persisted with that proposal even when we prompted him to go in a different direction). It's quite possible that some other company would say "Yes, that's exactly what we wanted to hear, you're hired!", but he wasn't the right person for us.
So - what's the solution?
You might try angling for a less senior role. It's hard when you have seemingly relevant engineering experience, to pitch yourself as a mid-level engineer, but you might need to find a way to do it. Then the expectations are lowered, you can get in the door, find out where your previous experience was leading you astray, and then be promoted to a senior role (or switch to a new company, now that you have the skills you need for the interview). You might need to trim your resume in the process so that you only mention the last 5 years of experience, and don't look too senior.
Alternatively, it might just be an interviewing issue. You might just need to translate what you do know from "small company" to "big company". Try something like https://interviewing.io/ and learn how to explain the skills you do have, in terms that big companies like.
--
edit: s/prompted/promoted
I'm curious what a correct answer to your interview question would look like - would you mind expanding on a plausible approach?
I just realized you already gave a very thorough list of your expectations. Thank you!
You're welcome, but I'm happy to at least elaborate on why that answer was a poor fit for us:
- It presumed that the existing spreadsheet would be flawless and bug-free. That is almost never the case; ad-hoc spreadsheets are often riddled with mistakes.
- It presumed that it would be a high risk/expensive task to replicate that spreadsheet in a technology that was more suitable for the job. Yet (if you assume that the spreadsheet was essentially correct in its function) it is one of the simplest implementations - you have a working specification for the behaviour you're implementing. If you are not confident in your ability to replicate a working spreadsheet, and then test that your new code behaves identically, then what are you going to be confident to build?
- It presumed that the technology used to automate the spreadsheet would replicate its behaviour faithfully. But that's only true if you use the same underlying application, so you'd only get the benefits if you automated Excel. If you used Open/LibreOffice, or Apache POI, or something similar then you still have all the risks that come with a reimplementation.
- It failed to account for the operational complexity of such a solution. Automating a spreadsheet is fragile. The resulting system would likely be a nightmare to operate.
- It failed to account for the long term maintenance cost of running a suite of business applications that are cobbled together from bits-and-pieces without any planning or cohesion. In that environment you should assume that an application will be in service for 7-10 years with the possibility of it running for 20 or more years. One of the biggest ongoing costs for that team was the number of bespoke applications we had, each using esoteric technologies and inconsistent design approaches. For example, a project to upgrade the underlying Operating System (or web browser, or database, or ...) would need to test each of those apps and potentially fix bugs. Which meant finding the source code, working out how to build it and package it, etc. Not to mention the cost of trying to stay on top of security patches for the underlying components and libraries. Consistency has massive value in that sort of environment.
You learn those lessons from experience - if your experience has been in a similar sort of working environment. I don't presume that every senior engineer has that same set of experiences and will agree on the same set of priorities and tradeoffs. But if I'm hiring you and paying a senior engineer salary because you have experience, then it needs to be experience that is applicable to the sorts of problems we face and the decisions we need to make.
- It presumed that the existing spreadsheet would be flawless and bug-free. That is almost never the case; ad-hoc spreadsheets are often riddled with mistakes.
- It presumed that it would be a high risk/expensive task to replicate that spreadsheet in a technology that was more suitable for the job. Yet (if you assume that the spreadsheet was essentially correct in its function) it is one of the simplest implementations - you have a working specification for the behaviour you're implementing. If you are not confident in your ability to replicate a working spreadsheet, and then test that your new code behaves identically, then what are you going to be confident to build?
- It presumed that the technology used to automate the spreadsheet would replicate its behaviour faithfully. But that's only true if you use the same underlying application, so you'd only get the benefits if you automated Excel. If you used Open/LibreOffice, or Apache POI, or something similar then you still have all the risks that come with a reimplementation.
- It failed to account for the operational complexity of such a solution. Automating a spreadsheet is fragile. The resulting system would likely be a nightmare to operate.
- It failed to account for the long term maintenance cost of running a suite of business applications that are cobbled together from bits-and-pieces without any planning or cohesion. In that environment you should assume that an application will be in service for 7-10 years with the possibility of it running for 20 or more years. One of the biggest ongoing costs for that team was the number of bespoke applications we had, each using esoteric technologies and inconsistent design approaches. For example, a project to upgrade the underlying Operating System (or web browser, or database, or ...) would need to test each of those apps and potentially fix bugs. Which meant finding the source code, working out how to build it and package it, etc. Not to mention the cost of trying to stay on top of security patches for the underlying components and libraries. Consistency has massive value in that sort of environment.
You learn those lessons from experience - if your experience has been in a similar sort of working environment. I don't presume that every senior engineer has that same set of experiences and will agree on the same set of priorities and tradeoffs. But if I'm hiring you and paying a senior engineer salary because you have experience, then it needs to be experience that is applicable to the sorts of problems we face and the decisions we need to make.
interviewing.io has been in private beta for months and I am still on the waiting list since March.
please email us at [email protected]
Yes
Elaborate?
What are some examples of this?
More importantly I want to know if you read the content of my post, and what are your thoughts on that content and your personal reflection of it.
What are some examples of this?
More importantly I want to know if you read the content of my post, and what are your thoughts on that content and your personal reflection of it.
I feel like I'm pigeonholed with only being able to be hired by very small companies. Fewer than 20 employees small. No fortune 500's, not even any full-time benefits or 401(k). They're very unstable too. I usually lose my job before I could get another one lined up. I had roughly $8000 in my bank account when I graduated and today, ten years later I have only about $400.
I want out of companies that constantly make me walk a tight rope of self-care. I want to ask am I pigeonholed? Because I cast a wide net with job applications, going to larger companies. Even some major ones like Amazon, Cloudflare and Coinbase have phone interviewed me. But they don't want to hire me. Like maybe these smaller companies are giving me a stigma.
Am I stuck in the small company loop forever? Unless I make some major lifestyle change like getting a master's degree or completely changing my personality it seems to be the case.
So what do you think about this sort of pigeonholing? Have you been pigeonholed in a similar sense whether stuck with large companies, small companies or anywhere in between?