EmbeddedRelated.com
Blogs

The Self-Directed Virtual Internship

Steve BranamMay 3, 2020

A number of my LinkedIn connections are college and university students at the bachelor's, master's, and doctoral levels, from all over the world. The embedded systems community constantly amazes me.

One fallout they're experiencing from COVID19 is cancellation of summer internships. This is very unfortunate, because an internship represents maintaining educational momentum and preparing for launch of a career with a taste of the real working world, along with some financial income.

I like to have plans, backup plans, and backup plans for the backup plans. The backup plan for these folks is to seek unpaid remote internships.

But the hard reality is that those will be few. It's an enormous logistical hurdle for companies struggling to survive this crisis to add interns of any kind to their concerns.

This post is a backup to the backup plan. You may find it impractical. But in unusual circumstances, we must turn to unusual solutions.

Let's strip the concept of internship down to those fundamentals of educational momementum, career preparation, and a taste of the real working world.

The (Backup To The Backup) Plan

What I'm proposing here is that if you are in this situation, you create your own unpaid, self-directed, virtual internship.

That means you decide exactly what the internship comprises, using the resources you have at hand or can acquire, for equipment, development boards, development hosts, and software tools. What can you achieve with those?

You do it on your own, at home. No employer required.

  • You define the overall plan of the internship.
  • You define the main topic.
  • You define the breakdown of smaller topics.
  • You define the work tasks.
  • You define the work product.

Think of it as independent study.

What you'll end up with at the end of the summer is a set of deliverables that you can show to potential employers. You'll have a project you can list on your resume. What you call it may depend on how it works out. But you'll have something tangible.

Some employers will appreciate that you took the initiative to take control of the situation and actually did something, gaining some actual practical, work-like experience. Some won't. But it gives you a talking point beyond the purely academic items on your resume. That can be the basis for further discussion.

What Should You Do?

There are several ways to approach this, subject to the resources you have available and the time you need to get started.

You need to fill 2-6 months of full-time work schedule. You need to get started doing it within the next few weeks.

Once you do, you need to treat it like a real job, maintaining some kind of 8-hour, 5-day work schedule. You're  working from home, like most of the rest of us in the profession right now, just as if you had real internship working remotely. See Some Advice For Working From Home.

Life is composed of that which we can control, and that which we can't. This is where, in the midst of chaos, you get to take some control. You get to drive your own destiny, at least in some small measure.

What are some possibilities?

  • Was there a class that really got you interested? What about taking one of the problems, case studies, or projects from the class and turning it into an internship?
  • Is there a company or specialization that you really want to focus on? What about doing something related to the field or one of the products?
  • Is there a topic you're interested in that wasn't covered enough (or at all) by your classes? What about something related to that?
  • Is there an aspect of embedded systems you just couldn't jam into your curriculum? What about FPGA's, DSP's, machine learning, vision systems, cryptography, robotics?
  • Was there something you felt you didn't do well enough in? Could that benefit from a deeper review and hands-on practice?
  • Do you have some grand scheme you haven't had a chance to work on? Is this the time?
  • Is there something you've gotten a taste of that you'd like to spend more time on? Any unfinished projects just crying out for attention?
  • Is there an open source project you'd like to contribute to?
  • Is there a fun little side project you've wanted to do, but school got in the way?
  • Is there some new technology you've heard about that you'd like to delve into?
  • Learn TDD (Test Driven Development) and put it to use. More on that below in the Work Tools section.

Expand your mind and your horizons. You just need to be realistic about what you can do in the time available, with the resources you have available.

One thing you should strive for is to challenge your boundaries and stretch your brain. There's no cost of failure. You'll learn a lot either way. Engineering involves a lot of failure and learning from mistakes. That's the human condition.

That stretching may be the thing that makes employers value your internship, rather than another typical ho-hum run-of-the-mill internship. Most technical organizations appreciate striving in the face of difficulties, because that's exactly what a lot of real engineering is.

