Comment by PragmaticPulp | Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Parent Full thread

This is also deeply misunderstood as an interview question. The idea that interviewers will reject candidates for not programming outside of work is a persistent meme now.

The truth is that (good) interviewers don't care when/where/how you acquired your skills and knowledge. They just care that you have the knowledge and ability, and also that your learning is on a consistent upward trajectory.

We ask if people do side projects not because side projects are mandatory, but because the goal of an interview is to surface any and every reason to believe the candidate is qualified. In practice, most engineers don't put side projects or hobby projects on their resume or even their GitHub profiles, and they won't spontaneously bring it up during the interview. Asking if they've worked on any fun hobby projects usually strikes up good conversation, loosens up the candidate, and maybe unearths some skills and interests that don't show up on the resume.

If a candidate says they don't program outside of work, it's not a negative. It's neutral. We just move on.

As an interviewer I can only agree.

I look for signs that the person is interested in what they are doing. Private projects with public repositories are a sign but nowadays I see people started showing up who force themselves to do these projects just to improve their interview prospects.

I even had one person admit it when it was obvious they can't tell me anything about their own project.

Obviously, this is a result of a very know effect where judging performance based on some measurements causes people to pervert this measurement.

Other signs that people overlook and misunderstand is deep knowledge on any topic related to software development. If somebody could acquire good, deep understanding of at least one topic it shows they were likely at least at some point interested in it.

People are sometimes put off that I seem to be asking large number of hard questions and then grilling to death, but that's what I am doing, looking for signs of being interested in something.

I even have one question where I ask: What is the question you would like me to ask you? That's just another occasion to have a discussion on something where the candidate can demonstrate their deep knowledge.

> but nowadays I see people started showing up who force themselves to do these projects just to improve their interview prospects.

As an interviewer, it's fascinating to read forums like /r/cscareerquestions where people are working hard to game the interview system. Coding Bootcamps have also become bad at training students to pass interviews by practicing coding questions and putting cookie-cutter "side projects" in their GitHub profile.

One of our local coding bootcamps had students post their class projects to GitHub as "side projects" to show to interviewers. The catch was that every graduate from the boot camp had the exact same "side projects" that followed the same formula.

As an interviewer, it's amazing to see people arrive at interviews with an idea that we're just robots trying to check items off of a checklist. The internet pop-culture view of coding interviews is that they're just arbitrary gatekeeping that can be bypassed if you simply know which magic words to say to your robot interviewers.

Tip for interviewers: Speak to your interviewers as if they were your future peers or managers.

That mindset pisses me off so much. Every time someone asks me about advice for an interview and I don't mention doing hours of leetcode studying they accuse me of lying and trying to sabotage them because _obviously_ the only way to pass an interview is to memorize every possible question the interview can ask! It's so crazy to me how people think this and then I'll sit down with them for a mock interview and watch them completely stop communicating or treat me like I'm a binary switch that only comes on when they have the optimal solution.

Nothing to be pissed about. You are correct and so are interviewers.

Interviewers and interviewees have different incentives.

My job as an interviewer is to see through bullshit as efficiently as possible and decide on some realistic compromise when selecting candidates.

I also sometimes look for job myself. Technically, I could go with the flow and do whatever other candidates are doing. But I don't want to and I don't need to. I have over two decades of both development and interviewing experience and I know that just being myself and not trying to impress anybody is already going to impress interviewers a lot.

I gladly offer information about which parts of the requirement I am lacking and also I will immediately say that I don't know something when I don't -- without trying to impress on the interviewer that I know more than in reality. This alone lets me stand out from other candidates.

There is one more reason not to try to game the process. It is the most important one. I want to be building trust with my manager from day one. Misleading about my knowledge and experience is best way to immediately taint that cooperation.

Yeah, I've noticed a big gap in interviewee's perception of what interviews are supposed to be like, vs what I look for when conducting an interview. Often times, I see people on reddit asking questions along the lines of "I've an interview coming up, what leetcode thing should I cram", but that really misses the picture that a good interview is nothing like a teacher marking a scantron school test.

The crazy part is that some of these interviewees even have work experience and ought to know better!

>Yeah, I've noticed a big gap in interviewee's perception of what interviews are supposed to be like, vs what I look for when conducting an interview.

This depends on the person and company doing the interview, I think. I work as a consultant implementing a specific software package and recently interviewed with a Unicorn trying to switch to mroe general purpose coding. The difference in the process is night and day. When I do interviews with consulting firms it's almost always someone with significantly more experience than me. And they are usually pretty free flowing and in depth discussions.

The Unicorn interview was 100% checking boxes. I had 4 leetcode style coding challenges and the only thing that really mattered was solving the problem. The discussion ones were pretty obviously interviewers asking questions from a piece of paper. The only goal there was to give them something good enough to write in the box so that it would pass later review.

I agree that big companies have interviews that look more checkboxy since they generally want interviews to be standardized/fair for candidates, but even then, a lot of the interview is not about the solution to the problem per se. For example, if the candidate struggles with basic syntax, or if they struggle with refactoring, or they don't react to feedback well, these are all things that get considered, even if they do solve the question optimally on paper.

I had one where we solved the problem half way through the session and went on a big tangent about how to engineer a solution to a related fuzzy problem.

I do agree though that interview standardization can lead to mediocre interviewer practices if the interviewer isn't truly committed to improving their recruiting skills (which is sometimes the case if a team is on a crunch, for example).

I agree. All of my consulting interviews have gone on tangents here, there and everywhere.. And focused more on ability to think, problem solve and be a human. Whereas engineering and software jobs are rote.

"Tip for interviewers: Speak to your interviewers as if they were your future peers or managers. "

That exposes a real problem. WIth people gaming the interview process that is good advice.

But it surely it is part of the process that leads to mono cultures? Workplaces with 25-35 year old white men? (Or what ever)

How can you get a diverse good group? Does diversity matter? I think it does, am I right?

I don't think being more professional/collegial and less dishonest in an interview leads to monocultures. Ideally it would just reflect well on the person for not obviously trying to game the system. If that actually leads to someone being less likely to get a job someplace, well that's a place you wouldn't want to work at anyway.

You don't need every job you apply for. You only need one.

When you get that one job, you want good relationship with your manager. Trying to game the system means your manager will have higher expectations that will not be met, causing possibly dissapointment or trust issues.

By trying to game the system you have almost 100% chance of damaging your future relationship. You need to ask yourself whether that's something you want.

Things become memes (they used to be called stereotypes) because there's enough truth behind them to make them relevant and "sticky"

The programming in your free time comes up all the time because people, like the OP, see it as a signal. If you do it, you're good. If you don't, you're bad.

And specific to your point - "do you code in your free time" as an interview question - if it didn't provide you with signal that you thought was useful in determining the quality of a candidate, you wouldn't ask it. So, why are you (interviewers in general) asking it?

Because I want to get to know the person a little bit, professionally. Because I want to learn if the person has some traits that correlate well with doing a good job later.

I don't think it is going to be very controversial when I say that people who are enthusiastic about programming, have experience completing projects, can solve difficult problems, can show they have knowledge of concepts, are intelligent and know how to work with other people tend to do just that -- perform better at their jobs.

Also, I don't ask "do you code in your free time". I ask for any projects private or professional they have been working on recently that they think are fun and interesting.

Reply on news.ycombinator.com