Re: Software Portfolio
There’s something to be said for being at the right place at the right time. I worked at Intel and left for a few months. When i returned to another division, I learned that about 2 dozen people I worked with there all turned in their resignations one Monday morning shortly after I’d left, including my former boss. They went and hired on with a new startup. Among them were a bunch of guys who all graduated from a Master’s program at the same place at the same time. One of them got ostracized and was not invited to join. He got depressed. A mutual friend said he got a call from a headhunter to interview at Microsoft. This was 1981 before they had gone public. He went but wasn’t very excited about it. They apparently offerred him a huge stock option and sign-on bonus, and he finally agreed. He bacame the manager of a very high-profile team. When the two companies went public, the group of guys all became multi-millionaires overnight. The guy they didn’t invite ended up getting enough Microsoft stock that it was worth more than all of his budies combined. He eventually went off to create a little startup of his own, which you’d know if you were around back then, and he made a shit-pile more when that company was acquired by a much bigger fish. I knew these guys, and worked with them on a daily basis. They all would hang out several evenings a week playing D They all left their work at the office. They made fun of me because I’d spend evenings reading computer mags like Byte and Dr. Dobb’s Journal. I also brought some parts home from work and built a little computer that was the size of a RPi that ran an 8088. That got me a job working with a group that was too cheap to buy a symbolic debugger so we had to debug all of the software looking at core dumps and assembly language generated by a C compiler. It wasn’t a lot of fun, and they kicked me out after 90 days. I probably knew more people who becamse multi-millionaires with startups in the 80’s than people from high school who were killed in Viet Nam. Fortunately or unfortunately, I wasn’t in either group. Back then, friends would get together and kick ideas around, noodle around creating stuff, and a lot of the time it led to a startup. Today, nobody really wants to hang out and talk about stuff unless you have some money to pony-up first. I guess that’s because, you know … those FOSS projects people do in their spare time are like little lottery tickets, right? -David Schwartz > On Dec 1, 2022, at 11:00 PM, Steve Litt via PLUG-discuss > wrote: > > David Schwartz via PLUG-discuss said on Thu, 01 Dec 2022 19:48:59 + > (UTC) > > >> I’ve met a few folks who like plaing with open-source projects, but >> none of them ever said they thought it made a difference in terms of >> getting a job. > > This is an anecdote, so take it for what it's worth: A friend of mine > is a developer supreme: He thoroughly understands algorithms, data > structures and protocols at a deep level. He made a free software smart > phone app and maintained it for his users. A couple years later > WhatsApp noticed it, noticed him, invited him to California, hired him, > and when Facebook bought WhatsApp he got a bonus at least if not more > than sufficient for him to buy a Tesla. > > SteveT > > Steve Litt > Autumn 2022 featured book: Thriving in Tough Times > http://www.troubleshooters.com/bookstore/thrive.htm > --- > 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
Re: Software Portfolio
NICE! Sometimes good things happen to deserving people and a good deed goes unpunished. On Thu, Dec 1, 2022 at 11:00 PM Steve Litt via PLUG-discuss < plug-discuss@lists.phxlinux.org> wrote: > David Schwartz via PLUG-discuss said on Thu, 01 Dec 2022 19:48:59 + > (UTC) > > > >I’ve met a few folks who like plaing with open-source projects, but > >none of them ever said they thought it made a difference in terms of > >getting a job. > > This is an anecdote, so take it for what it's worth: A friend of mine > is a developer supreme: He thoroughly understands algorithms, data > structures and protocols at a deep level. He made a free software smart > phone app and maintained it for his users. A couple years later > WhatsApp noticed it, noticed him, invited him to California, hired him, > and when Facebook bought WhatsApp he got a bonus at least if not more > than sufficient for him to buy a Tesla. > > SteveT > > Steve Litt > Autumn 2022 featured book: Thriving in Tough Times > http://www.troubleshooters.com/bookstore/thrive.htm > --- > 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
Re: Skills for the future
Both inflation and deflation are like positive feedback loops or resonance. A central bank can beat inflation into the ground with interest rates (even one like this, which is caused by demand pull, supply shortages, and rising profits) at the cost of a nasty recession (pretty much what the Fed did at the end of the 70's) Deflation is less common, but is really pernicious and hard to fix when it happens. And this has very little to do with Linux, FOSS, or even IT per se. On Thu, Dec 1, 2022 at 10:38 PM Ed via PLUG-discuss < plug-discuss@lists.phxlinux.org> wrote: > you should look up the difference between a recession and a > depression. Odds are we will have a middling recession, but the real > problem is and will be inflation. Inflation is a ratchet, it only goes > in one direction and hits everyone and everything*. It's like a > network that has more and more noise on the line. For context, > consider that people experience something like a half dozen recessions > in their lifetime - more or less. It's the business cycle. > > You already said it - you expect robotics to become more involved so > go do that. Just remember robots are capital intensive - so go with > the big. > > *except for Japan and it's lost decade(s) - they had/have deflation > > On Sat, Nov 19, 2022 at 7:13 AM Keith Smith via PLUG-discuss > wrote: > > > > > > > > Hi, > > > > I am reading and watching YouTube videos that say the economy is going > > to tank to maybe as bad as the depression. > > > > If this is true what skills are going to be in demand. > > > > I suspect there will be a real push to automate things so I'm guessing > > those who can create browser based business web apps and phone apps will > > be in high demand. That will equate to the administrator skills to > > support such things. > > > > I also expect robotics to become more involved in factories, > > manufacturing, and even flipping burgers. > > > > What say you? > > > > Thanks!! > > > > Keith > > --- > > 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 > --- 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
Re: Software Portfolio
David Schwartz via PLUG-discuss said on Thu, 01 Dec 2022 19:48:59 + (UTC) >I’ve met a few folks who like plaing with open-source projects, but >none of them ever said they thought it made a difference in terms of >getting a job. This is an anecdote, so take it for what it's worth: A friend of mine is a developer supreme: He thoroughly understands algorithms, data structures and protocols at a deep level. He made a free software smart phone app and maintained it for his users. A couple years later WhatsApp noticed it, noticed him, invited him to California, hired him, and when Facebook bought WhatsApp he got a bonus at least if not more than sufficient for him to buy a Tesla. SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm --- 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
Re: Skills for the future
you should look up the difference between a recession and a depression. Odds are we will have a middling recession, but the real problem is and will be inflation. Inflation is a ratchet, it only goes in one direction and hits everyone and everything*. It's like a network that has more and more noise on the line. For context, consider that people experience something like a half dozen recessions in their lifetime - more or less. It's the business cycle. You already said it - you expect robotics to become more involved so go do that. Just remember robots are capital intensive - so go with the big. *except for Japan and it's lost decade(s) - they had/have deflation On Sat, Nov 19, 2022 at 7:13 AM Keith Smith via PLUG-discuss wrote: > > > > Hi, > > I am reading and watching YouTube videos that say the economy is going > to tank to maybe as bad as the depression. > > If this is true what skills are going to be in demand. > > I suspect there will be a real push to automate things so I'm guessing > those who can create browser based business web apps and phone apps will > be in high demand. That will equate to the administrator skills to > support such things. > > I also expect robotics to become more involved in factories, > manufacturing, and even flipping burgers. > > What say you? > > Thanks!! > > Keith > --- > 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
Re: SD cards
Thanks. Now it makes sense. On 12/1/22 15:05, Joseph Sinclair via PLUG-discuss wrote: Specifications set minimum requirements, rarely does a specification set an actual maximum limit. In this case, the specification requires that compliant hardware support *at least* the rates specified (within the defined optionality of the specification), but does not bar hardware from supporting higher rates or additional features, as long as the specification is met otherwise. Most likely the manufacturer is quoting the maximum possible rate for their hardware under laboratory conditions and using carefully specified supporting hardware; rather than the real world conditions with various unknown additional hardware elements (e.g. a card reader) and environmental conditions. Basically, you'll probably never see the maximum quoted data rate because some *other* hardware in the system probably won't support it (again, readers *can* support higher speeds, but most won't), but the card *could* deliver data at those rates in a theoretical perfect environment. Most quoted rates do, somewhere in fine print and often only on their website, describe the basis for the claim. With a little digging you can probably find the exact answer if you're curious enough. On 2022-12-01 02:22 PM, Jim via PLUG-discuss wrote: I know this isn't really a linux question, but I don't know who else to ask and I haven't yet found an answer online, but I'm still looking. I'm looking at buying a micro sd card and have found some UHS -I cards that advertize 180 MB/s read speeds and 130 MB/s write speeds, I've also read that UHS - I is supposed to have a maximum speed of 104 MB/s. Are the card makers guilty of false advertizing, or is there some way to get around the 104 MB/s limit? thanks --- 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 --- 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
Re: SD cards
Specifications set minimum requirements, rarely does a specification set an actual maximum limit. In this case, the specification requires that compliant hardware support *at least* the rates specified (within the defined optionality of the specification), but does not bar hardware from supporting higher rates or additional features, as long as the specification is met otherwise. Most likely the manufacturer is quoting the maximum possible rate for their hardware under laboratory conditions and using carefully specified supporting hardware; rather than the real world conditions with various unknown additional hardware elements (e.g. a card reader) and environmental conditions. Basically, you'll probably never see the maximum quoted data rate because some *other* hardware in the system probably won't support it (again, readers *can* support higher speeds, but most won't), but the card *could* deliver data at those rates in a theoretical perfect environment. Most quoted rates do, somewhere in fine print and often only on their website, describe the basis for the claim. With a little digging you can probably find the exact answer if you're curious enough. On 2022-12-01 02:22 PM, Jim via PLUG-discuss wrote: > I know this isn't really a linux question, but I don't know who else to ask > and I haven't yet found an answer online, but I'm still looking. > > I'm looking at buying a micro sd card and have found some UHS -I cards that > advertize 180 MB/s read speeds and 130 MB/s write speeds, I've also read > that UHS - I is supposed to have a maximum speed of 104 MB/s. Are the card > makers guilty of false advertizing, or is there some way to get around the > 104 MB/s limit? > > > thanks > > --- > 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 signature.asc Description: OpenPGP digital signature --- 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
SD cards
I know this isn't really a linux question, but I don't know who else to ask and I haven't yet found an answer online, but I'm still looking. I'm looking at buying a micro sd card and have found some UHS -I cards that advertize 180 MB/s read speeds and 130 MB/s write speeds, I've also read that UHS - I is supposed to have a maximum speed of 104 MB/s. Are the card makers guilty of false advertizing, or is there some way to get around the 104 MB/s limit? thanks --- 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
Re: Software Portfolio
We used a similar process to weed out Support candidates. its amazing how many could not even with an Open internet test. Mainly I didn't care if they got it 100% I wanted to see the process they went through. did they google an error. did they look for similar issues etc. On Thu, Dec 1, 2022 at 2:49 PM David Schwartz via PLUG-discuss < plug-discuss@lists.phxlinux.org> wrote: > Sorry, but this would prevent most people who work for big corporations > from ever getting hired. > > It might work for smaller companies trying to sift through a bunch of > applicants and they need a way to get a little more insight into their > abilities. > > I’ve always been amazed at the off-hours interestes of other devs where > I’ve worked. They seem to go in one of two directions: > > 1) they spend time off-hours working on stuff they enjoy that’s unrelated > to their job; or > > 2) they leave the programming at work and prefer spending time on totally > different things. > > I’ve met a few folks who like plaing with open-source projects, but none > of them ever said they thought it made a difference in terms of getting a > job. > > Keep in mind, these are big engineering companies, not small shops that do > things like build websites. Graphic artists have “portfolios”. Programmers > have “knowledge”. Code embodies knowledge, but doesn’t always reflect it. > Most of what you’ll see is how the organize their code, what their coding > style might be like, what they comment and don’t comment, and if you’re > good enough to recognize different design patterns in the code then you can > get some idea of how they think. If you run the software, maybe you can see > their UI skills. > > However, the chances of what you’re looking at having any relevance to the > job at hand is not very good, based on my experience on both sides of the > hiring fence. > > Reading code is a slow tedious process that leaves more questions than > answers. I want to know how you think and solve problems. > > I was working at a place as a contractor and we had to hire four more > people on the team. Someone arranged for a headhunter, and he showed up one > day with an 18” pile of resumes. After about the first dozen or so they all > started to look the same. The two other colleagues working with me bugged > off and refused to waste their time. What do you do in that case? > > We decided to write up a short questionaire with four questions that gave > us a lot of insight into their understanding of some problems we were > dealing with in our code. We had the headhunter send it out and asked them > to answer to the best of their ability and return it. (Only about half did, > which was really helpful.) We weren’t looking for anybody to answer all > four like it was a Master’s Thesis. We just wanted to filter out those who > had such a limited knowledge of what we were doing that we didn’t have to > even waste our time interviewing them. From that perspective, looking at > code on github is far more time-intensive than scanning a resume and four > more detailed tech questions that applied very closely to our project. > > If someone at a prospective employer has time to waste going through my > github code looking to be impressed, I don’t want to work there because > their priorities are messed-up. I can get what I need just talking with > you. > > -David Schwartz > > > > > On Dec 1, 2022, at 9:46 AM, Stephen Partington via PLUG-discuss < > plug-discuss@lists.phxlinux.org> wrote: > > 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. > > > > --- > 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 --- 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
Re: Software Portfolio
Sorry, but this would prevent most people who work for big corporations from ever getting hired. It might work for smaller companies trying to sift through a bunch of applicants and they need a way to get a little more insight into their abilities. I’ve always been amazed at the off-hours interestes of other devs where I’ve worked. They seem to go in one of two directions: 1) they spend time off-hours working on stuff they enjoy that’s unrelated to their job; or 2) they leave the programming at work and prefer spending time on totally different things. I’ve met a few folks who like plaing with open-source projects, but none of them ever said they thought it made a difference in terms of getting a job. Keep in mind, these are big engineering companies, not small shops that do things like build websites. Graphic artists have “portfolios”. Programmers have “knowledge”. Code embodies knowledge, but doesn’t always reflect it. Most of what you’ll see is how the organize their code, what their coding style might be like, what they comment and don’t comment, and if you’re good enough to recognize different design patterns in the code then you can get some idea of how they think. If you run the software, maybe you can see their UI skills. However, the chances of what you’re looking at having any relevance to the job at hand is not very good, based on my experience on both sides of the hiring fence. Reading code is a slow tedious process that leaves more questions than answers. I want to know how you think and solve problems. I was working at a place as a contractor and we had to hire four more people on the team. Someone arranged for a headhunter, and he showed up one day with an 18” pile of resumes. After about the first dozen or so they all started to look the same. The two other colleagues working with me bugged off and refused to waste their time. What do you do in that case? We decided to write up a short questionaire with four questions that gave us a lot of insight into their understanding of some problems we were dealing with in our code. We had the headhunter send it out and asked them to answer to the best of their ability and return it. (Only about half did, which was really helpful.) We weren’t looking for anybody to answer all four like it was a Master’s Thesis. We just wanted to filter out those who had such a limited knowledge of what we were doing that we didn’t have to even waste our time interviewing them. From that perspective, looking at code on github is far more time-intensive than scanning a resume and four more detailed tech questions that applied very closely to our project. If someone at a prospective employer has time to waste going through my github code looking to be impressed, I don’t want to work there because their priorities are messed-up. I can get what I need just talking with you. -David Schwartz > On Dec 1, 2022, at 9:46 AM, Stephen Partington via PLUG-discuss > wrote: > > 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. > > --- 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
Re: Software Portfolio
Indeed. the best way do build this is if you have a function that irks you, build it, refine it, document it, and then share it. and happy hunting. On Thu, Dec 1, 2022 at 11:56 AM trent shipley via PLUG-discuss < plug-discuss@lists.phxlinux.org> wrote: > Hi Stephen, > > That is what I had strongly suspected -- especially if you don't have much > experience or you didn't just graduate from a top program. I think I'm > getting to the point where I can do more than just little training and test > exercises, so it's time to devote some effort to some demonstrable product, > even if I were to get an entry level position in the field which satisfied > me for a while. (It looks like I might get something soon as a Python web > developer ... which would be a step up from writing automated UI tests in > VBScript.) > > > Trent > > On Thu, Dec 1, 2022 at 9:47 AM Stephen Partington via PLUG-discuss < > plug-discuss@lists.phxlinux.org> wrote: > >> 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
Re: Software Portfolio
Hi Stephen, That is what I had strongly suspected -- especially if you don't have much experience or you didn't just graduate from a top program. I think I'm getting to the point where I can do more than just little training and test exercises, so it's time to devote some effort to some demonstrable product, even if I were to get an entry level position in the field which satisfied me for a while. (It looks like I might get something soon as a Python web developer ... which would be a step up from writing automated UI tests in VBScript.) Trent On Thu, Dec 1, 2022 at 9:47 AM Stephen Partington via PLUG-discuss < plug-discuss@lists.phxlinux.org> wrote: > 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: >>
Re: Software Portfolio
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
