Ask HN: Am I a software developer?
I've been writing software professionally for several years now. It's worked out fine. Lately I started interviewing for a new developer position at a few companies. All of them included various online developer tests where you have to write or debug code. I was bad at all of them. Some of them showed my score at the end, and it was abysmal. Have I been faking it all these years? Do the good candidates, heck, even the average candidates, manage to code answers to these online tests pretty decently? Maybe I am not a developer after all.
28 comments
If you have been generating value for a business through software you have developed you are clearly a software developer.
Several things can be happening :
* The companies you are applying for are testing for software developers with a different skill set ;
* The companies you are applying have bad interview process and can't test for software developers that would generate money for them.
Interview is broken in software in general I think.
Several things can be happening :
* The companies you are applying for are testing for software developers with a different skill set ;
* The companies you are applying have bad interview process and can't test for software developers that would generate money for them.
Interview is broken in software in general I think.
Here is a tip for you - line up as many interviews as you can from companies you aren't necessarily super jazzed about. Take a full month and go through all the painful process. You will probably fail a lot, at least for the first month or so. It depends on your availability, if you can line-up 2 to 3 interviews per week that would be ideal. Then when you're done interviewing for a while with these "whatever" companies, start applying at your favorite ones.
I found out that putting 2 months of preparation reading books, practicing on your own, etc. is not relevant enough. Chances are, you will get questions that aren't directly related to what you've studies. Another thing I found out is that interviewers ask the same coding questions and this happens very often! ta-da!! You know where I'm going?
After a month interviewing, you'll have a chance to think about all the questions you've been asked, then you'll be able to come up with an answer next time. You'll be surprised when you'll start getting the exact same questions over and over. Don't study on your own, involved companies and real interviewers in your practice. Jump straight into the interview process and take a lot of notes ;)
I found out that putting 2 months of preparation reading books, practicing on your own, etc. is not relevant enough. Chances are, you will get questions that aren't directly related to what you've studies. Another thing I found out is that interviewers ask the same coding questions and this happens very often! ta-da!! You know where I'm going?
After a month interviewing, you'll have a chance to think about all the questions you've been asked, then you'll be able to come up with an answer next time. You'll be surprised when you'll start getting the exact same questions over and over. Don't study on your own, involved companies and real interviewers in your practice. Jump straight into the interview process and take a lot of notes ;)
Agreed, I took notes after every interview (bombed on several in a row, like the OP), then collated common questions and prepared brief, positive, well-written answers. I went from failing every interview to acing every interview, many would say things like "that's the best answer we've heard" or "that's a very thoughtful response", well, I spent hours preparing them, unlike most other candidates!
great thing about phone interviews is they won't know that you are reading from a script! Writing them and repeating them also helped me memorize them enough for in-person interviews.
It also calms the nerves to feel so well prepared.
great thing about phone interviews is they won't know that you are reading from a script! Writing them and repeating them also helped me memorize them enough for in-person interviews.
It also calms the nerves to feel so well prepared.
Honestly, I found the books (eg; Cracking the Coding Interview) to be decent at giving a quick overview.
At the end of the day, doing a bunch of medium difficulty and some hard difficulty questions on leetcode proved to be the best preparation. By the time you get to your interviews, you've probably seen a variation on what they're asking. I didn't find doing more interviews to be much more helpful than just doing a bunch of practice questions (if you're already good at interviewing in general).
Still, I think this garbage is annoying for senior developer positions or once you're at least a few years out of school. Having to practice implementing a topo-sort in 10 minutes or doing some tedious combinatorial problem gives zero insight into good software engineering practices. System design questions, on the other hand, are actually useful.
At the end of the day, doing a bunch of medium difficulty and some hard difficulty questions on leetcode proved to be the best preparation. By the time you get to your interviews, you've probably seen a variation on what they're asking. I didn't find doing more interviews to be much more helpful than just doing a bunch of practice questions (if you're already good at interviewing in general).
Still, I think this garbage is annoying for senior developer positions or once you're at least a few years out of school. Having to practice implementing a topo-sort in 10 minutes or doing some tedious combinatorial problem gives zero insight into good software engineering practices. System design questions, on the other hand, are actually useful.
Indeed, I'd be fine if it was only one algo question in the whole process. Unfortunately we're talking about one, sometimes 2 technical phone screens. Then 4-5 tehnical interviews onsite. You have to deal with data structures/algo crap the whole time (30 minute each) which is not only painful, but it's extremely annoying and pointless.
Regarding books vs real world practice - I came a lot more confident by going through the process a few times talking to real interviewers. It's not only you and your laptop and zero stress. This make a big difference in boosting your confidence level.
Regarding books vs real world practice - I came a lot more confident by going through the process a few times talking to real interviewers. It's not only you and your laptop and zero stress. This make a big difference in boosting your confidence level.
If this is referring to codility, don't worry. Codility is extremely poor at writing its requirements for the problem it wants you to solve. They're extremely technical requirements, and there is no one to direct your questions to. I was interviewing for a company that did that and I thought the exact same thing.
I consistently received failing grades with little to no explanation, the tests weren't descriptive. I chalk it up to codility sucks. Don't get down on yourself. one of the problems, the ONLY solution is a bitwise XOR
for num in nums: var a ^= num
kind of thing. That is the ONLY answer. But they don't clearly describe the optimization they're looking for in that problem either. In my opinion, the only way one could have known how to solve this is if they already knew about bitwise operands at a deep level. Which 99% of all code ever written will never use.
In other words, I don' think it's any kind of commentary on your skills, but rather poor questioning, and structure of codility, if we're talking about codility, which I think we are.
I consistently received failing grades with little to no explanation, the tests weren't descriptive. I chalk it up to codility sucks. Don't get down on yourself. one of the problems, the ONLY solution is a bitwise XOR
for num in nums: var a ^= num
kind of thing. That is the ONLY answer. But they don't clearly describe the optimization they're looking for in that problem either. In my opinion, the only way one could have known how to solve this is if they already knew about bitwise operands at a deep level. Which 99% of all code ever written will never use.
In other words, I don' think it's any kind of commentary on your skills, but rather poor questioning, and structure of codility, if we're talking about codility, which I think we are.
I also recently had a terrible codility test. I had stuff that would run partly on my machine but would throw other errors on their submission. And it was 4 data structure final exam type problems that were just mentally exhausting - I was interviewing for front-end!
How is this answerable with the information provided?
Good point.
It's not.
The point is to make OP feel better in the ensuing rants against technical interviews.
My advice to OP would be to understand that tech interviews, like all standardized testing, are something to be gamed (practice makes perfect).
You can rant all you want, but you will have little power to change it as a random applicant.
Just game it, and move on.
The point is to make OP feel better in the ensuing rants against technical interviews.
My advice to OP would be to understand that tech interviews, like all standardized testing, are something to be gamed (practice makes perfect).
You can rant all you want, but you will have little power to change it as a random applicant.
Just game it, and move on.
One should be careful to not go public about this intent (to game it). Someone had dedicated blog about his studies, preparations for BigG interview, he was reject right away without even a phone call... This story was on HN.
Yeah, I remember that.
When I say game, I mean: practice questions you can expect to get (a little googling will help).
To think anyone would get through those interviews without prepping is ridiculous. Google specifically actually tells you to prep and what things to practice.
And also, since so many people do prep, the bar for acceptable performance is much higher than it would otherwise.
At this point, I'm not sure what these interviews are supposed to be measuring.
When I say game, I mean: practice questions you can expect to get (a little googling will help).
To think anyone would get through those interviews without prepping is ridiculous. Google specifically actually tells you to prep and what things to practice.
And also, since so many people do prep, the bar for acceptable performance is much higher than it would otherwise.
At this point, I'm not sure what these interviews are supposed to be measuring.
> I'm not sure what these interviews are supposed to be measuring.
I guess the level of dedication/passion of how much one wants to get a job there... That's seems the only "reasonable" explanation so far :)
I guess the level of dedication/passion of how much one wants to get a job there... That's seems the only "reasonable" explanation so far :)
Can someone shared the URL to the said HN story where someone was rejected right away even with a phone call for blogging about studies and preparations for BigG interview?
They might be getting confused with the person who blogged about their interview prep and ended up not getting an offer. I find it almost impossible to believe that Google would reject someone because they spent time and energy preparing for their interview process--they provide pretty detailed information about how to prepare and it's common knowledge.
Actually making it through an interview and getting an offer is much less common, for (what I'd consider) obvious reasons.
I interviewed at Google without any preparation and was not given an offer. I would have liked to have the time to prep, but I didn't, and I assumed I would not get an offer. I didn't do horribly, and I was encouraged to prep and return. I believe I'm good enough that if I prepped I'd get an offer--I simply don't have the time to jump through those particular hoops at this time, for better or worse.
Actually making it through an interview and getting an offer is much less common, for (what I'd consider) obvious reasons.
I interviewed at Google without any preparation and was not given an offer. I would have liked to have the time to prep, but I didn't, and I assumed I would not get an offer. I didn't do horribly, and I was encouraged to prep and return. I believe I'm good enough that if I prepped I'd get an offer--I simply don't have the time to jump through those particular hoops at this time, for better or worse.
No, that person didn't even get a phone call... Just a generic rejection without any interviews.
What type of software/applications have you been writing professionally?
How does this compare to the software/applications in the code tests?
How does this compare to the software/applications in the code tests?
> I've been writing software professionally
Yes, you are a developer. Are you a good developer or bad?
If your users are pretty happy with your results, maybe you are good.
> various online developer tests where you have to write or debug code. I was bad at all of them.
This can be learned. Are you willing learn? This is the crux. If you want to progress, you have to study at what you got wrong. You have to take your feedback (e.g. the developer tests you took) and find out what it would take to pass them with flying colors.
If, instead, you expect to pass them without putting extra effort, or correcting yourself, then I'm afraid you are a bad developer.
I've worked with developers who, when faced with criticism (guidance, really) just get red in the face and double down on whatever ineffective strategy they were using to begin with. And later they get even more red in the face because they spent so much effort doing the wrong thing instead of what they were advised to do.
Yes, you are a developer. Are you a good developer or bad?
If your users are pretty happy with your results, maybe you are good.
> various online developer tests where you have to write or debug code. I was bad at all of them.
This can be learned. Are you willing learn? This is the crux. If you want to progress, you have to study at what you got wrong. You have to take your feedback (e.g. the developer tests you took) and find out what it would take to pass them with flying colors.
If, instead, you expect to pass them without putting extra effort, or correcting yourself, then I'm afraid you are a bad developer.
I've worked with developers who, when faced with criticism (guidance, really) just get red in the face and double down on whatever ineffective strategy they were using to begin with. And later they get even more red in the face because they spent so much effort doing the wrong thing instead of what they were advised to do.
What were some of the questions that you struggled with? Most of the time interview questions are pretty awful and have nothing to do with real life problems, which you might be really good at solving. Keep your head up, keep looking and things will work out.
Being able to pass a job interview can require different skills than actually doing the job. So it is more accurate to say that you are a bad interviewer. The standard advice is:
- get Cracking the Code Interview
- practice it for a couple months
- practice using a whiteboard and other problematic areas
- get Cracking the Code Interview
- practice it for a couple months
- practice using a whiteboard and other problematic areas
I've been through this myself, being told "You're not a real developer" earlier in my career. At that time I was very junior and doing essentially maintenance (bug fixes and adding new features) to a C++ cross-platform client/server application.
But for myself it boils down to this standard: Can I write programs to accomplish my own goals? And the answer to that is yes. I might use an older technology or an older stack but I can certainly get done what I need to get done.
Labels aside, when I need a program to accomplish a goal, in any programming language, I can do it.
But for myself it boils down to this standard: Can I write programs to accomplish my own goals? And the answer to that is yes. I might use an older technology or an older stack but I can certainly get done what I need to get done.
Labels aside, when I need a program to accomplish a goal, in any programming language, I can do it.
I've found that some companies when they interview they send you a challenge that doesn't represent a real world scenario and it takes a different type of skill than real world skills.
If that's the case the only way to get better at it is by practicing, do leetcode questions and refresh your A&DS knowledge.
If the challenge was a real world scenario and you failed maybe was in an area you don't have much experience with. That's normal, nobody nails the 100% of the interviews they give.
If that's the case the only way to get better at it is by practicing, do leetcode questions and refresh your A&DS knowledge.
If the challenge was a real world scenario and you failed maybe was in an area you don't have much experience with. That's normal, nobody nails the 100% of the interviews they give.
I think that these kind of tests are only fit to decide if you're a coder or a monkey. As a matter of fact I think that being able to solve riddles in code is only a small part of being a developer.
I once was subjected to a hastily organised test once. I felt it was degrading and I also felt having a good conversation with a fellow developer would be much more efficient in determining what the real level of an applicant is.
I was once in an interview for a $180-$250+ (cash, no fancy stocks) job and was first (compared to 100 remote devs from around the world) on the tech-interview with 3 simulatenous people ( had a headache after the ~90 minute interview, and today i've been programming for 11 hours and feel fine) and failed spectacularly at the next stage. So it can happen.
I've also failed most of those online tests.
I've also failed most of those online tests.
How can we tell you if you don't post examples? I have met examples of both persons who are bad at whiteboard pressure tests but also brilliant at software development, and other self-professed software developers who were good at Job Interviewing but bad at thinking about software. You just have to ignore your emotions and compare yourself to others objectively!
Do the first 50 problems on projecteuler. they're fairly easy (compared to the other problems). it'll take you a day or two. or maybe a week, if you're really weak at that kind of thing. afterwards, you will ace all the stupid online tests.
Most engineers suck at technical interviews. Because interviewing is a separate skill that must be learned and practiced. So yes, you are an engineer, but you need to take some time and prepare for technical interviews before you go onsite. Search Google and quora you'll find lots of resources and stories.
> Maybe I am not a developer after all.
Maybe you are a developer, but just an extremely mediocre one.
Someone has to account for the lower end of the bell curve. Maybe you're one of them.
Based on the information you provided, I think this is the most likely answer to your question.
Maybe you are a developer, but just an extremely mediocre one.
Someone has to account for the lower end of the bell curve. Maybe you're one of them.
Based on the information you provided, I think this is the most likely answer to your question.
To answer that question first you have to know what happens inside many of these companies. Its just too complex to come up with a process that is fair to everyone.
There is a lot of overlap into different roles in this field
Programmer
Developer
Software Engineer
Web Developer
Full stack engineer
Backend Engineer
Frontend Engineer
Software Design Engineer
DataScience Engineer
There is no standard or a clear definition of these roles or the skills you need for these roles or skills relevant to particular company. Not all companies have a clear cut hiring standards or insight into what kind of people they should be hiring. Hiring is overshadowed by a lot of players who are just following process. Most of them search in google to figure out a perfect recruiting approach or just want to one-up the popular company hiring approach. They are easily convinced by "tech hiring done right consultants" or their SEO tailored blogs, who actually are good at selling their services. The interviewers in the loop do a google search to figure out what to ask and it does not occur to them if it is relevant or not, its just what other big companies ask in an interview. At the end it is left to un-empowered hiring managers, many times also dev managers who are afraid of breaking tradition and have to make a better decision in a bad situation.
If you ask a web developer a lot of algorithmic questions, the candidate fails and a candidate who "cracks" your algorithmic interview is most likely to fail at front end web development job. Design skills are as important as algorithmic skills and they need constant improvement just like programmers improve, who decides what level of design skills are needed for this role?. For a web developer there is a decent amount of algorithmic thinking necessary but who determines that for your company or team? From my personal experience, I needed someone who knows a couple of javascript frameworks and can make sure things look good. The company did not have a role as "web developer" and they choose to call him "software developer" and paid him at the same scale. After a year, the person was transferred to a different team that did not value his skills and the company thought it was too expensive to retrain him.
Most management at mid sized companies want to see tech people as lego blocks/building blocks who can be transferred to a different team or project/product on demand. There is a preference for generalist programmer who sort of can do web development/app development/ data science/machine learning/AI etc on demand. It is kind of good and bad because many people get bored after sometime and want to do something else at their job and would like it if a company allows them to transfer.
A lot of companies I know tried the tailored approach where they let the teams decide who they hire but the problem is lot of the team members are unskilled at making hiring opinions outside their area of work, they mimic the Hippo(highest paid person opinion) in the room. People with other skills can make the team/product better but many hiring teams do not have that self-intuition and mostly hire someone like themselves. There is also a conflict between hiring for known chunk of work already planned vs hiring for longterm with skills to solve vague problems related to a specific field. The same hiring approach does not work for both the cases.
To deal with this complexity, many big companies come up with a process that looks like standardized testing. Hire hardworking people who can deal with really hard problems and solve very complex math/computer science problems and have spent enough preparation time learning the literature. Kids who are very good at school can easily get through this tests. This will become a new normal to them. Also the standardized testing approach gives the companies immunity from gender/race discrimination complaints.
The fact that these smart people seem to be unhappy everywhere and have to change companies every 9 months tells you that not everyone needs to write MonteCarlo Markov Chain likelihood estimators with Bayesian inference in python. Your average CRUD app may not be able to keep them happy no matter how much PR you give this product. There is a need to tailor these interviews with time. Its a constantly improving process.
I was watching this documentary on notorious gangs. The common way to get into that gang was always designed to be very hard. One approach was they throw this new wannabe gangster down and 5-10 people start kicking this guy brutally and after 10/15 mins if this guy survives with out crying/screaming/giving up then they will admit this person into the gang. It was psychologically important for the gang to recruit only the toughest people and at the same time it was important for the person to mentally go through that rigorous process and beat it which after "winning" creates a psychological bond and loyalty with the brand of the gang and a sense of earning that respect from the gang. Our tech interviews sounded very similar to the recruiting done by these notorious gangs. So lets just say that this kind of whiteboard interviewing evolved in nature.
For lack of better ideas, this is going to be new normal. Spend significant time and get comfortable dealing with whiteboard/standardized tests. The alternative is networking and referrals where some managers in few companies can bypass the hiring process and hire you if they like what you have to offer.
There is a lot of overlap into different roles in this field
Programmer
Developer
Software Engineer
Web Developer
Full stack engineer
Backend Engineer
Frontend Engineer
Software Design Engineer
DataScience Engineer
There is no standard or a clear definition of these roles or the skills you need for these roles or skills relevant to particular company. Not all companies have a clear cut hiring standards or insight into what kind of people they should be hiring. Hiring is overshadowed by a lot of players who are just following process. Most of them search in google to figure out a perfect recruiting approach or just want to one-up the popular company hiring approach. They are easily convinced by "tech hiring done right consultants" or their SEO tailored blogs, who actually are good at selling their services. The interviewers in the loop do a google search to figure out what to ask and it does not occur to them if it is relevant or not, its just what other big companies ask in an interview. At the end it is left to un-empowered hiring managers, many times also dev managers who are afraid of breaking tradition and have to make a better decision in a bad situation.
If you ask a web developer a lot of algorithmic questions, the candidate fails and a candidate who "cracks" your algorithmic interview is most likely to fail at front end web development job. Design skills are as important as algorithmic skills and they need constant improvement just like programmers improve, who decides what level of design skills are needed for this role?. For a web developer there is a decent amount of algorithmic thinking necessary but who determines that for your company or team? From my personal experience, I needed someone who knows a couple of javascript frameworks and can make sure things look good. The company did not have a role as "web developer" and they choose to call him "software developer" and paid him at the same scale. After a year, the person was transferred to a different team that did not value his skills and the company thought it was too expensive to retrain him.
Most management at mid sized companies want to see tech people as lego blocks/building blocks who can be transferred to a different team or project/product on demand. There is a preference for generalist programmer who sort of can do web development/app development/ data science/machine learning/AI etc on demand. It is kind of good and bad because many people get bored after sometime and want to do something else at their job and would like it if a company allows them to transfer.
A lot of companies I know tried the tailored approach where they let the teams decide who they hire but the problem is lot of the team members are unskilled at making hiring opinions outside their area of work, they mimic the Hippo(highest paid person opinion) in the room. People with other skills can make the team/product better but many hiring teams do not have that self-intuition and mostly hire someone like themselves. There is also a conflict between hiring for known chunk of work already planned vs hiring for longterm with skills to solve vague problems related to a specific field. The same hiring approach does not work for both the cases.
To deal with this complexity, many big companies come up with a process that looks like standardized testing. Hire hardworking people who can deal with really hard problems and solve very complex math/computer science problems and have spent enough preparation time learning the literature. Kids who are very good at school can easily get through this tests. This will become a new normal to them. Also the standardized testing approach gives the companies immunity from gender/race discrimination complaints.
The fact that these smart people seem to be unhappy everywhere and have to change companies every 9 months tells you that not everyone needs to write MonteCarlo Markov Chain likelihood estimators with Bayesian inference in python. Your average CRUD app may not be able to keep them happy no matter how much PR you give this product. There is a need to tailor these interviews with time. Its a constantly improving process.
I was watching this documentary on notorious gangs. The common way to get into that gang was always designed to be very hard. One approach was they throw this new wannabe gangster down and 5-10 people start kicking this guy brutally and after 10/15 mins if this guy survives with out crying/screaming/giving up then they will admit this person into the gang. It was psychologically important for the gang to recruit only the toughest people and at the same time it was important for the person to mentally go through that rigorous process and beat it which after "winning" creates a psychological bond and loyalty with the brand of the gang and a sense of earning that respect from the gang. Our tech interviews sounded very similar to the recruiting done by these notorious gangs. So lets just say that this kind of whiteboard interviewing evolved in nature.
For lack of better ideas, this is going to be new normal. Spend significant time and get comfortable dealing with whiteboard/standardized tests. The alternative is networking and referrals where some managers in few companies can bypass the hiring process and hire you if they like what you have to offer.