Looking for some other sources of inspiration? Try these:

  • The Embedded.fm podcast: This has been my go-to for learning about cool new stuff. These are some of my favorite episodes:
    • 179: Spaghetti Reducer: Miro Samek on using FSM's (Finite State Machines) in place of RTOS. He has a spectacularly awesome YouTube series.
    • 263: Experience the Theory: Arizona State University professor Angela Sodemann's RoboGrok.com is an entire college robotics course on YouTube.
    • 258: Security Is Another Dimension: Links to Christof Paar’s fantastic Introduction to Cryptography class, available on you guessed it, YouTube. He also has a cryptopgraphy textbook, which is a fairly conventional formal math text, but the real magic is that he breaks it all down in the videos. So you end up with both the formal and the intuitive presentations.
    • 329: At Least 32-Bits, Thank You: The Zephyr project is an open-source Linux-like OS for embedded systems. You can contribute!
    • 327: A Little Bit of Human Knowledge: TinyML is machine learning on embedded systems. I expect that to be a growing field.
    • 175: How Hard Could It Be? Jean Labrosse wrote the uC/OS operating system and started the company Micrium for it.
    • 53: Being a grownup engineer: Jack Ganssle!
    • 30: Eventually Lightning Strikes, and 109: Resurrection of Extreme Programming: James Grenning talks about TDD (Test Driven Development).
  • LinkedIn Learning: Their courses on FPGA programming finally got me to pay for LinkedIn Professional. Lots of other good courses on Arduino and harware interfacing/programming. Some might be a little too basic if you've already covered the topics in college courses, but they also might cover some new aspects.
  • Udemy: Contains some very industry-specific courses. CAN bus, anyone? So far not as professionally done as the LinkedIn courses, but it's the information I care about.

Once you have an idea, there are several ways to go about it. Depending on your background with the material and your objectives, your internship could be:

  • Project-based: Build a breadboard or protoboard version of some device (or set of communicating devices), using a commercial dev board and some parts. Or just totally on a dev board. This could be a proof of concept or a platform for exploring some technology. The result will be the hardware, the code (visible on GitHub, BitBucket, or some other public repository) and documentation on it (with diagrams).
  • Report-based: Play with some code and hardware and learn some new techniques, and write up an article on it for publication, for a blog or industry journal.
  • Tutorial-based: Learn something and then write up a tutorial on it so others can acquire your knowledge. Publish it on Instructables or some other platform. Or make a YouTube video or series. See Make Your Own Oscilloscope(Mini DSO) With STC MCU Easily for an outstanding example.
  • Open-source-based: Contribute something to an open-source project. It could be something where you have some expertise, or somehing new to you. It could be a new feature, a rewrite, or a major cleanup or bugfix.

Those will be the tangible results that you can show employers when you talk about that unusual internship on your resume.

The One-Pager

Write up a one-page plan (the "one-pager") and list what you plan to do, the things you need, challenges, constraints, issues, available resources, and some form of schedule. Half the reason for doing this is just to make you think it through.

The second half is to allow you to take advantage of my offer I'll tell you about in a moment.

My daughter went to college at Hampshire College, where the concept is that you write your own curriculum, in whatever topic of study you want. You can be as conventional or unconventional as you want. The one requirement is that you submit it to a board of review, and it has to pass muster with them. They are the mentors bringing experience to the equation.

My offer to you: send me your resume and your one-pager at sdbranam at gmail.com, and I'll send you my feedback as a mentor (I'm also open to volunteers to share some of the load reviewing them). If I get flooded, I may not be able to spend much time on them. But I will try and give a reasonable and timely review so that you can act on it.

What are my criteria? I don't know. I'm learning this in real time just like you. But I'll bring my 38 years of experience as a software developer to it. Think of me as a sanity check, more of a cheap compass rather than a precision GPS to guide you. I may not be totally effective in that role, and I can't offer any guarantees. The rest is up to you.

Work Tools

Part of an internship is learning the tools used in the professional workplace. You may have learned some of them in the academic environment. One potential use for some of your time is to learn some of the ones you're not familiar with, perhaps incorporating them into the internship materials. This list is not necessarily exhaustive.

