Whenever I speak with students/new grads about interviewing I actually specifically advise them that an interview is not a test. Yes, you need to have a certain level of base skills, but beyond that, an interview is much more like a date than a test. I say this because you can do everything right and still be rejected. It doesn’t mean that you did anything wrong or there’s anything with wrong with you, but rather there just wasn’t a match between you and the company you were interviewing with at that point in time. There are so many factors entirely outside of your control that determine if you’re given an offer or are rejected to the point that I find it really tough to consider it a “test” in the academic sense where you need to score a certain value to pass or fail it.
Likewise, it’s incredibly common for students/new grads to focus heavily on the technical skills while completely ignoring the soft skills. The best thing you can do in an interview is make the interviewer like you and want to work with you. It’s amazing how many people will overlook subpar technical skills either consciously or subconsciously if they feel comfortable with you (the amount of borderline incompetent people I’ve seen hired that are otherwise smooth talkers is astounding). It seems like the author of the linked to article here might be falling into that trap too. He writes about his technical experience heavily but does not touch on the soft skills at all, even questioning at one point that he may simply be bad at interviewing which is a strong sign to me that he’s not presenting himself well in the interview.
This is something that transcends software engineering. If you’re a sociable and likeable person you’ll go far further in life than the person that is quietly a genius but doesn’t work well with others. I wish more people folks in this industry would focus on that side of the coin instead of simply saying “grind Leetcode more to get more offers.”
Very true and completely agree with your post. I didn’t mean a test in the exam sense more like a COVID test in terms of test design.
I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.
I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.
At one of my favourite places to work, the owner had a sticky note on the side of his monitor that read “Hire for attitude, train for skill, reward for excellence.”
During one of our training sessions (I was teaching him Excel), I noticed that the sticky note was a different colour. I asked him about it and he said he rewrites it every Monday on a different colour so that it’s always visible and always fresh in his mind because it’s too easy to forget, even though he thought it was the secret to running a successful business.
The most successful interview I had I’d had a few shots ahead of time, and got into a (respectful) argument with the CTO about the pros/cons of their implementation of agile as I saw it.
Like, not to roast our man here, but he comes off as a competent Eeyore, even while writing from the safest of places, where he can take the time to craft whatever image he wants.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Whenever I speak with students/new grads about interviewing I actually specifically advise them that an interview is not a test. Yes, you need to have a certain level of base skills, but beyond that, an interview is much more like a date than a test. I say this because you can do everything right and still be rejected. It doesn’t mean that you did anything wrong or there’s anything with wrong with you, but rather there just wasn’t a match between you and the company you were interviewing with at that point in time. There are so many factors entirely outside of your control that determine if you’re given an offer or are rejected to the point that I find it really tough to consider it a “test” in the academic sense where you need to score a certain value to pass or fail it.
Likewise, it’s incredibly common for students/new grads to focus heavily on the technical skills while completely ignoring the soft skills. The best thing you can do in an interview is make the interviewer like you and want to work with you. It’s amazing how many people will overlook subpar technical skills either consciously or subconsciously if they feel comfortable with you (the amount of borderline incompetent people I’ve seen hired that are otherwise smooth talkers is astounding). It seems like the author of the linked to article here might be falling into that trap too. He writes about his technical experience heavily but does not touch on the soft skills at all, even questioning at one point that he may simply be bad at interviewing which is a strong sign to me that he’s not presenting himself well in the interview.
This is something that transcends software engineering. If you’re a sociable and likeable person you’ll go far further in life than the person that is quietly a genius but doesn’t work well with others. I wish more people folks in this industry would focus on that side of the coin instead of simply saying “grind Leetcode more to get more offers.”
Very true and completely agree with your post. I didn’t mean a test in the exam sense more like a COVID test in terms of test design.
I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.
At one of my favourite places to work, the owner had a sticky note on the side of his monitor that read “Hire for attitude, train for skill, reward for excellence.”
During one of our training sessions (I was teaching him Excel), I noticed that the sticky note was a different colour. I asked him about it and he said he rewrites it every Monday on a different colour so that it’s always visible and always fresh in his mind because it’s too easy to forget, even though he thought it was the secret to running a successful business.
The most successful interview I had I’d had a few shots ahead of time, and got into a (respectful) argument with the CTO about the pros/cons of their implementation of agile as I saw it.
Like, not to roast our man here, but he comes off as a competent Eeyore, even while writing from the safest of places, where he can take the time to craft whatever image he wants.