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
[ 3.0 ms ] story [ 75.4 ms ] threadHow does this compare to the software/applications in the code tests?
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.
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 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 :)
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.
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.
- get Cracking the Code Interview
- practice it for a couple months
- practice using a whiteboard and other problematic areas
I've also failed most of those online tests.
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 ;)
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.
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.
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.
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.
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.
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.
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.
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 an...
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.