<story><title>Panic at the Job Market</title><url>https://matt.sh/panic-at-the-job-market</url></story><parent_chain><item><author>ajkjk</author><text>Imo, there are two kinds of programmers: people who can write code to build stuff, and people who can write code to build stuff and are also conversationally fluent in the theory behind writing code. The second group is 5x more useful than the first, and coding interviews are testing which group you&amp;#x27;re in. Often the first group doesn&amp;#x27;t think the extra skill of fluency is important, which is fine, think what you want, but they&amp;#x27;re definitely &lt;i&gt;wrong&lt;/i&gt;, and I wouldn&amp;#x27;t want to work with those people; when there are actual problems to solve I&amp;#x27;m going to go looking for people in the second group to figure them out. A terrible situation is to end up with a team of entirely people who can code but can&amp;#x27;t theorize about code, because they&amp;#x27;ll build a mountain of crap that other people have to rebuild later.&lt;p&gt;(Now it&amp;#x27;s true that some people can&amp;#x27;t theorize quickly, or in front of someone else, or especially in a stressful interview where there&amp;#x27;s a lot on the line. Those are real issues with the format that need solving. Not to mention the &amp;quot;esoteric trivia&amp;quot; sorts of questions which are pointless.&lt;p&gt;But the basic objection that &amp;quot;coding tests aren&amp;#x27;t testing the skills you need in your day job&amp;quot; is absurd to me. They&amp;#x27;re not the skills you use everyday, they&amp;#x27;re the skills you need to be able to pull out when you need them, which backstop the work you do every day. Like your mechanic doesn&amp;#x27;t use their &amp;quot;theory of how engines work&amp;quot; every day to fix a car, but you wouldn&amp;#x27;t want a mechanic who doesn&amp;#x27;t know how an engine works working on your car for very long either...)</text></item><item><author>caesil</author><text>&amp;gt;According to all the interviews I’ve failed over the years (I don’t think I’ve ever passed an actual “coding interview” anywhere?), the entire goal of tech hiring is just finding people in the 100 to 115 midwit block then outright rejecting everybody else as too much of an unknown risk.&lt;p&gt;As a (now) senior&amp;#x2F;staff-level engineer back out on the job market for the first time in a while, I&amp;#x27;m begrudgingly coming to accept that coding interviews might not actually be all that bad. Mostly because I find myself passing them due to having picked up skills in the past few years rather than spending a ton of time studying, which suggests they might actually be picking up some signal. I once thought they were purely hazing with zero relevance to day to day work, but as I get more senior I drift further away from that opinion.</text></item></parent_chain><comment><author>dakiol</author><text>I think there’s another group: people who can come up with solid code by using search tools.&lt;p&gt;I code, sure, but I will never come up with a custom solution for any non trivial problem. I know where to find appropriate solutions (the best ones) because I’m aware of what I don’t know (I read a lot of tech books). You cannot test this in the classic tech interview (because I would googling 75% of the time).&lt;p&gt;The final result is: you want good code or not? How I come up with it should be secondary.</text></comment>
<story><title>Panic at the Job Market</title><url>https://matt.sh/panic-at-the-job-market</url></story><parent_chain><item><author>ajkjk</author><text>Imo, there are two kinds of programmers: people who can write code to build stuff, and people who can write code to build stuff and are also conversationally fluent in the theory behind writing code. The second group is 5x more useful than the first, and coding interviews are testing which group you&amp;#x27;re in. Often the first group doesn&amp;#x27;t think the extra skill of fluency is important, which is fine, think what you want, but they&amp;#x27;re definitely &lt;i&gt;wrong&lt;/i&gt;, and I wouldn&amp;#x27;t want to work with those people; when there are actual problems to solve I&amp;#x27;m going to go looking for people in the second group to figure them out. A terrible situation is to end up with a team of entirely people who can code but can&amp;#x27;t theorize about code, because they&amp;#x27;ll build a mountain of crap that other people have to rebuild later.&lt;p&gt;(Now it&amp;#x27;s true that some people can&amp;#x27;t theorize quickly, or in front of someone else, or especially in a stressful interview where there&amp;#x27;s a lot on the line. Those are real issues with the format that need solving. Not to mention the &amp;quot;esoteric trivia&amp;quot; sorts of questions which are pointless.&lt;p&gt;But the basic objection that &amp;quot;coding tests aren&amp;#x27;t testing the skills you need in your day job&amp;quot; is absurd to me. They&amp;#x27;re not the skills you use everyday, they&amp;#x27;re the skills you need to be able to pull out when you need them, which backstop the work you do every day. Like your mechanic doesn&amp;#x27;t use their &amp;quot;theory of how engines work&amp;quot; every day to fix a car, but you wouldn&amp;#x27;t want a mechanic who doesn&amp;#x27;t know how an engine works working on your car for very long either...)</text></item><item><author>caesil</author><text>&amp;gt;According to all the interviews I’ve failed over the years (I don’t think I’ve ever passed an actual “coding interview” anywhere?), the entire goal of tech hiring is just finding people in the 100 to 115 midwit block then outright rejecting everybody else as too much of an unknown risk.&lt;p&gt;As a (now) senior&amp;#x2F;staff-level engineer back out on the job market for the first time in a while, I&amp;#x27;m begrudgingly coming to accept that coding interviews might not actually be all that bad. Mostly because I find myself passing them due to having picked up skills in the past few years rather than spending a ton of time studying, which suggests they might actually be picking up some signal. I once thought they were purely hazing with zero relevance to day to day work, but as I get more senior I drift further away from that opinion.</text></item></parent_chain><comment><author>joha4270</author><text>Could you expand on what&lt;p&gt;&amp;gt; conversationally fluent in the theory behind writing code&lt;p&gt;means?&lt;p&gt;It might be my insufficient command of the English language, or I might be outing myself as being outside said group, but I&amp;#x27;m unsure what that &lt;i&gt;means&lt;/i&gt;. Is this just referring to a vocabulary for discussing the structure and creation of software, or is there a deeper mystery I have not yet grasped?</text></comment>