Hacker News Reader

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.

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

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

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

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.

>If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. --Antoine de Saint-Exupéry

I've noticed this in my software work. When I'm on a project that I'm personally excited by, I feel like I'm firing on all cylinders and am vastly more productive. Driven by COVID fear, I switched jobs over the summer to a company that would allow me to work from home. I'm not at all interested in the project I'm working on. And I feel like it shows...I don't retain things that coworkers have already explained, I don't feel a drive to learn more than necessary about the domain, etc. Maybe some of it is just COVID-brain, but my goodness being interested in your work makes a world of difference.

That's a good view on that opinion. I've kids and a wife that has a job, the spare time is taken up by them and the time I need to rest. I would if I had the time, but I'm interested in each and everything when working.

As I get older, I start realizing that I don't want to spend my free time coding all the time. I do like to take that time to build something with my hands, fix things around the home. I feel those are good critical thinking tasks and great experiences that can be applied to programming.

#1: "Programmers who don’t code in their spare time for fun will never become as good as those that do." #17: "Software development is just a job."

I don't think there is any problem here.

Not everybody has to be uber excited about everything they do. I surely can empathize with every person that wants to have a well paying job but just don't feel anything towards anything that is well paying.

Just set your expectations realistically. If you are of slightly above average intelligence and you are not uber excited about programming (ie. typical developer), chances are you are never going to be rock star developer. Plan your career realistically taking that into account. Maybe work in area that doesn't require changing entire stack every 2 years?

My friend decided consciously (we had a discussion) he is not ambitious but still wants to earn. He is now Cobol developer working with people that are on average twice his age. He has been and will be well paid for many years. He works 8h day, has time for his kids and other interests. He says he couldn't be happier.

Programming is not the same thing as software development. Software development requires programming, among many other things. Programming need not be towards the acct of software development.

More specifically, I wouldn't call solving Project Euler problems "software development". It's a game, a puzzle, that requires programming. And I wouldn't call requirements analysis, UI design, testing, etc., "programming", But they are fundamental aspects of software development.

It's possible to treat programming as a calling and software development an occupation.