<p>Thing is that I am looking to learn Go and after learning will want to get hand my hands dirty. So would like to know from experienced people what projects will help my portfolio to be shortlisted atleast for interview?</p>
<p>Also what projects can help me acquire skills require to pass a golang backend related job interview?</p>
<hr/>**评论：**<br/><br/>malibu_danube: <pre><p>REST API, map/reduce, really any back end application written in Go is all you need to practice writing. I'd also focus on TDD and using Go's benchmarking package for learning the language the socratic way. </p>
<p>I programmed a simple Todo for my portfolio but I made it robust using several features of Go and Vue.js I had bst search, doubly linked list goroutine traverse (starting from both ends of the list simultaneously to find stuff), cache using maps, authentication, CORS, logging, error handling and more. The key is pick something you can do in your sleep and build features as you learn the right packages and syntax. </p>
<p>Good luck!</p></pre>AdvancedPizza: <pre><p>Very cool. Did you handle authentication with cookie based sessions? Or something more fancy like jwt?</p></pre>FrancisMcKracken: <pre><p>Build a real world "production" REST or gRPC API:</p>
<ul>
<li>Scalable, must be able to run more than one instance.</li>
<li>Dockerized, <a href="https://kubernetes.io/docs/getting-started-guides/minikube/">runnable on minikube</a>.</li>
<li>Unit tested, must be able to run "go test ./..." directly from clone.</li>
<li>Integration tested, recommend docker-compose.</li>
<li>OpenAPI/Swagger (or similar for gRPC) documented.</li>
<li>dep vendored, but using the standard library often, instead of piling on dependencies.</li>
<li>Authenticated and Authorized via apikeys and/or user accounts.</li>
<li>Built and tested via CI: Travis, CircleCi, etc. Recommend Makefile for task documentation.</li>
<li>Flag & ENV config, API keys, ports, dev mode, etc.</li>
<li><a href="https://blog.codinghorror.com/code-tells-you-how-comments-tell-you-why/">"why" comments, not "what" or "how"</a> which should be clear through func/variable names and <a href="https://blog.golang.org/godoc-documenting-go-code">godoc comments</a>.</li>
<li><a href="https://blog.golang.org/context">Use of Context</a> to limit request time.</li>
<li>Leveled JSON logging, <a href="https://github.com/sirupsen/logrus">logrus</a> or similar.</li>
<li>Postgres/MySQL, <a href="https://github.com/jmoiron/sqlx">sqlx</a> or an ORM.</li>
<li>Redis/memcache for scalable caching.</li>
<li>Datadog, New Relic, AppDynamics, etc for monitoring.</li>
<li>Well documented README.md with separate sections for API user and service developer audiences. Maybe even include graphviz or mermaidJS <a href="https://tallyfy.com/uml-diagram/">UML diagrams</a>.</li>
<li><a href="https://chris.beams.io/posts/git-commit/">Clean git history with structured commits and useful messages</a>. No merge master commits.</li>
<li>Passing go fmt, go lint, or better, go-metalinter in the CI.</li>
</ul>
<p>Show me that, or even half of it, on Github/Gitlab with some open source contributions and I'd be arguing to hire you. Note: I'm not saying this is required to be hired.</p>
<p>Edit: Formatting and links.</p>
<ul>
<li><a href="https://peter.bourgon.org/go-for-industrial-programming/">https://peter.bourgon.org/go-for-industrial-programming/</a></li>
<li><a href="https://blog.csnet.me/blog/building-a-go-api-grpc-rest-and-openapi-swagger.1/">https://blog.csnet.me/blog/building-a-go-api-grpc-rest-and-openapi-swagger.1/</a></li>
</ul>
<p>EditEdit: You do not need all of this just to get a junior level job. Many developers will not get to all of this at first, especially since when needing to balance time/resources vs shipping. Long term, it should all be there for a production system.</p></pre>datavinci: <pre><blockquote>
<p>Build a real world "production" REST</p>
</blockquote>
<p>Hey, if u don't mind could you please elaborate on this?</p></pre>FrancisMcKracken: <pre><p><em>I'm assuming what you are asking, but please rephrase and ask specific questions, if my assumption is incorrect.</em></p>
<p>I'm suggesting building a backend service/application API as if it were real important production software. The actual code is just part of the process of writing maintainable systems. I don't care if you can balance a red/black tree in an interview. In fact, if you submit a PR where you've <a href="https://en.wikipedia.org/wiki/Not_invented_here">NIH</a>'d one, I'll tell you to <a href="https://github.com/sakeven/RbTree">use an existing library</a> (link for example, not specific recommendation.) I want to know if you can write tested, monitored (error rates and overall metrics), maintainable, software following Go and software engineering best practices. It could be the common "todo list" or something more interesting, such as a video processor using ffmpeg to convert anything to web video formats with background workers. The actual function is less important, unless it's something unique and useful in its own right.</p>
<p>That's also why open source contributions are interesting to me. Does this person give back to the community on business or personal time? Even just a bug report. How do they handle code review? Have they used correct grammar and spelling? (Not needed on reddit, but important in a business environment. Haha) Are their PRs clean and organized? In summary, will they help or hinder my team?</p>
<p>I should probably mention: I am speaking for myself and many people I know. Some engineering interviews do just want that, IMHO silly, red/black tree. I am an engineer who does interviews, not on the recruiting team though. </p></pre>SeweragesOfTheMind: <pre><p>I would add instrumentation for metrics to this list as well.</p></pre>AdvancedPizza: <pre><p>This is a great checklist for any project, not just go IMHO. Thanks for writing!</p></pre>beowulf_71: <pre><p>Use RAML over OpenAPI.. so so much better for API design.</p></pre>FrancisMcKracken: <pre><p>Haha, now I want to use it myself. I got dropped into a codebase already using OpenAPI and in the interest of consistency used it in the next project.</p></pre>beowulf_71: <pre><p>You are missing out. The reason everyone gravitates to OpenAPI is the idea/name, and the tools. Which is not a bad reason. However, I tend to think if you are designing APIs with something like OpenAPI, you would be much happier using RAML. The good thing is Mulesoft has donated the AMF tool to OpenAPI (not sure the exact status yet on this though.. e.g. if its ready to be used), but AMF (API Modeling Framework) is basically the ability to take any api spec (right now RAML and Swagger 2) and convert them to any other API spec. I believe Swagger 3 is not far off, and others like APIary, Blueprint, etc should all be possible. It is a sort of intermediary API definition that can then be used to translate to any other API spec. Why do this... well while RAML has some good tools (RAML2JAXRS, RAML2HTML and RAML2POJO (Java pojo generator from RAML Types), they were not as adopted as Swagger was before OpenAPI. Sad thing is OpenAPI didnt even consult with Mulesoft and RAML... they just adopted Swagger.. which is odd that the better format was not even considered. </p>
<p>At any rate, assuming AMF is usable, you can design with RAML 1 and bask in the glory of an awesome API spec to work with, and still generate code, tests, etc using OpenAPI tools if you want. </p>
<p>I am a hard core API first sort of developer. I see the magic in providing APIs that can be consumed by 3rd parties, UIs, etc over writing a bunch of code first, then trying to retrofit an API onto it using the way most swagger users go..which is add swagger annotations into their code (yuck) to then generate a swagger json file, then go back and generate tests, docs, etc. I much prefer the API first, generate everything from single source of truth route. Also.. I dont have to remember to keep my annotated API in sync with code changes.</p>
<p>But that is just me. :D</p></pre>Redundancy_: <pre><p>The chances are that if you're applying for a more junior position, they will expect to have to train you up to work with their stack. What they're going to be looking for is that you can write code that isn't a mess, have enthusiasm for learning and have a little experience in something backendy. </p></pre>SeriousM00nlight: <pre><p>Build an open source project for fun or because it’s something you (or others) would re-use in other projects. Open source is probably the most important thing in the world. Ensure it has test cases too. Then run all the lint and cyclo tools out there on it. Optimize it if you can. That way you can show how you solved a problem and then how you improved upon it and its performance. Following community best practices as well, you can really demonstrate a level beyond just knowing the language.</p>
<p>If I’m looking at two candidates and one “just knows some Go” and the other “cares about how they write Go” ... guess which one is getting hired?</p>
<p>You don’t need perfect code - you just should demonstrate initiative and thoughtfulness.</p></pre>cjbprime: <pre><p>I'd try doing this MIT lab and put the result on GitHub linked from your resume: <a href="https://pdos.csail.mit.edu/6.824/labs/lab-raft.html" rel="nofollow">https://pdos.csail.mit.edu/6.824/labs/lab-raft.html</a></p></pre>im_10xer_bro: <pre><p>Are you a student at MIT? If not, how'd you get a copy of the project skeleton/tests?</p></pre>cjbprime: <pre><p>It's on GitHub as well as their own public site.</p></pre>xwnatnai: <pre><p>Gonna say something unpopular: blockchains contributions/implementations.</p></pre>titpetric: <pre><p>Have an upvote, sorry for your downvotes. I feel like you'd get some upvotes if you wrote <code>distributed append-only database</code> instead of <code>blockchain</code>.</p></pre>xwnatnai: <pre><p>Thanks. That’s alright. I saw it coming. Blockchain has become somewhat of a bad word amongst programmers these days.</p></pre>sOundsoFpErsistence: <pre><p>Blockchain gets a bad wrap as far as I'm concerned. Immutable ledgers have been largely ignored <em>(by the population at large, not researchers)</em>, and can prove some interesting advantages and problems.</p></pre>Redundancy_: <pre><p>On the other hand, there's really stupid funding hype for anything featuring the word "blockchain" too and plenty of startups "mining" that. Expect quite a few unemployed blockchain programmers when that bubble bursts, and beware when applying to a one.</p></pre>sOundsoFpErsistence: <pre><p>Yea, I'm mildly speaking as a developer writing things. It's a tool in a bag that was not often talked about, especially in the context of content addressable storage.</p></pre>xwnatnai: <pre><p>There are several constraints presented by the nature of distributed immutable ledgers with multiple masters (ie all nodes can write) that make their codebases pretty good educational tools for a go programmer, even if you don’t usually do work that involves this kind of distribution. </p></pre>tv64738: <pre><p>Certificate Transparency's merkle tree is really cool.
Bitcoin is just people burning coal and polluting for the sake of greed.</p></pre>sOundsoFpErsistence: <pre><p>And is too closely tied to the word "Blockchain". Guessing hashes does not a blockchain make, imo</p></pre>mcandre: <pre><p>Send PRs to Docker, Kubernetes, packer</p></pre>titpetric: <pre><p>Sorry to rain on your parade, but this seems like bad advice.</p>
<ul>
<li>The projects are complex, meaning you'll never showcase a larger part of your abilities even if you submit some PRs,</li>
<li>Sending PRs to large corporate projects means you'll have to navigate their politics and roadmaps as well,</li>
<li>If you're doing all this, most likely you'll apply for a job there (google, hashicorp, docker, related vendors like redhat/microsoft/etc. who are working on k8s mostly)</li>
</ul>
<p>But apart from that, the only benefit is that you can put <code>[Docker, Kubernetes, Packer] contributor</code> on your CV. It might get you a second round interview because the paper looks good. If that was your intent, sure, it can't hurt. If somebody drills down a bit to find your contributions, it's not going to make much difference in the hiring process, most likely.</p></pre>blahism: <pre><p>You don't have to solve world hunger by submitting PR's to these projects and if you do learn how to navigate politics and roadmaps, then you will earn that job much quicker because the reality is being a software developer is 90% navigating politics and roadmaps and 10% writing...</p></pre>titpetric: <pre><p>Are you sure you’re not a technical manager? ?</p></pre>bigkraig: <pre><p>If they are asking this kind of question they likely do not have a lot of skills to showcase. Being able to contribute to large existing codebases is a valuable skill, internally or externally.</p></pre>titpetric: <pre><p>It doesn’t hurt, that’s true. It does seem overkill (in terms of effort vs. payoff) for something that seems to be a junior position however.</p></pre>the4ner: <pre><p>Make sure you know and understand goroutines and channels well</p></pre>zeromint: <pre><p>How about a subscription management platform in Go?</p>
<p>See: <a href="http://killbill.io/" rel="nofollow">http://killbill.io/</a></p>
<p>Contributing to an existing project would be difficult. Starting your own from scratch will help you showcase your abilities.</p></pre>bigkraig: <pre><p>anything related to kubernetes</p></pre>dasper12: <pre><p>Me, I am working on a some Kafka consumers. Read from a queue, process the data, save to a database, and add channels for concurrency. Not too hard but still involves a good set of tools. </p></pre>goodcryptoman: <pre><p>Check this collection of golang libraries.</p>
<p>30k stars
<a href="https://github.com/avelino/awesome-go" rel="nofollow">https://github.com/avelino/awesome-go</a></p></pre>purpleidea: <pre><p>We mentor new golang hackers over at <a href="https://github.com/purpleidea/mgmt/" rel="nofollow">https://github.com/purpleidea/mgmt/</a></p>
<p>Ping me in #mgmtconfig IRC on Freenode if interested.</p>
<p>Good luck!</p></pre>