There are free accounts or versions of every class of tool, in some cases limited to small-scale evaluation usage. If you can't afford the full professional versions, at least get some familiarity with the free versions.

Different workplaces place different emphasis on the various types of tools. Not every place will consider all of these important. An essential tool at one place may be considered irrelevent at another. But if I were a hiring manager, my ideal candidate would have some capability with each type.

Office Productivity

These are pretty much assumed knowledge these days, but don't take them for granted. You need to be able to create written documents (with adequate written communication skills), spreadsheets, presentations, and diagrams, and exchange email. These are used heavily in any technical workplace.

  • Microsoft Office
  • Google Drive/Docs/Sheets/Slides/Drawings
  • Libre Office
  • Gmail
  • Visio
  • Gliffy
  • Draw.io
  • Plant UML

Documentation Systems

There are two types of these. One is for sharing information internally in an organization; every place has some kind of wiki or knowledgebase. The other is for creating internal code documentation.

  • Confluence
  • Doxygen

Remote Work Tools

These are used for video conferencing and screen/desktop sharing.

  • Skype
  • Google Hangouts
  • Slack
  • HipChat
  • WebEx
  • Zoom
  • VNC
  • TeamViewer

Source Control Systems

  • Git
  • GitHub
  • Stash
  • BitBucket
  • Mercurial
  • ClearCase
  • Perforce
  • Subversion

Project Management And Bugtracking Systems

  • Jira
  • Bugzilla

Unit Test Environments And TDD

I'm being somewhat aspirational with this one. Many workplaces don't do systematic, repeatable developer-based unit testing, instead relying on separate SQA (Software Quality Assurance) staff to do testing.

But they should. Oh, they really should, because many of the quality and debugging problems that software development suffers could be avoided.

So I'm taking this opportunity to encourage you to make TDD (Test Driven Development) part of your normal software development practice. It would be an enormously valuable investment of your time.

I would say it's as fundamental as learning programming languages and basic electronics. You wouldn't attempt to be an embedded systems developer without those, would you? Don't do it without this, either. This is that third thing they should have taught you in your first year of school.

Why do I feel this way? The actual testing is only one of the benefits. What isn't obvious at the outset, but becomes clear very quickly, is that it drives enormous design benefits.

There are other benefits as well, that you only begin to appreciate once you have them. It will save you years of grief in your professional career.

TDD is a force multiplier for your skills. Want to be a 10X developer? TDD will give you at least a 2X bump. Maybe 4X. Maybe more, because of those design benefits. Really.

The primary reference for this is James Grenning's book; see my Review: Test Driven Development for Embedded C, James W. Grenning. Jeff Langr's book Modern C++ Programming with Test-Driven Development: Code Better, Sleep Better is an excellent follow-up.

Grenning also offers an online course where you can get guided hands-on practice, which is extremely valuable. It's a little expensive for college students, but really worthwhile if you can manage to do it or have an employer pay for it. See my Review: Web-Based Course Test-Driven Development For Embedded C/C++, James W. Grenning.

The Embedded.fm podcast episodes 30: Eventually Lightning Strikes and 109: Resurrection of Extreme Programming that I mentioned above are interviews with Grenning that discuss some of these aspects.

These are the primary unit test environments for C and C++:

  • Google Test/Mock
  • CppUnit

IDE's and Toolchains

Some of these are vendor-specific, some are multi-vendor. You need to be able to do target cross-development for embedded code, and native development for unit tests.

  • IAR EWARM
  • Keil
  • MPLABX
  • TI Code Composer Studio
  • System Workbench for STM32
  • Eclipse
  • gcc-arm-none-eabi
  • gcc
  • LD scripts

Build Systems

These are primarily for non-IDE-based work.

  • Make
  • CMake
  • Scons
  • Meson

Debugging Tools

These are primarily for non-IDE-based work.

  • gdb
  • openOCD

A Final Word

We will get through this. Some day your chance will come to pay it forward, and you can be a mentor for someone else. Hopefully not in similar cirumstances. Good luck!



To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: