Not saying you know the question and lying after you've been asked are different things. I agree on that. And probably you should only answer questions on interviews not give away any info not required by interviewer as sometimes it can even lead to interviewer thinking "we'll you give too much info but we need someone who's simple and just does what's asked of him".
I strongly disagree with practising for interview and schema like questions. This is pretty bad as people get to memorize some rules pass the test and then do same mistakes others do while programming. Candidate should be asked theoretical questions and their views on it. This gives you more perspective on does the candidate understand why is something a standard or a good practice. Example many design patterns are out there but some became "useless" like strategy pattern that can be solved by simple lambda. Now it's maybe not useless but why would you do it any other way when provided possibility. The answer is because you learn schema on how to solve problem and do not really understand what's it actually doing.
So if you're getting ready for a new job and know the questions and that helps you get the job you should really think about what's going to happen when it's time for you to make strategic decision and you deliver poorly. The post is written in a way that could make me think there's some honesty issues here and gives message like "look for yourself". I dislike that approach and always put honesty first as it hurts less later if I say in the start "yeah I'm not good at that".
If the system were fair, then honesty would be the best approach. But the interview system at a lot of companies is kind of random. The idea that throwing a random algorithm question at you is some way indicative of your ability is wrong.
So, in my view, if the interview process is a silly game, then learn to play the game. This doesn't preclude you from learning how to code, but navigating the dumb questions are a prerequisite to working -- especially if you're targeting specific companies.
As I mentioned, I think for good interview questions it doesn't really matter much if the person has seen it before. And I think this is what you're saying as well.
Of course. Companies tend to have silly "game" and what worries me is wanting to work for them. I had a lot of interviews were I did not have such questions but latest one I had with questions about design patterns and solid priciples was more of how would I explain it. On the other hand I disslike forcing patterns and some principels/architecture because others do it, so I'm glad I didn't get the job and accepted other opportunity.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not saying you know the question and lying after you've been asked are different things. I agree on that. And probably you should only answer questions on interviews not give away any info not required by interviewer as sometimes it can even lead to interviewer thinking "we'll you give too much info but we need someone who's simple and just does what's asked of him".
I strongly disagree with practising for interview and schema like questions. This is pretty bad as people get to memorize some rules pass the test and then do same mistakes others do while programming. Candidate should be asked theoretical questions and their views on it. This gives you more perspective on does the candidate understand why is something a standard or a good practice. Example many design patterns are out there but some became "useless" like strategy pattern that can be solved by simple lambda. Now it's maybe not useless but why would you do it any other way when provided possibility. The answer is because you learn schema on how to solve problem and do not really understand what's it actually doing.
So if you're getting ready for a new job and know the questions and that helps you get the job you should really think about what's going to happen when it's time for you to make strategic decision and you deliver poorly. The post is written in a way that could make me think there's some honesty issues here and gives message like "look for yourself". I dislike that approach and always put honesty first as it hurts less later if I say in the start "yeah I'm not good at that".
But this is too subjective I'm aware of that.
If the system were fair, then honesty would be the best approach. But the interview system at a lot of companies is kind of random. The idea that throwing a random algorithm question at you is some way indicative of your ability is wrong.
So, in my view, if the interview process is a silly game, then learn to play the game. This doesn't preclude you from learning how to code, but navigating the dumb questions are a prerequisite to working -- especially if you're targeting specific companies.
As I mentioned, I think for good interview questions it doesn't really matter much if the person has seen it before. And I think this is what you're saying as well.
Of course. Companies tend to have silly "game" and what worries me is wanting to work for them. I had a lot of interviews were I did not have such questions but latest one I had with questions about design patterns and solid priciples was more of how would I explain it. On the other hand I disslike forcing patterns and some principels/architecture because others do it, so I'm glad I didn't get the job and accepted other opportunity.