<p>I often see jobs for senior level engineer with Go experience. I usually associate senior-level with 10+ years work experience in a professional environment since that is what I've seen described with Java and C++.
Since Golang is relatively new, what would be considered senior, advanced, intermediate, beginner?
If you've been working with C for 8+ year's and recently started working with Go for about 2 years, would that count?
I don't know there are a lot of people that would qualify for senior level if you compartmentalized the accurate length of time of work experience.</p>
<p>I guess this goes back to the argument of how much work experience someone actually has if they say 3 years but code for maybe 3-4 hours a day and the rest is all meetings, emails, discussion, etc.</p>
<p>I'm also guessing that not a lot of people used Golang in 2009 right away.</p>
<hr/>**评论：**<br/><br/>cyberal: <pre><p>From my perspective, the Senior title is given to the role of the engineer, based on their total work experience and responsibility level (independently of the programming language they use). In other words, they might be completely new to Go and still have a Senior title. However some companies that care about mastery of Go, might not want to hire someone who is at a Senior level but a newbie specifically for Go (if that's what they care about). For levels of experience specifically related to a technology, I doubt someone would use the Junior/Mid/Senior classification. Instead the inexperienced/beginner/intermediate/advanced/etc classification would be more appropriate.</p></pre>meddlepal: <pre><p>A programming language is just a tool. Usually when I think about seniority I'm thinking about general software engineering experience. How you solve problems might change a little bit in Go due to the lack of generics and untraditional concurrency mechanism but other than that an experience senior level engineer is defined by how they solve a problem not the tools they use to solve it. </p>
<p>If I saw a job for "Senior Level Engineer" with "Go experience" I'd be looking for somewhere around 7-10 years of professional software engineering experience and the ability to bootstrap from scratch and develop a Go program, but I don't care if that person has 1 year or 6 years of experience writing Go. </p></pre>iandthen: <pre><p>Language is a tool, like frameworks, libs and so on. </p>
<p>Principles are the same <strong>for decades.</strong></p>
<p>As for me, I do not recognize myself as <em>Java Developer,</em> I prefer to recognize myself as <em>Software Development Engineer.</em> That is all. Everyday I work with Java, but from time to time I need to develop in Python, NodeJS, Bash, etc. </p>
<p>So you need to understand principles and approaches, not have experience with a tool. </p>
<p>CS is for <strong>SCIENCE</strong>, stop treating it like an experience in individual branch or PL or whatever.</p></pre>kostix: <pre><p>I have recently put up <a href="https://stackoverflow.com/a/49772651/720999" rel="nofollow">a list of what I'm expecting a senior-level gopher to know</a> when they are being interviewed at my $dayjob.</p>
<blockquote>
<p>If you've been working with C for 8+ year's and recently started working with Go for about 2 years, would that count?</p>
</blockquote>
<p>In my book, definitely yes.
Just observe that Go is typically used to implement high-load networked servers, and so you might be expected to possess
reasonable knowledge of how HTTP stack works end-to-end (including kernel syscalls, in-kernel buffering, TCP/IP, HTTP connection reusing etc) and how to assess performance of a process running on a typical Linux-powered system (like what are RSS vs VSZ in the <code>top</code> output, how and why they change etc; what the TCP ephemeral ports are etc etc etc).</p>
<p>I mean, familiarity with C is a huge bonus (as it suggests the person
has a reasonable idea about how "the iron" works) but, say, writing C for
embedded systems with 4K RAM for 10 years might not gain you much idea
about how to write networked servers. ;-)</p>
<p>Hope this helps.</p></pre>CitizenCinco: <pre><p>ah yeah I shoulda used C++ for that example. but I get what you mean</p></pre>JinSantosAndria: <pre><p>Isnt it always a way how you sell it? If you worked 10 years in using a complex language that sports the same major points and features I automatically assume that you know what concurrency, parallelism and stuff like that is. I range adapation of a new language somewhere between 6-24 months at maximum. The first months are pretty worthless, but anything after that could pass a code review and can easily mind-shared/improved with others.</p></pre>etherealflaim: <pre><p>I'd say if you've taught or mentored multiple people in Go and you've convinced upper management to use Go for a project despite opposition, you're probably Senior :).</p>
<p>Shipping a product built with Go helps too.</p></pre>makavelixx: <pre><p>nowadays you have people calling themselves senior developers with 3 years+ experience</p></pre>anonfunction: <pre><p>It’s hardly concrete but one thing I’ve heard is junior developers use packages and senior developers make them. </p></pre>
