> Go's documentation, tutorials, videos, support, community - what forms the ecosystem, basically - is really the reason why I keep coming back to it.
One way to put it is that this highlights Go from a user's perspective.
The very same thing is true from the compiler developer's perspective.
I've found that the process of installing dependencies, pulling source, navigating source, building, testing, contributing patches, etc is important for success--as well as the user experience.
I've had bug-fix patches accepted into Clang, GHC, and Rust. I found Rust to be a bit pricklier than Clang and GHC. I'd like to make time to get a similar experience with Go--I suspect it would be good.
Willing to relocate: Yes
Technologies: C, C++, Haskell, Python, Go,
Linux kernel, Ethernet, IEEE 802.3, TCP/IP,
I2C, SPI, MAC, PHY,
parallel & concurrent programming,
algorithms, data structures
Résumé/CV: http://brpbr.com/ (resume upon request)
Email: brooks !dot* brian ^at% gmail
Looking for an opportunity to create & grow solutions to real-world problems via boundary-less engineering. Over 5 years experience in software for networking devices: L1/L2 Ethernet, Linux kernel, infrastructure, network protocols. Spare time includes contributing to OSS, programming challenges, and learning new technologies & languages.
I've had 9 on-sites in the past 4 months at both large companies and start-ups. A few reflections:
- Sometimes, a "No" means "we like your career trajectory; we've identified you as a candidate that we want to follow up with in ~6 months".
- Sometimes, a "No" means "we really like you; we think you'd be a fit here, we'll be constructing this team in ~6 months".
- Sometimes, a "No" means "we wont relocate; we wont fly you out here; we're only considering local (e.g. Bay Area) candidates".
- Sometimes, a "No" means that it's up to you to reflect on the situation. Take as many notes as you can during the process. Analyze what you said, wrote, acted, etc. It's up to you to determine how you could be better.
- When you get to the on-site and have the opportunity to learn a lot more, things might not be all ponies and rainbows like you'd imagine. Be open to what you didn't want to see, hear, or learn about. You might learn that you actually don't want to work here.
- You're racing against the clock. Balance is key. You hear advice about asking clarification questions, discussing trade-offs, etc. but at the end of the hour one of the most important things is the code you put up on that board. The interviewer will likely whip out their phone, take a pic, and that's that.
- Coding on a whiteboard, with a stranger, in an unfamiliar environment, after traveling many miles... is... challenging. Without much practice, you're at risk to fall flat on your face--I've face-planted my fair share, and it's always fuel to get back at it again.
- Interview as much as you possibly can. You learn about companies, people, technology, industry, challenges, etc. Practice, practice, practice.
- Sometimes, recruiters reach out to you for an initial call (you're excited), and then you learn that members of the hiring team haven't even seen your resume (orly? u think i haz de skillz dear rekrooter?). You then never hear back from the recruiter, or receive an email stating that they're not moving forward. I've only had a couple of these, but it's enough for me to strongly dislike contact before any member of the hiring team has reviewed my qualifications.
Taking a huge risk by saying this (I do not use C++ full-time), but every time I look at C++11 and C++14 I get the feeling that I should just stick with Haskell or <insert-popular-fp-lang-here>. It is insanely more natural to do stuff like this in Haskell. Defer to those with more experience in 'modern C++'.
I use C++ more than full time (gamedev -_-;;) out of necessity (consoles, existing codebase, C++ APIs...)
If I could swing it, I'd absolutely code everything in C#. Okay, maybe that fails the "fp-lang" bit, but my reasons are basically the same ;). Unity's finally getting around to covering the "consoles" bases, although I really wish they weren't using old buggy compilers and writing similarly buggy APIs. Maybe MonoGame will port to Xbox One eventually...