<story><title>Tech Interview Handbook</title><url>https://yangshun.github.io/tech-interview-handbook/</url></story><parent_chain><item><author>new299</author><text>Personally I can&amp;#x27;t see an issue with very simple FizzBuzz style programming interview questions. I used to ask a simple &amp;quot;count duplicate substrings&amp;quot; question [1]. Maybe some people consider this too hard? I never used to require exact syntax, and would have been happy with pseudo-code. Using libraries is fine etc..&lt;p&gt;I also found very few people could solve this (similar non-SF large city location). Occasionally, people who could not solve this were hired for other teams. Based on their performance, I don&amp;#x27;t think I would have been comfortable working with them.&lt;p&gt;I don&amp;#x27;t think it&amp;#x27;s unreasonable. But I&amp;#x27;m not sure I&amp;#x27;d use it as a screen if I was hiring now. I think I&amp;#x27;d just have a chat and try and discuss a previous project. After that I&amp;#x27;d move to a paid take home project (ideally representing real, useful work).&lt;p&gt;[1] Take a string, for example &amp;quot;ABCCABC&amp;quot; and count the number of times each 3 character substring occurs. In this case the answer would be 2xABC 1xBCC 1xCCA 1xCAB.</text></item><item><author>DavidWoof</author><text>I realize everybody&amp;#x27;s going to jump in and rant about algorithms in interviews, but I wish you&amp;#x27;d all add something constructive as well.&lt;p&gt;I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot.  Resumes are meaningless, and often re-written by recruiters to match the job anyway.  Everyone has the same canned answers to the stupid behavioral questions.  And as for the code, we included what we thought was a trivial nested for-loop problem and virtually nobody could even get started on it.&lt;p&gt;Is this kind of code problem too complicated in your opinion?   For all I join in when complaining about irrelevant algorithmic questions, I have to admit that they at least test &lt;i&gt;something&lt;/i&gt;, even if it&amp;#x27;s just willingness to study for the interview.&lt;p&gt;Instead of reading everybody&amp;#x27;s complaints about interviewing, I&amp;#x27;d love to hear how you think it should be done.  Because I have to admit I&amp;#x27;m pretty much lost right now.</text></item></parent_chain><comment><author>bradlys</author><text>I never had any technical interview prep when I started.  I could code just fine. I demonstrated that at my other jobs and in school well enough. Then I started interviewing for SF positions that did these interviews.&lt;p&gt;I froze up. I couldn&amp;#x27;t talk and think at the same time. I didn&amp;#x27;t have the skillset for doing this in a very intense scenario. In my case, I was homeless and needed a job ASAP. Every interview felt like life or death to me.&lt;p&gt;First one I was asked to reverse a string in C. I hadn&amp;#x27;t done C in a few months. I froze up on syntax. I looked like an idiot who couldn&amp;#x27;t do it.&lt;p&gt;I could imagine many people who have never experienced this format (or haven&amp;#x27;t experienced it much) would easily freak out and look stupid as bricks like I did.&lt;p&gt;I&amp;#x27;ve since done over 200 technical interviews (as the interviewee) and I usually sweep. Still fail at FAANG but I always get the solutions. (Even the leetcode hard ones) Just not sure why I fail but cest la vie.</text></comment>
<story><title>Tech Interview Handbook</title><url>https://yangshun.github.io/tech-interview-handbook/</url></story><parent_chain><item><author>new299</author><text>Personally I can&amp;#x27;t see an issue with very simple FizzBuzz style programming interview questions. I used to ask a simple &amp;quot;count duplicate substrings&amp;quot; question [1]. Maybe some people consider this too hard? I never used to require exact syntax, and would have been happy with pseudo-code. Using libraries is fine etc..&lt;p&gt;I also found very few people could solve this (similar non-SF large city location). Occasionally, people who could not solve this were hired for other teams. Based on their performance, I don&amp;#x27;t think I would have been comfortable working with them.&lt;p&gt;I don&amp;#x27;t think it&amp;#x27;s unreasonable. But I&amp;#x27;m not sure I&amp;#x27;d use it as a screen if I was hiring now. I think I&amp;#x27;d just have a chat and try and discuss a previous project. After that I&amp;#x27;d move to a paid take home project (ideally representing real, useful work).&lt;p&gt;[1] Take a string, for example &amp;quot;ABCCABC&amp;quot; and count the number of times each 3 character substring occurs. In this case the answer would be 2xABC 1xBCC 1xCCA 1xCAB.</text></item><item><author>DavidWoof</author><text>I realize everybody&amp;#x27;s going to jump in and rant about algorithms in interviews, but I wish you&amp;#x27;d all add something constructive as well.&lt;p&gt;I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot.  Resumes are meaningless, and often re-written by recruiters to match the job anyway.  Everyone has the same canned answers to the stupid behavioral questions.  And as for the code, we included what we thought was a trivial nested for-loop problem and virtually nobody could even get started on it.&lt;p&gt;Is this kind of code problem too complicated in your opinion?   For all I join in when complaining about irrelevant algorithmic questions, I have to admit that they at least test &lt;i&gt;something&lt;/i&gt;, even if it&amp;#x27;s just willingness to study for the interview.&lt;p&gt;Instead of reading everybody&amp;#x27;s complaints about interviewing, I&amp;#x27;d love to hear how you think it should be done.  Because I have to admit I&amp;#x27;m pretty much lost right now.</text></item></parent_chain><comment><author>lacker</author><text>Of course &lt;i&gt;some&lt;/i&gt; people will consider that question to be too hard. But you may not want to hire those people. The point of an interview process is for you to pick the people you want to hire, not to ask questions that everyone agrees aren’t too hard.</text></comment>