Ask HN: How does an engineer transition to problem solving roles at a startup?
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/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't complex algorithms or anything, just simple application systems that need to work end to end.
1 comments
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:
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.