<p>Hi all,</p>
<p>We're looking for Go engineers to build the future of payments with us at Bolt (bolt.com). More details here: <a href="https://bolt.com/platform-engineer">https://bolt.com/platform-engineer</a>.</p>
<p>PM me or shoot us an email: jobs[at]bolt.com.</p>
<p>Some notes:</p>
<ul>
<li>We are building a service-based payments platform primarily in Go</li>
<li>New team members we will be responsible for designing, building and shipping new infrastructure and feature using Go</li>
<li>Our team is heavily investing in go infrastructure, tools and support</li>
<li>This is a SF-based job. We provide relocation support and a few months of buffer before moving.</li>
<li>We're an engineer-first team with key lead engineers from FB/Twitter/Google/Apple</li>
<li>Opportunity to join a small yet very high-impact team</li>
</ul>
<p><em>Thanks moderators for approving this post.</em></p>
<hr/>**评论:**<br/><br/>IntellectualReserve: <pre><blockquote>
<ul>
<li>Ability to operate in a startup environment and execute in the presence of <em>ambiguity and change</em></li>
</ul>
</blockquote>
<p>Can you elaborate on what this means to your company? What thing(s) are acceptably ambiguous? What thing(s) change (and how often)? How do these factors contribute to your company's success? </p>
<p>Early in my career, I worked for a software startup that was created on a whim by a self-funded non-engineer with no business plan. As you might imagine from that description, we had no roadmap, no requirements, no specifications, and no release goals. That level of ambiguity and change ultimately led the company to financial failure.</p>
<p>I do not cite this example to suggest Bolt is similar, but to illustrate how much more there is for Bolt to say about its culture/environment. I look forward to hearing more as I have an interest in a large portion of Bolt's problem domain and I might be interested in applying. </p></pre>google_you: <pre><p>Do I have a private office? Is this a sweat shop? Can I work 40 hour or less a week? And no on-call. No release overtimes. No overtime what so ever. Yes, I make stable programs that are well tested before release, unless crazy yolo product manager rushes shits.</p></pre>breslow: <pre><p>Good questions. </p>
<ul>
<li>I'm sure we can accommodate private office if important.<br/></li>
<li>We really value work/life balance. Less hours with higher-focused work > more hours of poorly focused work</li>
<li>We'll be hiring someone dedicated to on-call work and administration. Right now, we're focused on high-performance, stable development.<br/></li>
</ul></pre>CapoFerro: <pre><p>I've always thought that the on call should be the developers cause they are often most empowered to fix the root causes of problems, and being on call motivates them to do so, so they get called less.</p></pre>breslow: <pre><p>I agree. However, being on-call can also be overwhelming and specialization around that is sometimes beneficial. It's never good for problems to exist, so I think our team has plenty of incentive to make sure the root causes of problems are fixed.</p></pre>CapoFerro: <pre><p>If the team is small, that is definitely a concern. We had a team of three guys responsible for supporting all our operations in China and they would burn out and change teams on a cadence of like 4 to 6 months, making it very hard to keep fully trained staff over there... Being on call all the time really sucks. Having a 1 week shift every 6 weeks in a mid sized team rotation is much more manageable. </p></pre>terrason: <pre><p>Hey! I looked at the site and I have some questions others might have, too.</p>
<p>How old is this company?</p>
<p>How big is this company?</p>
<p>Do any key engineers have notable published work?</p>
<p>Do you have an intern program?</p>
<p>What's a workday like at this company?</p></pre>breslow: <pre><p>Thanks for the interest terrason<br/>
- ~1 year old<br/>
- 10 people<br/>
- Yes, several. A couple profiles - <a href="https://github.com/netik">https://github.com/netik</a>, <a href="https://github.com/ryanking">https://github.com/ryanking</a><br/>
- No intern program at this stage<br/>
- We're pretty heads down throughout the day. Headphones in. Meals provided by company. But, we're a pretty close team and hang out after / outside of work. </p></pre>hipone: <pre><p>Do you have engineers that work remotely?
If yes, where from?
If no, do you plan to have engineers that'll work remotely?</p></pre>