

Ask HN: How does an engineer transition to problem solving roles at a startup? - astartupemp

A lot of junior engineers we hire, some of them right out of college for whom this is their first job experience, acquiring some specific skills (like iOS&#x2F;Android development) are not to hard to come by over a year or two. However it is hard to transition them to projects that involve planning and designing a system and then building different components that can work together. What sort of learning curriculum can help an average developer improve their problem solving ability within the context of the start-up given that there might not be very experienced folks to learn from and not too much time available to attend a full time program. The problems aren&#x27;t complex algorithms or anything, just simple application systems that need to work end to end.
======
angersock
My favorite thing to throw people at is working on network APIs, file format
libraries, and SDKs.

The problem space is well-defined and testable--a file either parses or it
doesn't, an HTTP request either produces the desired results or it doesn't--
but the problem space is also limited enough in political and philosophical
complexity that it doesn't distract them from the planning and care and
architecture work they'll need to do to accomplish their goal.

I'm actually rather proud of an intern of mine...in the last month and a half,
their work has been:

1\. Creating an auditing and compliance tool to help meet regulatory
requirements. They were allowed to use whatever they wanted (they chose Ruby
with some cleverness in the programming), and then made something that pulled
from wikis and Github in order to automatically annotate issues and produce
reports showing what had been tested, where, by whom, etc. Simple project, had
some practice extracting requirements (some meetings I sat in on to help
smooth things along), and then they executed wonderfully.

2\. Working with me to draft and specify a binary and JSON format for shipping
realtime waveform data. We did the design work in a weekend, presented the
draft to the CTO, and got it approved for use (which was all expected, but
intern got to learn about politics). This also had several conversations where
I had to push back on good engineering decisions to meet business
requirements, which is important because I could explain both why it had to
happen and acknowledge how frustrating it was for them.

3\. Worked on the Ruby and C library implementation of aforementioned spec,
and then they took over my C# implementation when I ran out of free cycles to
work on it...basically the testing and verification work that I hadn't
finished. The project is about done enough to ship to our partners for use.

4\. (not started yet) will be native Ruby and Python bindings for working with
our data collection platform, and maybe JS bindings too. This will expand on
their experience doing documentation and testing, and give them a pretty free
hand in doing larger architecture work on important things, but still with
limited scope and no politics so that they'll learn a lot.

~

The previous summer we had an intern who wasn't experienced enough in
programming to take to that sort of work, so I instead had them working on
doing test data generation and simulation. That worked out alright, but our
business folks kinda kept sticking their noses in and interfering with what
they were working on--"Hey, you like art, can you do logo design?", "Hey, we
need this data set, can you just hand generate it?", "Hey, we need an
inforgraphic...". Worst thing ever.

~

Basically, give them:

    
    
      1. Work that is important to the company.
    
      2. Work that is technically straightforward (doesn't have to be _easy_).
    
      3. Work that does not block on or blocks anyone else.
    
      4. Work that does not cross political boundaries. They talk to you, or you both talk to customer.
    
      5. Work that requires planning and implementation correctness.

