Ask HN: Why do we have to study before applying for a job?
This is a question that has never been asked. Let's have a deep thought about it here. Aren't we supposed to be qualified for a job when applying for a job? I'm a senior software engineer, why do I have to spend hours/weeks/months on Leet Code, Hacker Rank, etc. in order to be prepared for a "technical interview" these days? Why do technical interviews force me to re-learn something not relevant to the actual job I'm applying for? I say "re-learn" because you learn it, never use it then you forget about it. I'm referring to the mathematical/academic concepts like big O, binary trees, graphs, linked list, etc.
I feel like the interview process for software engineers is designed exclusively for people fresh out of college. Why is it still bad in 2017? Honestly, how could we fix this?
24 comments
[ 3.0 ms ] story [ 70.0 ms ] threadJuniors aren't, though they are expected to show some capability in the matter (and that's why everybody demands from them a college degree).
In the old days companies were training their employees on the job. In those days it wasn't uncommon for employee to stick to a company for twenty-thirty years, so training paid off for the company. Today employee works only for couple of years before moving (or being moved) to next company, so it's not surprising nobody wants to train anybody from ground up. Training requires loyalty from both parties, which is a scarce resource nowadays.
> I'm a senior software engineer, why do I have to spend hours/weeks/months on Leet Code, Hacker Rank, etc. in order to be prepared for a "technical interview" these days?
I don't. Apparently it's a location-specific phenomenon.
> Why do technical interviews force me to re-learn something not relevant to the actual job I'm applying for? [...] I'm referring to the mathematical/academic concepts like big O, binary trees, graphs, linked list, etc.
I don't know what are you doing in your work, but in my job data structures and computational complexity are important basics. Without ability to juggle with those in my head (assessing complexity on the fly) I couldn't even start to think about anything substantial. And I'm not even fully fledged programmer, I'm in large part a sysadmin.
I manipulate hash tables all day everyday and data structures at a high level. Languages like Java, Objective-c, swift, etc. aren't built for schools. They are built for professionals who want to build products. Which is what I do all day. The underlying/academic thing isn't relevant anymore in 2017. Plus, I graduated from college with a CS major 10 years ago. That alone should be enough for a company to believe I'm not a Walmart employee trying to switch careers. (I have nothing against Walmart employees).
Are you a Mac user or a PC user? Let's say you're a Mac user. What if I ask you specific questions about the OS X kernel? If you use it everyday then you should know how it works right? We, software engineers, build products, or at least the majority of us. Technical interviews should focus on that, we should be building mini products and features and get evaluated on that rather than white boarding stuff.
Three tools ago (my tools are small and orbit around 5kLOC). And it seems I'll need one again in current tool, for similar reasons.
> Languages like Java, Objective-c, swift, etc. aren't built for schools.
Very little languages were written for schools specifically. But this doesn't mean much, because the same stands for table saws or CNC machines, yet students (woodworkers and machinists) are taught to operate those.
> The underlying/academic thing isn't relevant anymore in 2017.
As I said, I don't know what you do in your work, but the underlying concepts are not relevant only if you never use them. Which I think tells something if even a sysadmin uses them.
> Plus, I graduated from college with a CS major 10 years ago.
If we're bragging, then I don't even have a degree and apparently I have work experience of similar length. And compare our attitudes towards data structures knowledge: I use it often, you don't. What went wrong?
> [CS degree] That alone should be enough for a company to believe I'm not a Walmart employee trying to switch careers.
As I said, quizzes about data structures seem to be a location-based thing.
> We, software engineers, build products, or at least the majority of us. Technical interviews should focus on that, we should be building mini products and features and get evaluated on that rather than white boarding stuff.
Mind you, I don't claim we should not. I just say that your "white boarding stuff" seems to be local to some geographical area(s?) and that knowledge about basic algorithms and data structures is important even for a sysadmin that happens to wirte tools, so it should also be the case for regular senior programmers.
* A lot of software developers don't apply to enough positions. A number of developers who talk with me and complain about the interview process don't apply and get enough interviews to be picky about the interviews they are accepting. Companies play on this fact very well. They know developers get their heart set on only a few jobs and so make them jump through hoops to get the position. Try applying to 10 developer positions a day. Seriously. It's fun and refreshing.
* Software developers don't market themselves well enough. I honestly don't even have a resume available. When people ask for one I say, "I don't have a resume nor do I need one." They will then say one of two things. A) "Fine, we're not interested in you." Great! I didn't apply with you anyway and frankly don't have time to jump through your hoops. B) "Oh that's not a problem can we just chat with you for a bit? I know you spoke at Conference A, B, and C, and we saw you at MeetUp X, Y, and Z. You're good friends with our Senior Ops person. We don't need a resume." Fantastic. My marketing is working out well. By the way, when they bring me in to have a chat and say "We'd like you to write out a red-black tree on the board in your favorite language, please. Oh and answer a bunch of random Big O notation questions." The answer is: No. Remember how you heard me speak at those conferences? Remember how I did a live coding and pairing session at that MeetUp? I think we can assume I know how to code. And if we can't, that's fine.
* Finally, have confidence. Honestly, most interviewers aren't confident in how to hire or what to hire. So, be confident for them. 50% of the time when I say I will not answer your asinine questions, more interviews stop and say, "Oh, well excellent, let me just talk to you about our problems." Which is where most interviews need to go.
So, you ask, how could we fix this? Fix it for yourself, individually. You aren't going to fix the industry. You aren't going to fix how bad people are at judging others work in a short period of time. But you can make your own situation substantially better.
If you do exactly what you said in your comment, you'd be disqualified for being a "jerk". As bad as it sounds, it's reality. Again, what you said is %300 what I think candidates should do.
Now, one area I am going to respectfully disagree on it competition. I find there is very low competition. Yes, I know, there are thousands of jobs and thousands of applicants. But the trick with competition is use it to your advantage. You mention elsewhere that you DO have a CS degree some a university. Good, you have a differentiator. What other differentiators do you have? Do you visit MeetUps? Do you talk to people at MeetUps? Do you present at MeetUps? Are you on the board of a MeetUp? Do you talk at conferences? Do you blog? Do you submit code to open source projects? Do you have your own open source project? Are you published? The list goes on and on and on. Get yourself some differentiators and suddenly the competition shrinks or disappears.
Imagine if you spent all of that prep time for an interview doing these other activities. You'd better yourself AND your ability to be valued in the market. I don't have a trick for getting work without working at it, hard. But I can say that if you hate prepping for interviews like you have been, then stop. Do something else to prep your future employer to know you are the right fit.
I could be their favorite pick, my 10 years of experience + a few products out in the world won't change much. They will pull out the "culture fit" card on you and you'll be out.
I also will bring a laptop with me to the interview. If it turned out they would like to ask me a white boarding question while I am there I have said "I would much prefer we pair on a solution to that together. I have my laptop here. Why don't we get started? I bet we could deploy something in the next 10 minutes." This often leads to, again, either a good discussion or even better an actual pairing session which teaches me about my interviewer and them about me.
If they really insist I whiteboard something, I will say no unless it's a problem that really interests me.
The company I work for tries to focus our interview challenges on knowledge that you would actually exercise and think about while on-the-job but isn't language and framework specific. It has trade-offs (we have a take-home test, which does impose a cost on candidates' free time) and I would be interested in seeing someone more experienced than I go through the process and evaluate how well we do.
Simply refuse to participate in asinine technical interviews. Counteroffer with a discussion proposal.
This subject actually comes up with great regularity. Here's a solid TC article from 2015 > https://techcrunch.com/2015/03/21/the-terrible-technical-int...
I hope I am not nitpicking here but ain't nothing wrong with knowing the time/space complexity for code you'd write. Especially if you are a "senior software engineer".
Some people freeze up during interviews and are not able to code as good as they otherwise could. That is unfortunate and a problem I don't know how to solve.