<p>Has anyone here done an interview for any companies that used Go? If so, was it the typical algorithm and data structures questions or were the interview questions Go specific? What was your experience like. I'm assuming your experiences might be the typical kind, but there's an association of DevOps with Go that might restrict some job opportunities.</p>
<hr/>**评论：**<br/><br/>LK4D4: <pre><p>I work for Dropbox. We have very large Go codebase. Questions are never go specific on our interviews - you will learn it during onboarding anyway.</p></pre>wemgl: <pre><p>So would you say the interview questions are more on the algorithm and data structures side? In order to see if the candidate has the basics down?</p></pre>LK4D4: <pre><p>It's 50/50 algorithms and system things(like how files API works and such stuff). Also, there are concurrency questions for experienced candidates.
I believe it's pure algorithms only for new grads. </p></pre>hipone: <pre><blockquote>
<p>you will learn it during onboarding anyway</p>
</blockquote>
<p>Wondering how's code quality of a large codebase written by first-timers. Alternatively wondering, whether you guys spend 50% of your time doing code review?</p></pre>burnaftertweeting: <pre><p>If you are an experienced programmer its fairly difficult to write 'bad' go code, especially if your code is reviewed by someone more skilled in go. Go is very opinionated, and very simple. I've never been a huge fan of procedural languages until using Go.</p>
<p>Greg Wilson cites some studies in <a href="https://vimeo.com/9270320" rel="nofollow">this video</a> saying code review is the most effective way to eliminate bugs early, even more effective than unit testing. </p>
<p>my $0.02</p></pre>skidooer: <pre><blockquote>
<p>If you are an experienced programmer its fairly difficult to write 'bad' go code</p>
</blockquote>
<p>Strangely, after decades of programming experience in other languages, I found Go to be one of the more challenging languages to reach a point of writing good code. For lack of a better way to put it, you can paper over poor choices with language features in other languages. Not so in Go. I often wonder if some of criticisms of Go are directly a result of people not putting in the time required to reach a point of writing good code.</p>
<p>I agree that code review would go a long way here though.</p></pre>LK4D4: <pre><p>Code quality is ok. Go was designed for not requiring years of experience. Dropbox is hiring nearly hundred engineers per month - there is just not enough gophers out there.
And yeah, we're spending some quality time reviewing code. </p></pre>eikenberry: <pre><blockquote>
<p>there is just not enough gophers out there.</p>
</blockquote>
<p>Not in the few cities you are hiring in. If you want more/better people you should start setting up remote teams.</p></pre>deusmetallum: <pre><p>I did one today. It focused around writing a really basic restful API, following a spec, and the unit testing to go with it. Took about an hour.</p>
<p>Another couple I've done have focused around using maps to store data.</p></pre>wemgl: <pre><p>Ah, that's not to bad. I'm assuming it focused on doing your implementation using the standard library, or could you have used the gorilla toolkit or something?</p>
<p>I just got this book from Amazon called <a href="https://www.amazon.com/dp/1976503302/ref=cm_sw_r_cp_api_KcSYzbE342VT3" rel="nofollow">Data Structures & Algorithms in Go</a> and it seems to be written from the point of view of preparing for more traditional interviews. Go just seems more practical so I would expect more interviews like yours, but I could be wrong.</p></pre>deusmetallum: <pre><p>I chose to use the standard library, but I could have used a different toolkit if I'd wanted to. My API would have been easier if I used labstack echo for handling the http server, but net/http was fine.</p></pre>wemgl: <pre><p>Thanks for the information. I hope you get that job.</p></pre>_ak: <pre><p>I've been using Go professionally for about 4 years now, I have interviewed lots and hired plenty of other Go developers, and I was in several job interviews for Go positions. I've had everything from some basic programming tasks ("build a REST API to store and retrieve whatever in-memory data") to questions about intricate details and semantics of language elements to just general discussions about large-scale architectures without any coding exercises.</p>
<p>I have not witnessed any focus on DevOps tasks. Everyone I've had contact with, including in previous and current jobs, used Go for backend development, usually web services or microservices of some sorts.</p>
<p>When I interviewed people, I primarily checked that people could demonstrate an understanding of Go and some language-specific features like chans and goroutines, that they had sufficient communication skills to discuss their code in a review, and that they had some general ideas about how to architecture code and make it testable. Of course, every interview is different, but if you can present and demonstrate your Go skills, you should have pretty good chances, especially since Go developers are currently highly sought after.</p></pre>goomba_gibbon: <pre><p>I've applied for a few Go roles and I get the impression that employers are looking for willing Go converts, rather than experienced Go developers.</p>
<p>Was this true in your case?</p></pre>wemgl: <pre><p>I got this impression too, especially because Go is fairly young.</p></pre>goomba_gibbon: <pre><p>It helps that go is quite a small language and relatively easy to learn. Experienced programmers should pick it up quite easily.</p>
<p>There was a stack overflow survey about languages and I noticed that Go was significantly more popular in the US than most other places. That must be a factor in finding a role and in how many candidates a company will find that already have Go experience.</p></pre>burnaftertweeting: <pre><p>At my job we use go for our backend, but asfaik we don't use channels or goroutines. Are we missing out? What kind of use cases are there for your typical backend?</p></pre>_ak: <pre><p>If your problems are easier to be solved using goroutines and chans, then use them. Don't try to use them for everything, though.</p></pre>burnaftertweeting: <pre><p>We use a popular cloud development platform which has a built in delay method, which I'm guessing does roughly the same thing with some syntactic sugar - or maybe its just a way to limit the number of open chans or goroutines a customer can use.</p></pre>skidooer: <pre><p>If your popular cloud platform's delay method is anything like App Engine's delay package, then sort of, but not really. Which is to say that you can achieve similar results using goroutines, but that is just one small part of what they can do.</p>
<p>Goroutines and channels are really aimed at writing programs with concurrency, based on the <a href="https://en.wikipedia.org/wiki/Communicating_sequential_processes" rel="nofollow">CSP model</a>. I struggle to put it any better than the parent, "you'll know it when you need it", but <a href="https://www.youtube.com/watch?v=HxaD_trXwRE" rel="nofollow">this talk by Rob Pike</a> might help with thinking about problems in that way.</p></pre>Squeakerpants: <pre><p>As an example, you can have an API that returns the expected json response on the main thread, but spawns third party notifications and tracking on separate goroutines.</p></pre>jasonscheirer: <pre><p>The Go-specific questions I've been asked at Go shops are mainly bozo filters with obvious solutions: recognizing when you should be using channels, goroutines, etc (e.g. how would you download hundreds of URLs in parallel and save to disk). Everything else I was asked were standard data structures and algorithms questions, API design, etc. which is easier to whiteboard with Python. I've gotten an offer at all three Go shops I've interviewed at over the last couple of years, so that's saying something.</p></pre>PaluMacil: <pre><p>My previous team, in Chattanooga, TN, was about 25% Go, 50% C#, and 25% Python with most of each backend having an Angular front if it wasn't simply an API or data-crunching away somewhere. Interviews would tend to lead candidates to talk about hobbies, favorite things in software development, and other topics that could allow us to gauge if someone enjoyed programming. Specific skills are nice for frontend, statistics, but a love of coding is all people need to learn Go. Our job postings and interviews didn't mention Go as a requirement.</p></pre>xbooing: <pre><p>Really only Google uses it hence the name.</p></pre>
