<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on Takehome.io Blog</title>
    <link>https://blog.takehome.io/post/</link>
    <description>Recent content in Posts on Takehome.io Blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 08 May 2018 09:03:17 +1000</lastBuildDate>
    <atom:link href="https://blog.takehome.io/post/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Conway&#39;s law of technical interview challenges</title>
      <link>https://blog.takehome.io/post/conway/</link>
      <pubDate>Tue, 08 May 2018 09:03:17 +1000</pubDate>
      <guid>https://blog.takehome.io/post/conway/</guid>
      <description>&amp;ldquo;organizations which design systems &amp;hellip; are constrained to produce designs which are copies of the communication structures of these organizations.&amp;rdquo;&#xA;— M. Conway&#xA;Your software architecture reflects your org chart. The interview process you put candidates through reflects your organisational culture. This process sends a loud message about what your company will be like to work for. By definition, the people getting this message are the candidates you’re most interested in hiring.</description>
    </item>
    <item>
      <title>What makes a good code challenge</title>
      <link>https://blog.takehome.io/post/good_challenges/</link>
      <pubDate>Fri, 04 May 2018 14:42:10 +1000</pubDate>
      <guid>https://blog.takehome.io/post/good_challenges/</guid>
      <description>Last time we established why code challenges are important. Now it&amp;rsquo;s time to talk about what separates a good challenge from a bad challenge. Stick to the following principles and you&amp;rsquo;ll get something great.&#xA;Concise. You want great people. Everyone wants great people. Therefore, it&amp;rsquo;s pretty unlikely that your candidates are only going to be interviewing with you. If someone has time to do a five-day unpaid technical challenge as part of an interview process that&amp;rsquo;s probably not a positive signal.</description>
    </item>
    <item>
      <title>Why code challenges?</title>
      <link>https://blog.takehome.io/post/why_code_challenges/</link>
      <pubDate>Thu, 22 Feb 2018 14:46:03 +1100</pubDate>
      <guid>https://blog.takehome.io/post/why_code_challenges/</guid>
      <description>When you’re hiring software developers, it’s vital to assess that they can actually solve problems with code. In my experience, this is harder to get right than you may think. Let’s take a look at four popular solutions to this problem, and try to work out the best option.&#xA;A quick chat Most interviewers first try a general, fairly freeform conversation about code and technical matters. As they talk, they’ll use their intuition, experience and common sense to get a feel for how experienced and competent the candidate is.</description>
    </item>
  </channel>
</rss>
