Live data from Hacker News

My dad's resume and skills from 1980

github.com

451–460 of 611 posts

Re: My dad's resume and skills from 1980

#451
post #231

Earlier quoted context omitted.

No, I'm strongly implying that many recruiters will just change resumes with minimal regard for the truth. Note the difference between FOOlang and FOOLAND, among other things...

Woah, that is way more insidious than I was expecting. I get what you mean now, and that just seems really stupid on the recruiter's part. Doesn't it come out during the interview process if there's BS on the resume? But I'm guessing that's your point, right? Because the hiring manager should notice, and the interview process should screen for it, so this must be a symptom of much larger scale dysfunction in the tech…

> Doesn't it come out during the interview process if there's BS on the resume?

Oh yes. As the candidate this is also great when the interviewer says something like “It says here you’ve worked with x” and you go “I’m fairly certain that that wasn’t on there when I submitted the resume (to the recruiter), let me see that” and it turns out like the OP said, extra skill added in a different font.

Re: My dad's resume and skills from 1980

#452

Earlier quoted context omitted.

My father was a physicist. He learned to program in FORTRAN in the university in the 70's. Decades later I, still a teenager, asked him something like this: "Dad, you were a FORTRAN programmer and physicist in the 70's, you could be a very well paid developer anywhere in the developed world... why didn't you?"; he answered me: "I didn't thought this thing about computers would go too far."

We probably are close to the same age. My dad was an engineer who also learned to program FORTRAN in the 70's. When I asked him a similar question his reply was (quotes are paraphrased): "It was way too tedious to do. You'd spend hours getting the cards just right. We used to put them in a shoebox and mark them with a pen in case we dropped them on the way to the lab. Then you'd wait until the next day to get your re…

I agree with your father that batch processing (cards) is a drag.

I was in school and working in the computer lab when we switched from batch processing (cards) to a time shared system with terminal labs. I was part of the team that wired up the campus and connected the campus to the ARPANET (precursor to the internet).

As we rolled out the terminal labs, each CS class was either assigned to batch processing or time sharing. Since I was part of the lab, I could schedule my classes to be time share only. I was only stuck with 4 classes not in the time share lab. 2 were batch processing. For some reason my LISP and AI classes used a teletype interface. It was not as bad as the cards, but still weird. Some classes allowed me to use my personal computer (TRS80) and work at home.

At the time my uncle was a programmer. He said that there was no future in CS and I should switch majors. I could already see the wave coming and ignored the advice.

Re: My dad's resume and skills from 1980

#453

Earlier quoted context omitted.

> Hire someone right away and let them quit if they want to and hire someone else. It's just business for crying out loud. You're not hiring construction workers, you're hiring architects. It often takes more than 3 months to get used to a new codebase and understand how and why things are done the way they are.

And sometimes you are hiring construction workers, and sometimes trade-specialists. I've hired contractors to address specific tech-debt, or accelerate QA on project, to implement a CRUD type stuff for things with well-known approaches that just take time.

Well, then may be it's important to note that we are talking about two different industry niches and practices from one of them are not a good match for the other. And may be we even should come up with some kind of names for these kinds of "tech" to avoid mixing one up with the other.

Re: My dad's resume and skills from 1980

#454
post #144

Whoever can type a resume of that length in a typewriter with no errors I would instantly hire. Such level of attention to detail is extremely rare these days.

Most likely, someone with the initials "sd" typed out that resume rather than Ray Livesay

was wondering what that meant

Re: My dad's resume and skills from 1980

#455
post #197

Earlier quoted context omitted.

As Seymour Cray said, "The trouble with programmers is that you can never tell what a programmer is doing until it's too late." It can be months (at a high salary) before you really know whether a hire is likely to work out. I think it makes sense to invest more effort in screening applicants in this case.

I know a company that hired a contractor, who (probably) sat on his ass for months, then went AWOL with nothing delivered, and said company had to start over from scratch. Probably a little too much trust there.

