Advice for a young person training to be a software engineer
June 20, 2024 10:23 AM Subscribe
I'm mentoring someone who has just been admitted to a software engineering program at my alma mater. They have some coding experience but no work experience. How best to build a base for a good career?
One idea is to get hands on experience with open source. I've sadly lost touch with the most recent developments. What are the best open source projects for someone at this level? What other things could they do to get a leg up? The student is a keener and quite personable, but they are lacking the tech skills from a real-life development environment.
One idea is to get hands on experience with open source. I've sadly lost touch with the most recent developments. What are the best open source projects for someone at this level? What other things could they do to get a leg up? The student is a keener and quite personable, but they are lacking the tech skills from a real-life development environment.
I don't know know a lot about this event geared towards encouraging OS participation, but it might be worth them signing up for the updates and keeping up to on '24 plans: https://hacktoberfest.com/
posted by snowymorninblues at 10:49 AM on June 20
posted by snowymorninblues at 10:49 AM on June 20
This isn't exactly what you asked, but I would suggest that your mentee take a look at the excellent articles written by software engineer (and entrepreneur) Joel Spolsky:
https://www.joelonsoftware.com/
You may want to start with the "Top Ten" links under "Reading List". Spolsky is a very smart guy and an engaging writer. I'm not even in the industry, and I've long enjoyed reading his stuff.
posted by alex1965 at 11:10 AM on June 20 [5 favorites]
https://www.joelonsoftware.com/
You may want to start with the "Top Ten" links under "Reading List". Spolsky is a very smart guy and an engaging writer. I'm not even in the industry, and I've long enjoyed reading his stuff.
posted by alex1965 at 11:10 AM on June 20 [5 favorites]
but they are lacking the tech skills from a real-life development environment.
If not covered in the curriculum, they might want to have some familiarity with the non-code tools that will probably still be standard in 4 years. Git for scm. Jira (sandbox) for experimenting with creating/reading/organizing tickets. Confluence for out-of-date documentation that no one will read. Slack for venting to a co-worker about whoever wrote this or that ticket, how they may be functionally illiterate. Etc.
If they don't cover it, leaning how to read a bugfix or feature request. Learning how to git pull, build a project and reproduce a bug. Do they teach actual build systems? e.g. for Java it's one thing to turn in an assignment that you compile with javac, but learning maven or gradle is going to be a necessity in an actual job.
Depending on how theory-focused the program is these are some things they could get blind-sided by in their first real industry job. You might know how to write code, but the actual daily grind of software engineering involves a lot of tools that, at least for us, they didn't really talk much about. Lotta quicksort on a whiteboard and math classes, though.
How much of the above they do cover is going to depend on the school. And most of it honestly should be deferred til junior or senior year if it's not part of the curriculum. As they're getting started they should just focus on what's covered in class.
posted by howbigisthistextfield at 11:26 AM on June 20 [4 favorites]
If not covered in the curriculum, they might want to have some familiarity with the non-code tools that will probably still be standard in 4 years. Git for scm. Jira (sandbox) for experimenting with creating/reading/organizing tickets. Confluence for out-of-date documentation that no one will read. Slack for venting to a co-worker about whoever wrote this or that ticket, how they may be functionally illiterate. Etc.
If they don't cover it, leaning how to read a bugfix or feature request. Learning how to git pull, build a project and reproduce a bug. Do they teach actual build systems? e.g. for Java it's one thing to turn in an assignment that you compile with javac, but learning maven or gradle is going to be a necessity in an actual job.
Depending on how theory-focused the program is these are some things they could get blind-sided by in their first real industry job. You might know how to write code, but the actual daily grind of software engineering involves a lot of tools that, at least for us, they didn't really talk much about. Lotta quicksort on a whiteboard and math classes, though.
How much of the above they do cover is going to depend on the school. And most of it honestly should be deferred til junior or senior year if it's not part of the curriculum. As they're getting started they should just focus on what's covered in class.
posted by howbigisthistextfield at 11:26 AM on June 20 [4 favorites]
Software engineering is, at its core, about interacting with people, processes, structures, and concepts. Programming and software development, coding, is the smaller (but in many cases, fun!) part of the practice. The basis of a fulfilling and successful career doing engineering involves a deeply integrated understanding of the disciplines of reliability, quality, and operations; maybe not at RE/QE/OE level of detail, but enough to put them at the heart of their work.
Doing anything—anything at all!—that gives exposure to that stuff helps build better engineers. USENIX ATC is coming up, and USENIX offers student membership rates.
Throw up a k3d cluster, get the ingress going, and deploy some services. Break them. Modify the code, introduce some spectacular bugs, rebuild the images, and redeploy them. Play. Then sit down and think about why things worked at all; why things broke. What was hard to figure out. Write a document that isn't just a list of commands to do the thing, but an explanation of how all the pieces fit together. An explanation that a total stranger could have read and said "oh man, this kid knows their stuff!" Publish it.
Find some piece of code they already use—because I assure you, they use plenty, even if it's just oh-my-zsh or something—fork it, and git clone the repo. Cut a branch. Update the readme so that it's not ancient and out of date, or fix a spelling error. Or add a doc. Or fix all the spelling errors. git add -a; git commit -A ; git push fork my_doc_branch. Read up on how to contribute the PR: are there prerequisites, format things, license or contributor requirements? Cut a PR. Write a great PR comment.
Writing, reading, talking, taking the time to understand, taking the time to collaborate: these are the things that distinguish good engineers from "devs."
posted by majick at 11:27 AM on June 20 [5 favorites]
Doing anything—anything at all!—that gives exposure to that stuff helps build better engineers. USENIX ATC is coming up, and USENIX offers student membership rates.
Throw up a k3d cluster, get the ingress going, and deploy some services. Break them. Modify the code, introduce some spectacular bugs, rebuild the images, and redeploy them. Play. Then sit down and think about why things worked at all; why things broke. What was hard to figure out. Write a document that isn't just a list of commands to do the thing, but an explanation of how all the pieces fit together. An explanation that a total stranger could have read and said "oh man, this kid knows their stuff!" Publish it.
Find some piece of code they already use—because I assure you, they use plenty, even if it's just oh-my-zsh or something—fork it, and git clone the repo. Cut a branch. Update the readme so that it's not ancient and out of date, or fix a spelling error. Or add a doc. Or fix all the spelling errors. git add -a; git commit -A ; git push fork my_doc_branch. Read up on how to contribute the PR: are there prerequisites, format things, license or contributor requirements? Cut a PR. Write a great PR comment.
Writing, reading, talking, taking the time to understand, taking the time to collaborate: these are the things that distinguish good engineers from "devs."
posted by majick at 11:27 AM on June 20 [5 favorites]
Also AWS gives you a free year. Don't waste it. Wait until they're a junior or senior. But also cloud stuff is important. The encroaching reality is that even a fUlL sTaCK application developer needs to know at least a little Docker, kube, terraform, etc. Though I'd think there's probably one or more classes dedicated to infrastructure/devops.
posted by howbigisthistextfield at 11:29 AM on June 20
posted by howbigisthistextfield at 11:29 AM on June 20
they are lacking the tech skills from a real-life development environment
On the one hand, I suspect this means things like delivering software to production according to best practices that can turn out in reality to be situational and adapted pretty specifically within a language ecology and/or a project microculture, so going deep on those things for one or two languages and open source projects could make sense. On the other hand, general topics that come to mind are for a bit father along in their career, but some of this could matter soon:
posted by Wobbuffet at 11:41 AM on June 20 [6 favorites]
On the one hand, I suspect this means things like delivering software to production according to best practices that can turn out in reality to be situational and adapted pretty specifically within a language ecology and/or a project microculture, so going deep on those things for one or two languages and open source projects could make sense. On the other hand, general topics that come to mind are for a bit father along in their career, but some of this could matter soon:
- Paul Luo Li, Amy J. Ko, Jiamin Zhu: "What Makes A Great Software Engineer?"
- Raylene Yung, "The Engineer’s Guide to Career Growth — Advice from My Time at Stripe and Facebook"
- Swizec Teller, "What I learned from Software Engineering at Google"
- Camille Fournier, "An incomplete list of skills senior engineers need, beyond coding"
posted by Wobbuffet at 11:41 AM on June 20 [6 favorites]
someone who has just been admitted to a software engineering program at my alma mater. They have some coding experience but no work experience. How best to build a base for a good career?
Is this an undergrad degree program? If so then besides the open source suggestions, they should do their best to get summer internships between school years at places that do the kinds of work they're interested in. Does the school have job fairs with recruiters from software companies, alumni connections, etc.?
posted by trig at 11:59 AM on June 20 [6 favorites]
Is this an undergrad degree program? If so then besides the open source suggestions, they should do their best to get summer internships between school years at places that do the kinds of work they're interested in. Does the school have job fairs with recruiters from software companies, alumni connections, etc.?
posted by trig at 11:59 AM on June 20 [6 favorites]
When I'm interacting with other developers, the first thing I'm doing is to try and get a sense of their ability to listen and understand the problem at hand. If they are fast to spin up a solution before understanding the full issue I know that we are going to be in for a long and often painful project. Taking classes outside of the engineering building and in the arts / humanities is often a good way to develop those skills.
As for the actual tech, that often changes so fast that any recommendation I can give you today will be replaced by the next best thing in 4-6 years. You have a dozen languages, a dozen frameworks on top of those languages, and another dozen ways to run that code. It is probably best to go wide and play with as many as possible in an attempt to understand the nuances / strengths / limitations of each. This will let them pick the right tool for the job and not try and write an entire enterprise EPR system in something like Python or as a single page JS app.
Another item as the resident grey beard in the group is that the new kids really should learn how the system that they are running on work behind the scenes. In particular, things like dns, ip addresses, and security certificates are a huge black box to most developers. They don't understand them, they assume that they don't need to know anything about them, and they absolutely rely on them every single day to do anything in the real world. I literally just walked out of a Cisco ACI network design meeting before writing this. I am not a network admin, but I need to know what the network system is capable of doing (or not) and how it is put together as could influence how I design things.
The final thing to bring all of this together is to have them aggressively look for internships for the summer after their sophomore year to get "real world" experience. Bonus points if the school has a relationship with a local major tech company which offers a 50/50 opportunity (usually after their junior year). The local state university has a number of them where the company pays for college in addition to a real salary while the student works for them half time during their junior and senior year.
posted by SegFaultCoreDump at 12:16 PM on June 20 [2 favorites]
As for the actual tech, that often changes so fast that any recommendation I can give you today will be replaced by the next best thing in 4-6 years. You have a dozen languages, a dozen frameworks on top of those languages, and another dozen ways to run that code. It is probably best to go wide and play with as many as possible in an attempt to understand the nuances / strengths / limitations of each. This will let them pick the right tool for the job and not try and write an entire enterprise EPR system in something like Python or as a single page JS app.
Another item as the resident grey beard in the group is that the new kids really should learn how the system that they are running on work behind the scenes. In particular, things like dns, ip addresses, and security certificates are a huge black box to most developers. They don't understand them, they assume that they don't need to know anything about them, and they absolutely rely on them every single day to do anything in the real world. I literally just walked out of a Cisco ACI network design meeting before writing this. I am not a network admin, but I need to know what the network system is capable of doing (or not) and how it is put together as could influence how I design things.
The final thing to bring all of this together is to have them aggressively look for internships for the summer after their sophomore year to get "real world" experience. Bonus points if the school has a relationship with a local major tech company which offers a 50/50 opportunity (usually after their junior year). The local state university has a number of them where the company pays for college in addition to a real salary while the student works for them half time during their junior and senior year.
posted by SegFaultCoreDump at 12:16 PM on June 20 [2 favorites]
Also: does the school's CS department have a good pipeline for placing students, generally? This may not be universal but in my experience many companies hiring both interns and new grads, and definitely the FAANG-type companies that regularly hire both in large numbers, assume that these kids don't have much or any real-world experience. The interview questions are more about theory, logic, or writing some pseudocode to solve some basic problem. Coursework will matter, the school/department's connections and reputation will matter, and work experience will help in terms of competing against other candidates and also having some personal connections, but unless things have changed a lot in recent years, the process of getting a foot in the door in many companies as an intern or new grad often has little or nothing to do with knowing how real-life development actually works.
All of which is to say, they should put effort into their coursework (and maybe department work like TAing or working with professors on projects) and get relevant summer experience, but they should also not stress much about not having any experience yet; real-life development is usually learned on the job. If they eventually discover they're interested in some specific niche, then they can start focusing their efforts in that direction, and see what older students who managed to find work in that niche did in order to get there.
posted by trig at 1:00 PM on June 20 [1 favorite]
All of which is to say, they should put effort into their coursework (and maybe department work like TAing or working with professors on projects) and get relevant summer experience, but they should also not stress much about not having any experience yet; real-life development is usually learned on the job. If they eventually discover they're interested in some specific niche, then they can start focusing their efforts in that direction, and see what older students who managed to find work in that niche did in order to get there.
posted by trig at 1:00 PM on June 20 [1 favorite]
Internships are gold, apply to every one you can. Be super proactive in getting to know the career center staff so they know you are looking. Some schools will have supplemental funding for students that are taking ones that don't pay or don't pay enough.
posted by advicepig at 1:12 PM on June 20 [4 favorites]
posted by advicepig at 1:12 PM on June 20 [4 favorites]
You should not care about any specific programming languages - just pick one and learn to do basic stuff:
read a file. write a file. edit a file.
database stuff. insert/update tables.
Display information. learn to write an error message.
learn math functions.
programmatically edit images.
API that some other company wrote. how to interact with one, in terms of loading keys/etc and reading data in their format.
Learn 3D modeling if interested in graphics/video games.
conditional statements - like if/then/etc
configure a web server - interface with some external interface for sending - texts /emails etc.
use an existing library for something
Do logic with dates and times.
maybe a little bit with alternate encoding like hex or binary or whatever.
do some tech support stuff - learn how to configure a printer. etc.
learn to write a document explaining what they did.
ask them to write some program to do something, and then show it to you.
make sure they like doing all this stuff.
posted by The_Vegetables at 1:41 PM on June 20 [1 favorite]
read a file. write a file. edit a file.
database stuff. insert/update tables.
Display information. learn to write an error message.
learn math functions.
programmatically edit images.
API that some other company wrote. how to interact with one, in terms of loading keys/etc and reading data in their format.
Learn 3D modeling if interested in graphics/video games.
conditional statements - like if/then/etc
configure a web server - interface with some external interface for sending - texts /emails etc.
use an existing library for something
Do logic with dates and times.
maybe a little bit with alternate encoding like hex or binary or whatever.
do some tech support stuff - learn how to configure a printer. etc.
learn to write a document explaining what they did.
ask them to write some program to do something, and then show it to you.
make sure they like doing all this stuff.
posted by The_Vegetables at 1:41 PM on June 20 [1 favorite]
Please learn about refactoring and design patterns.
posted by matildaben at 1:53 PM on June 20 [2 favorites]
posted by matildaben at 1:53 PM on June 20 [2 favorites]
At least in the US, internships are where these skills are learned and a major component of landing a full time job after graduation. Open source contributions are good, but should not come at the expense of doing an internship.
posted by hoyland at 3:33 PM on June 20 [3 favorites]
posted by hoyland at 3:33 PM on June 20 [3 favorites]
I started my career at 27 (no degree) by taking a programming job in a non-technical industry. There are still plenty of companies where being able to do basic automation and data analysis will blow peoples minds and give a new coder a lot of positive feedback and grit. Not the best places to learn good habits, but you can often find things to improve or solve that are very obvious to even a new grad. A summer job at a place like that might be fun.
posted by caviar2d2 at 3:33 PM on June 20
posted by caviar2d2 at 3:33 PM on June 20
I will throw in my experience, not because it will be useful to this particular young person, but because it is a helicopter view of my career and some aspects that remained constant across 47 years until my recent retirement. The language I coded in was primarily COBOL (Common Business Oriented Language), it is ancient. Despite the ancient language, it was still a language and went through a compiler to produce an object program. If that blew up I needed to be able to find the type of failure and in what main or subprogram it occurred. Other times the programs were simple to write, but the algorithms were difficult, such as amortization, pro rata adjustments, checking for violations of government rules, creating ad hoc "what if" scenarios for reporting, allocation of costs and expenses to the appropriate profit or cost center to which the account(s) belonged, insuring loans were properly collateralized, etc.
And after years, and years, and years of this 2014 came along, when it came down from above that our programs would now run under Linux running in the Cloud. They brought in Linux software that would emulate COBOL environments and special compiles and database interfaces, and then we were all doing the same programming but in a new environment. The more things change the more they stay the same. Rewriting all that "legacy" code would not have been cost effective. But the programs did not "blow up" the same way, and it wasn't always easy to tell what program caused the failure. But we adapted and things moved on.
During all this time I still tinkered at home on my Windows and Linux PCs, in whatever language I felt like on my personal/hobby projects. And watching StackExhange and such forums I get the impression that the same fads and fashions go through the more mainstream languages (and design methodologies). So whatever jobs this graduate is going to be working in will not be the same 15, 25 or 30 years later. And I haven't even mentioned AI.
posted by forthright at 4:14 PM on June 20
And after years, and years, and years of this 2014 came along, when it came down from above that our programs would now run under Linux running in the Cloud. They brought in Linux software that would emulate COBOL environments and special compiles and database interfaces, and then we were all doing the same programming but in a new environment. The more things change the more they stay the same. Rewriting all that "legacy" code would not have been cost effective. But the programs did not "blow up" the same way, and it wasn't always easy to tell what program caused the failure. But we adapted and things moved on.
During all this time I still tinkered at home on my Windows and Linux PCs, in whatever language I felt like on my personal/hobby projects. And watching StackExhange and such forums I get the impression that the same fads and fashions go through the more mainstream languages (and design methodologies). So whatever jobs this graduate is going to be working in will not be the same 15, 25 or 30 years later. And I haven't even mentioned AI.
posted by forthright at 4:14 PM on June 20
in priority order:
posted by j_curiouser at 6:59 PM on June 20
- Be easy to work with.
- Be reliable.
- Master your professional competencies.
posted by j_curiouser at 6:59 PM on June 20
a lot of very relevant and marketable experience can be obtained outside of academia by joining a real world commercial project, where you work with other people to help ship and operate some piece of software. internships are one idea. another is getting a part-time software development job while you're studying. if you can land an internship in a team in a globally renown tech megacorp, sure, fantastic. failing that, joining a development team from a small local software product business or some niche software consultancy is still going to give a lot of practical experience, provided there's a few colleagues in the team to work with closely who have a good mix of industry experience & raw ability you can learn from.
the time inside of academia is a good opportunity to soak up material and ideas that you're less likely to get exposed to as a self-directed learner or in commercial projects. learn some theory, take a few math and stat courses (javascript frameworks come and go, but we still use a lot of stuff that Gauss figured out 200 years ago), get some exposure to reading research papers and how to frame and analyse a problem.
become fluent in at least one programming language. this can be done outside of academia and outside of a job, if you're motivated.
posted by are-coral-made at 2:59 AM on June 21
the time inside of academia is a good opportunity to soak up material and ideas that you're less likely to get exposed to as a self-directed learner or in commercial projects. learn some theory, take a few math and stat courses (javascript frameworks come and go, but we still use a lot of stuff that Gauss figured out 200 years ago), get some exposure to reading research papers and how to frame and analyse a problem.
become fluent in at least one programming language. this can be done outside of academia and outside of a job, if you're motivated.
posted by are-coral-made at 2:59 AM on June 21
Maybe you all are just better connected than me, but the only people I knew who got software internships were either connected via wealth or a had a moderately high up family member working for a tech firm.
I mean, good luck if you can find an intership or just go to some firm and start doing software, but that just wasn't available 30 years ago when I graduated college, and since a lot of actual development work has been offshored, I'm sure it's even harder now. I guess it also depends on where you are.
posted by The_Vegetables at 7:27 AM on June 21 [1 favorite]
I mean, good luck if you can find an intership or just go to some firm and start doing software, but that just wasn't available 30 years ago when I graduated college, and since a lot of actual development work has been offshored, I'm sure it's even harder now. I guess it also depends on where you are.
posted by The_Vegetables at 7:27 AM on June 21 [1 favorite]
A note about internships. I work in higher ed and got my undergrad a little over 25 years ago. The career center resources connecting students to internships are much better resourced today than back then, both at the highly ranked liberal arts school I attended and the huge state university I work in today.
posted by advicepig at 7:34 AM on June 21
posted by advicepig at 7:34 AM on June 21
Re: internships, I think the experience can be really different depending on the department's industry connections and reputation. At the programs I was familiar with 20+ years ago, software companies recruited students very actively, and interning over the summer was the norm. None of my friends who interned had connections beyond the fact of being in those programs. This is still the case as far as I know, because companies want to get good talent from good programs that they have a good track record of working with.
But even without that infrastructure, that doesn't mean you can't find a placement; it means doing more legwork on your own, pitching yourself to local companies (including "low-tech" ones where software supports the main activity), and being willing to earn less than you would at a FAANG-type internship. Getting to know upperclassmen and talking with them about their work experience and work connections can also help a lot.
If the program does have a relatively dismal track record wrt graduate and internship placement, then it might not be a bad idea to considering transferring if finding work more easily is the goal.
posted by trig at 8:36 AM on June 21
But even without that infrastructure, that doesn't mean you can't find a placement; it means doing more legwork on your own, pitching yourself to local companies (including "low-tech" ones where software supports the main activity), and being willing to earn less than you would at a FAANG-type internship. Getting to know upperclassmen and talking with them about their work experience and work connections can also help a lot.
If the program does have a relatively dismal track record wrt graduate and internship placement, then it might not be a bad idea to considering transferring if finding work more easily is the goal.
posted by trig at 8:36 AM on June 21
I'll throw in what I knew. I knew I always wanted to get into computers, and I actually spent 2 years at a huge public University in Texas, before a family death compelled me to move to California and reestablish myself in San Francisco, and finished my degree at state uni in Bachelor of Electrical/Electronic Engineering with Computer Science minor, as the school did not yet have a computer engineering program. Let's just say, I did great in digital, but I almost flunked analog, so I barely squeaked by graduation. And from there, I had a relative who hired me as an IT Technician, and it was THERE I learned database, sysadmin, app dev, and more. What I learned in school was Pascal and Modula-II something nobody uses outside of school. Never did get any internship, but did work in the school computer lab as a part of my financial aid package in school.
What advice would I give to a new student getting into coding? Find his counselor ASAP, find out what classes he *must* take, then spread out the hard classes mixed with the easier classes. One may be tempted to take the first year or two easy and do all the easier classes, and be totally overwhelmed in the remaining years. And start networking ASAP. The world of programming and software engineering is moving fast, so anything he learned in school will not be applicable. Instead, he would learn the generalities software engineering, i.e. how-to, and he would have to learn the rest at the next job. It's the networking, and the GPA, and social skills, that may land him an internship. With an internship, he's get both work experience, and understanding how different it is from school. But networking will always be important.
posted by kschang at 9:13 AM on June 21
What advice would I give to a new student getting into coding? Find his counselor ASAP, find out what classes he *must* take, then spread out the hard classes mixed with the easier classes. One may be tempted to take the first year or two easy and do all the easier classes, and be totally overwhelmed in the remaining years. And start networking ASAP. The world of programming and software engineering is moving fast, so anything he learned in school will not be applicable. Instead, he would learn the generalities software engineering, i.e. how-to, and he would have to learn the rest at the next job. It's the networking, and the GPA, and social skills, that may land him an internship. With an internship, he's get both work experience, and understanding how different it is from school. But networking will always be important.
posted by kschang at 9:13 AM on June 21
I used to be a hiring manager for junior positions, reading resumes and interviewing candidates straight out of college. It's been a few years, but I'd be willing to bet that in broad strokes things are still pretty similar:
I'd never require somebody's GitHub account as part of their application, but for somebody straight out of college I would definitely look positively on a GitHub history that showed they'd learned how to submit PRs and get them incorporated. "Tell me about how you became a contributor on this project" is a gimme question as long as they are comfortable talking about what they did.
posted by fedward at 9:46 AM on June 21
- College programs often tend to focus just on one approach. I requested code samples as part of the application, and a lot of what I saw seemed pretty rote, in an implement-this-algorithm way. They might have a bigger project at the end where they have to figure out how to put things together, but some of the new grads I interviewed clearly weren't yet comfortable enough identifying how all the pieces should fit.
- Practical programming often requires you to add a feature to existing code. With recent grads I pretty much had to lay out the tasks in the same implement-this-algorithm way that they were used to and couldn't count on them to take a less specific problem description and run with it. I spent more time than I wanted just breaking down feature assignments into the bits they understood how to do. And if I showed them how I'd solve a given problem, it was surprising how often they'd never seen the syntax I'd use, even in a language they'd used in their classes.
- Since I was hiring people partly to maintain apps written in old, unfashionable languages while their more modern replacements were being prepared, the most valuable thing for me was evidence that they had learned more than one language. If you're only learning how to implement algorithms in Java or Python or whatever, you're not learning the skill of learning languages. If I saw code samples in two languages and you could talk intelligently about both of them, I took it as a pretty good signal that I could also teach you what you needed to know to do the job.
- To the credit of most college programs, they do assign some team projects so people weren't completely new to working with other people. That said, there were definite communication style barriers. I'm pretty sure I made people cry once they were out of my sight, and I'm not even mean! The most common communication problem was that they tended to bottle up when I'd asked them to do something they didn't know how to do, and then they'd be scared to admit when they were stuck. So I had to focus a lot on saying I was there to help, and they needed to come to me with questions ASAP instead of being afraid of asking me things. The one guy I had to fire tended to spin out when he was stuck, and I still feel responsible for letting him down even though by the end I was basically holding his hand to get him through things.
I'd never require somebody's GitHub account as part of their application, but for somebody straight out of college I would definitely look positively on a GitHub history that showed they'd learned how to submit PRs and get them incorporated. "Tell me about how you became a contributor on this project" is a gimme question as long as they are comfortable talking about what they did.
posted by fedward at 9:46 AM on June 21
I am in a position where I occasionally hire entry level developers and my strong, strong advice is: build something real.
It almost doesn't matter what it is, or if it is a commercial endeavor or just some lark or hobby, but build something that works. Care about it enough to understand it, fight through the bugs, and be ready and willing to talk about it. This is markedly different from being one of a team of nine on a Codeschool/Bootcamp who builds something and can rattle off a few keywords but really doesn't understand anything other than the tiny piece they did.
Thank goodness Metafilter doesn't allow gifs, but I always want to refer to the scene in Aliens when they are on the dropship, and Ripley asks green lieutenant Gorman how many missions this is and he responds "38... simulated."
How many COMBAT drops?
The answer doesn't need to be 38, but making something real, and caring about it, causing problems and then finding solutions, doing something to get to an outcome other than "this is what the instructions say is next" - that's the stuff that will make you employable, IMO.
posted by dirtdirt at 10:11 AM on June 21 [1 favorite]
It almost doesn't matter what it is, or if it is a commercial endeavor or just some lark or hobby, but build something that works. Care about it enough to understand it, fight through the bugs, and be ready and willing to talk about it. This is markedly different from being one of a team of nine on a Codeschool/Bootcamp who builds something and can rattle off a few keywords but really doesn't understand anything other than the tiny piece they did.
Thank goodness Metafilter doesn't allow gifs, but I always want to refer to the scene in Aliens when they are on the dropship, and Ripley asks green lieutenant Gorman how many missions this is and he responds "38... simulated."
How many COMBAT drops?
The answer doesn't need to be 38, but making something real, and caring about it, causing problems and then finding solutions, doing something to get to an outcome other than "this is what the instructions say is next" - that's the stuff that will make you employable, IMO.
posted by dirtdirt at 10:11 AM on June 21 [1 favorite]
You should not care about any specific programming languages - just pick one and learn to do basic stuff:
You can pick up some Very Bad Habits and get stuck if you pick the wrong language.
Conversely if you pick a good one and Get Further while Understanding Fundamentals (and not just copy-pasting or codepilot/ai-ing) then you'll do much much better. You can return to janky ones later.
posted by lalochezia at 3:27 PM on June 22
You can pick up some Very Bad Habits and get stuck if you pick the wrong language.
Conversely if you pick a good one and Get Further while Understanding Fundamentals (and not just copy-pasting or codepilot/ai-ing) then you'll do much much better. You can return to janky ones later.
posted by lalochezia at 3:27 PM on June 22
You are not logged in, either login or create an account to post comments
I ask them to start by just picking a few projects that they think look interesting, finding out what tools they use, and learning about the culture. Then see if they can do a pull and get things running, then maybe start with a couple of low-hanging requests. There's a lot that they can do without even knowing how to code - many projects need documentation cleanup, graphics, etc. It's a great way to see the software lifecycle and how it's different from turning in assignments for a class.
posted by chbrooks at 10:42 AM on June 20 [1 favorite]