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