I know a contractor who started a gig and it was over a month before he was given a logon, let alone a computer.

That started the contractor looking elsewhere...

Re: My dad's resume and skills from 1980

#456

Earlier quoted context omitted.

> Hire someone right away and let them quit if they want to and hire someone else. It's just business for crying out loud. This is missing the point of interviewing. The goal isn't to find any warm body to fill the chair, the goal is to find someone qualified to do the work who also has a history of doing good work at previous employers. You also don't have unlimited headcount and hiring budget, so it's worth making…

I actually very much agree with this comment. I was a manager for 25 years. A bad "team fit" was not good. I never had a technical failure in my hires, but I did have a couple of "bad cultural fits." These usually weren't toxic people, but people that couldn't handle the responsibilities and pressures (we were a small, high-functioning team, and everyone's visibility was fairly high). But this: > who also has a histo…

Amen to that. We hired a guy that just completely polluted the office morale. We were small and wanted to do the "right thing" so we tried to figure out how to make it work for way too long. Finally ended the relationship and the whole place felt better. He wasn't a bad guy, just didn't fit somehow. He was really big on "lanes," didn't handle code review well, and on and on... Important lesson learned. It would have been better for him and us if we had ended it much sooner.

Re: My dad's resume and skills from 1980

#457
I knew Richard Siegel.

My stepfather Marty Einhorn was part of a developers' association in San Diego back in the '70s/'80s. I don't remember the name of it, but I used to go occasionally as a kid. I met Richard Siegel there several times -- seemed like a nice guy.

Re: My dad's resume and skills from 1980

#458

Earlier quoted context omitted.

There are many problems with your resume, and lack of fancy design is not one of them. - Half of your CV is empty space - Dates are formatted really badly, no one would be able to get a good grasp on your project and work timeline quickly - You have a game project that spans several years, and you sum it up into one sentence. Why are you doing that? It's one of your main selling points, and you don't expand enough on…

If I got this resume from a junior I would hire them assuming the interview went decently. Half is empty - just graduated, can't expect that much stuff to put there. Maybe I should have expanded more on the game but I was getting the impression nobody cared that much about personal projects. The very first two things you do with a resume are match up the list of technical skills with the list of tech in your position…

> The very first two things you do with a resume are match up the list of technical skills with the list of tech in your position requirements, and check the education requirement. That's why those two go at the top.

That is what you do. The very first thing I check is where they worked before and how they describe what they did there.

In the case of juniors, that’s replaced with looking at basically anything they did and how they describe it.

By the time the CV gets to my desk the keyword matching is already done.

While the resume isn’t necessarily bad, it screams to me that the candidate didn’t even bother to look at, or didn’t care how a CV is normally structured/laid out before handing theirs in.

It’s not necessarily bad, but when looking through a bunch of them you don’t really want to adjust your mental parsing model for every resume, so barring anything else about it that stands out, you just mentally dismiss it.

To be fair, this is something I’ve seen more from people just leaving school.

Re: My dad's resume and skills from 1980

#459

When I first entered the working world as a programmer and administrator of an "academic computing center", in the early 70s, you met men like Ray - ex-military, GI-bill educated, learned computers from the electricity on up in their mid-career, rather frequently, either as customer engineers for one of the big mainframe manufacturers (there were 7 or 8, depending on when and how you counted), or from the minicompute…

My father was a physicist. He learned to program in FORTRAN in the university in the 70's. Decades later I, still a teenager, asked him something like this: "Dad, you were a FORTRAN programmer and physicist in the 70's, you could be a very well paid developer anywhere in the developed world... why didn't you?"; he answered me: "I didn't thought this thing about computers would go too far."

My uncle worked for Folgers coffee in the 60s as a general office clerk. They gave everyone some kind of test designed to see if you had aptitude for programming. He scored high, so they asked him if he wanted to learn COBOL, and his career was born.
Post reply on HN