I will be brutally honest. When I review what someone has done the resume is less impressive than the work done when it comes to software. Anything you can opensource and share with the public do so. make a website that is based on the same domain as the same email you submit resume's on. link any working demos you may have. link your projects via git so they can look at what you make. Keep a project journal someplace and make that available. You can be the best dev in the world. but unless you can show off what you do nobody will have an idea. Resume's are for headhunters mostly. they look for buzzwords and consistent work. as well as references. On Wed, Nov 30, 2022 at 3:53 PM Joseph Sinclair via PLUG-discuss < plug-discuss@lists.phxlinux.org> wrote: > Some thoughts that may help (in addition to the good advice from Keith, > Steve, and David). > 1. Working on some open source software in Github is a good place to build > a "here is what I have done" portfolio. Github has pretty good public > analytics showing all your public commits and pull requests, as well as > issues, reviews, etc... I've used github history to understand engineering > skill, practice, and approach for both candidates and coworkers. > 2. What to work on depends a lot on what you find interesting. If you > want to work on Java or other JVM languages (e.g. Scala), I can probably > make some suggestions (ping me off-list for detail) for open source > projects to work on; if you can be patient I might be able to provide some > *light* guidance on some of those. > 3. The extreme majority of companies are terrible at interviewing. It's > not entirely you that's bad at interviews; the company is probably about as > competent interviewing software engineers as the average garden slug. > 4. You can try an approach I've seen some people have good results with. > A number of companies have started using things like HackerRank to > (foolishly in my opinion) "test" potential hires. It's relatively simple > to work through the "challenges" and "tutorials" on that site if you have > time. Completing the majority of those both makes it simple to pass these > "test" interviews (whether you know how to design software or not), and can > also produce a large visibility boost if you want to find work with one of > the companies that use the service for hiring. > > Side note (OT and rant, skip if not interested in curmudgeonly rants). > Using canned "code challenges" as a pass-fail "test" is about the > stupidest way to vet software professionals ever. High quality engineers > are not faster programmers (and make no mistake, HackerRank is mostly based > on "get the 'correct' solution fast"). High quality engineers produce > designs that meet requirements better, are more secure, perform better, are > more reliable, and/or cost less to maintain and operate. The fact is that > people interviewing engineers don't know how to evaluate engineering skill > so they fall back to "objective" tests, and end up filtering *out* the very > people they want. > I want to be clear, asking a coding problem isn't bad; provided the goal > is to listen and observe problem solving, however, not get a "right" > answer. Most people I interview never complete my coding problems; but I > learn a lot about how they approach problem solving in the process. > What's the alternative, though? I advocate dropping the "interrogation" > style interview entirely. If you have to dig and manipulate to get truth > from the interviewee, then you should not hire them at all; they cannot be > trusted. Focus on a clear, honest, open, adult conversation and mutual > learning instead. Ask questions about what the candidate can do, wants to > do, interests, and expectations. Learn, both directions, if and how the > candidate may meet the needs of the business, and if the position offered > will meet the needs and expectations of the candidate (not everyone wants > every position, nor should they). > I have found, through hundreds of interviews, on both sides of the table, > that an honest and open conversation is many times more successful than the > typical approach. > > On 2022-11-29 08:50 PM, trent shipley via PLUG-discuss wrote: > > (Lead buried in last two or three paragraphs.) > > > > Hi, > > > > I've been in software writing positions on-and-off since about 1999. I > > spent a couple years teaching myself Oracle SQL and PERL in 1999 and 2000 > > for a nice application in the phone industry, then I had a long bout of > > unemployment, with some false stats on contract programming positions > along > > the way. During that time I complimented my degrees, which included a > math > > major, with an MS in Information Management (really IT management) and a > > certificate in programming from Rio Salado, a couple years programming > > software tests in VBS for Micro Focus UFT One--which ceased to be very > > challenging by the end of two years. Recently, I did a pre-apprenticeship > > program with a local company with a software developer apprenticeship > > program (TechOne IT) which basically worked out to a slow-paced virtual > > boot camp in anticipation of an initial contingent > placement/apprenticeship > > proper. > > > > Right now my current employer (The Precisionists Inc)--which is > specialized > > in semi-supported contingent employment for autistic, neurodiverse, and > > other disabled people (in that order) has me on the bench, but I'm close > to > > getting a new position as a Python web developer ... for which, I could > be > > more unqualified, but not much. > > > > After lackluster success with the equivalent of more than an AS in CIS > > specializing in programming. I have concluded I face a few obstacles. > > > > 1. I'm autistic, so I can't interview worth a damn. > > 2.a. There is a tremendous shortage of doctors and nurses, but no one is > > going to hire one who hasn't graduated from an accredited program, done > an > > internship successfully, and passed their credentialing exam ... unless > > it's as a drug salesperson. > > 2.b. There is a tremendous shortage of software writers, but no one is > > going to be studpid enough to hire one until they have completed an > > accredited degree, done an internship, done a bootcamp, and maybe gotten > > some certs. I've only done the first. > > > > I've been looking at maybe putting together a "software portfolio". > > > > The stuff on the internet is focused on web-developer portfolio and seems > > to be really describing a visually appealing website which is partware > > between a resume and CV, but much closer to a friendlier more personable > > website--which to pay to have made since you aren't a web designer. > > > > I was thinking more, "this is my public GitHub account and this is > software > > I've written." > > > > Between school and the recent quasi-bootcamp, I should know Java well > > enough to write something useful in it. > > > > I'm partway through a Scala basics book, and I love it sooo much. > > > > I'd like to write more than just toys, maybe starting with little > > utility-like things (but all the good ones seem to have been done) or by > > doing maintenance or little chores on a Java- or Scala-based open source > > project, which raises the question of how to find a not-dead project I > fit > > well with and which can use my not-MIT grade talent and knowledge. > > > > I'd really like advice on how to put together a public software > portfolio > > which is also of practical use (well, of some kind of use to others, even > > if not terribly practical.) > > > > > > Trent > > > > > > > > --------------------------------------------------- > > PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org > > To subscribe, unsubscribe, or to change your mail settings: > > https://lists.phxlinux.org/mailman/listinfo/plug-discuss > > > > --------------------------------------------------- > PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > https://lists.phxlinux.org/mailman/listinfo/plug-discuss > -- A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button. Stephen