Ask HN: Why do we have to study before applying for a job?

22 points by bsvalley ↗ HN
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 ] thread
(comment deleted)
> Aren't we supposed to be qualified for a job when applying for a job?

Juniors 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.

Let me ask you this question - when was last time you used a binary tree at work? Just curious. Maybe you do use this stuff. Then in this case the current hiring process is perfect for you.

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.

> Let me ask you this question - when was last time you used a binary tree at work?

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.

What sort of questions about the OS X kernel do you have in mind?
It is interesting to note that company and employee loyalty is becoming more scarce, as well as on the job training being uncommon. It does not bode well for the state of the industry, if more and more companies are having a revolving door problem with employees.
Because there are a lot of developers they can chose from. Also its a young mans game. We have a new version of React or some random new framework every few months. I guess experience is not valued in this industry.
I agree. To that I'd add the fact that senior engineers - unlike junior engineers - get pulled from a bunch of other companies. By hiring young engineers companies would get longer commitments and leave plenty of rooms for employees to grow.
(comment deleted)
I believe this happens for a few reasons.

* 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.

That's good stuff I like that. In today's market the competition is too high, their goal during an interview process is to focus on the negatives. Why? Because they pretty much tell you right away - we're talking to you because we like you. So the game is to dislike you. They're looking for that opportunity to dislike you and to move on to the next candidate.

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.

You are right, sometimes I am disqualified for a number of reasons. I am sure people have thought of me as a jerk, a fake, a lot of other things. And that is absolutely alright. Why should the company and I both waste a substantial amount of our time on something that doesn't really fit? I certainly don't try to come across as a jerk but time is quite valuable. Use it wisely.

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'm referring to the "competition" post Resume, when they already reached out to you - "your profile is very attractive and would be a perfect fit for our role". They put you into their hiring process with a few other candidates who've also been selected carefully. I could bypass their stupid interview questions like you said, unfortunately, the other 2 or 3 candidates will play the game and one of them will get the job. They won't hire someone who doesn't follow the requirements.

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.

Is there a polite way to refuse the coding problems?
Generally I try to head this off before I even get into the situation. I will boldly ask whether there will be any white boarding during an interview. If there is I will often explain why that's not a good idea and see what else they would be willing to do to interview me. The discussion is usually very valuable to both of us.

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.

Because it takes skilled thoughtful effort to design an interview process that gathers sufficient information, corresponds reasonably to the work required, but which doesn't require a whole bunch of company-specific context or impose prohibitive costs.

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.

Because we get paid a lot. The reward/cost ratio for studying for interviews is very high.
It only happens in a minority of companies, ignore them and you'll be fine. I haven't done a difficult whiteboard puzzle in years now (sometimes companies do very easy coding problems to basically see how you think and check if you're not a fraud I guess? - they require no studying and thus I'm fine with them).
Stop applying to these jobs. People need to stand up for themselves (in the absence of unions) and refuse to do stupid activities like this.
> mathematical/academic concepts like big O

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".

I think being able to code a binary tree is a good indication of competence. C is perhaps an exception where writing a tree implementation is much harder due to pointer syntax and memory unsafety.

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.