A physics major is not good preparation for a career in software development

[StatGuy2000]

Can you elaborate more on the portfolio? Pictures of my program or something? Only thing I'd feel bad about is if someone looks at my code and sees bad coding practices or something. Usually when I'm learning, I don't sweat the details.

I was thinking more along the lines of copies of the code itself, or pictures of the end result. You can also bring your laptop with you and show the results of the code. If you're worried about IP or copyright, perhaps you can specify in advance that these are beta versions?

Those involved in software development may give you better advice about how to present a portfolio.

 

[TMFKAN64]

I've worked in software development for over 20 years and have never heard of anyone presenting a portfolio.

Usually, most of the code I've written has been owned by a previous employer... I couldn't have shown it to someone else unless I wanted endless legal hassles. I think that's the usual case... I've interviewed many people as well, and none of them have ever shown me a portfolio either.

 

[jkl71]

I was once asked for a sample of my code for an interview, since I didn't have anything that I could legally show, I declined.

I wouldn't really call it a portfolio, but twice I conducted interviews where the hiring manager asked the candidate to provide code samples. In one case it was an internal transfer so ownership of the code was not an issue, in the other instance I'm not sure if the code was proprietary or not (I didn't really want to know).

The code didn't really influence me that much, I was more interested in how they responded to the questions I asked. The only thing I felt a bit negative about was when I'd ask about why they did something a certain way, that was obviously wrong, and instead of just saying, "I made a mistake", they would try to come up with some justification that didn't make any sense before saying, "I made a mistake".

 

[symbolipoint]

Regarding the original statement as the topic title:
What makes it so? Do you know about the free-software movement? One of the chief promotors is a programmer and with degree in Physics.

What one studies formally along with their "degree" and what one chooses to learn or study outside their degree can make a person more than or different than just the result of their major field of study. Not everyone knows what to do about so many choices nor to look for them.

 

[ParticleGrl]

What makes it so? Do you know about the free-software movement? One of the chief promotors is a programmer and with degree in Physics.

Dude, Richard Stallman got his undergrad degree in physics IN 1974! Do you think maybe the expectations of software developers has changed a bit in the last 40 years? How many CS programs do you think existed in the 70s? The pattern of physics degrees is generally that they don't get work doing physics, but are smart people so they worm their way into areas that require little in the way of formal credentials (CS in the 70s, finance recently, insurance and data-mining).

In a world where there are no degrees teaching you how to develop software, something like physics where you'll get some time on fast computers and learn a bit about programming is excellent preparation. In a world where lots of schools are having CS students work on large, open source projects, physics is no longer good preparation.

Also, Stallman is AT BEST an idiosyncratic definitions of success. I met him briefly in the late 90s, and at the time it appeared he was literally living in his office and didn't appear to have much in the way of income.

 

[chiro]

Regarding the original statement as the topic title:
What makes it so? Do you know about the free-software movement? One of the chief promotors is a programmer and with degree in Physics.

What one studies formally along with their "degree" and what one chooses to learn or study outside their degree can make a person more than or different than just the result of their major field of study. Not everyone knows what to do about so many choices nor to look for them.

Modern software development is something you have to spend a lot of time becoming used to and being comfortable with.

Typically nowadays people are given a bunch of API's that do a lot of complex stuff and they are told: "Here's API blah, blah and blah: we need blah blah and blah".

Now in this environment you won't know anything much beyond those interfaces in terms of what is going in most cases (you know what it does, just not how) and you have to deal with the issues that arise not only from this, but also working with repositories that are huge and are maintained by a number of people that introduce issues of their own.

Working on a repository that is being accessed by half a dozen or more people can be a nightmare if things aren't co-ordinated and if you are used to developing for yourself, then it's pointless for an employer to look at you since they want someone who can not only get things done, but also get things done in the context of a team environment that means working with other coders, managers, and all kinds of people.

Again it's quite different to have this scenario than the one where you are doing your own pet project that you have full control over and relating the two situations in any way is just naive.

 

[jedishrfu]

This is quite an interesting thread that I didn't see earlier. Reading through it brought back memories.

I started out with a BS in Physics and was hired into a computer center that did two types of work: business based (payroll, stock certificates, billing...) and scientific/engineering based work. At the time, CS was a fledging field, the company knew it was better to hire physics majors and business majors to get the job done. The view was that it was easier to teach someone COBOL or FORTRAN than it was to teach them the complexities of a given science, engineering or business project. They did this by offering inhouse training in all aspects of programming of the time ie FORTRAN, COBOL, Report Writer, sorting, and macro assembler.

In particular, I was told that physics majors seemed especially adept at picking up programing projects and running with them. It seemed that we understood how to work with arrays better than business majors. This was before spreadsheets were invented, business majors could handle lists and with difficulty tables but add another index and they might get lost completely. COBOL pretty much dealt with lists of records to be sorted, summarized and reports printed.

In contrast, FORTRAN applications would use more math to compute or generate engineering data like plots, programmable milling machine tapes...

What I used to tell students majoring in any field was to minor in computers because companies that needed programmers to run the business look at the major first and then the programming is an extra that they will also want. I think this still stands today. CS people will get more easily hired by computer companies, engineers by engineering companies, physics majors by research labs... but in each case knowing how to program makes you a better fit for the job.

Curiously, IBM bucked the trend at the time by hiring English majors. Initially they needed manuals to be written but discovered that English majors had the logic skill needed to write effective programs. Many later became managers and executives for the company but that's another story...

Lastly, I'm sure if you were to do a poll of working programmers you would find many older programmers who had physics backgrounds. Two of the US inventors of early computers, Atanasoff and Mauchly were physicistts whereas Eckert and Zuse were engineers and Turing, Aiken and VonNeumann were mathematicians again before CS was a field of study.

 

[StatGuy2000]

Getting back into the point raised by the OP: I would have to agree that a physics major on its own is not a particularly good preparation for a career in software development. In my alma mater, the curriculum for physics majors often do not cover programming or software development in any degree of depth.

That being said, the physics majors that I know of have considerable skill in programming and often pick them up very quickly. And I could be mistaken about this, but I somehow I seem to get the impression that there is an unspoken belief that a physics major and a CS major are mutually exclusive, where in fact there are many people (including people I know personally) who have double-majored in both degrees. These people have often told me that an understanding of physics and of CS have complemented each other.

 

[TMFKAN64]

Also, Stallman is AT BEST an idiosyncratic definition of success. I met him briefly in the late 90s, and at the time it appeared he was literally living in his office and didn't appear to have much in the way of income.

He's his own boss and doing exactly what he wants to be doing, and has been for 30 years. I can't imagine being more of a success than that.

That said, I'd agree that he makes a poor role model for physics majors who aspire to be software developers.

 

[jedishrfu]

Getting back into the point raised by the OP: I would have to agree that a physics major on its own is not a particularly good preparation for a career in software development. In my alma mater, the curriculum for physics majors often do not cover programming or software development in any degree of depth.

That being said, the physics majors that I know of have considerable skill in programming and often pick them up very quickly. And I could be mistaken about this, but I somehow I seem to get the impression that there is an unspoken belief that a physics major and a CS major are mutually exclusive, where in fact there are many people (including people I know personally) who have double-majored in both degrees. These people have often told me that an understanding of physics and of CS have complemented each other.

I can vouch for that, I have a Physics BS and a CompSci MS and its true they do complement one another in odd ways but are especially helpful when doing scientific projects with a fair amount of computational math and physics.

 

[Floid]

Why? Because I developed all of it using Qt Creator by myself and not using .Net framework in an Agile environment or whatever.

Spin. If you know potential employers want .Net framework and Agile development experience working in a team then when you are talking about your project:

1.) Don't specify what development environment/libraries you used.
2.) Don't say you did it alone. Might seem conterintuitive but list what you did and leave it ambiguous as to if you worked alone or not.
3.) Even if you didn't officially use Agile processes, some of what you did probably is Agile like. Read through in figure out what is and point that out in your resume. State that you used the Agile concepts of "xxx", "xxx", and "xxx" or whatever.Then if you don't have it, get some .Net experience (this is the homecooked project part) and list in a general skills section that you have .Net experience.

 

[Floid]

Yes I have. The roadblocks I've run into are:

• What do I program? People say "give yourself a project", but that's vague non-advice. I don't know what project to undertake that would force me to learn new concepts. I learned Python a few weeks ago. Made a small game with pygame. It was super easy and I didn't learn anything besides syntax. I just don't know what else to start.
• Let's say I make a project and improve my knowledge. A good project that takes a solid month of programming. I can then write on my resume "1 month of programming in X". People almost always want years -- at least 1. Do I lie?
• Added to that, if I get probed on what my experience in language X is, I would respond with "Oh I made a project for myself." Would that even fly? There's no real way to check that out.

1.) Depends on what you want to try to learn. Something I fooled around with to learn about neural networks and learn C# was to create a stock analyzer. Write a program that gets historical stock data from the internet and stores it into a SQL database. Then write a program that pulls it out of the SQL database and performs some kind of basic analysis on it. Make it variable so you can examine stock or group of stocks starting at any date, for any window length, or find any stock whose price or volume deviated more than 1 STD in a certain length of time, etc.

This covers a lot of basics: basic socket programming, string parsing, basic database manipulation, math and array operations. Throw a GUI on it and plot if if you want GUI or maybe openGL development experience.

If you want something more mathematical, write a set of libraries using various numerical techniques to solve ODEs or PDEs. Figure out a way to use them and compare their results, processing efficiency, etc. Even better, compare the results with different compiler options or between different compilers/programming languages.

2.) Never state how much experience you have unless it is a big plus. If you know they want a C++ developer and you have 15 years developing in C++ state it. Otherwise, you are just "Proficient in [list all the languages you know to some basic level]"

3.) Spin and hype. Don't lie, but emphasize the strong points and don't mention the weak points unless they specifically ask. You didn't do a weekend programming project, you created a program that performed statistical analysis on a database of historical stock data. And you didn't do it to learn to program, you did because you didn't like the tools available for free on the internet or because you thought you had some novel approach to stock analysis.

 

[D H]

3.) Spin and hype. Don't lie, but emphasize the strong points and don't mention the weak points unless they specifically ask. You didn't do a weekend programming project, you created a program that performed statistical analysis on a database of historical stock data. And you didn't do it to learn to program, you did because you didn't like the tools available for free on the internet or because you thought you had some novel approach to stock analysis.

This is very bad advice. Spinning and hyping a weekend programming project as a significant endeavor is a lie. A reasonably good interviewer will detect it as such. Never lie on a resume or during an interview, and that includes excessive stretching of the truth. If you are going to lie about something as petty as a weekend programming project, what are you going to lie about when it comes to something significant?

If the company is at all competent, it will not hire you just on the basis of this kind of "spin and hype". If it makes a mistake and does hire you, they might well fire you when it turns out that you did "spin and hype" in your resume and interview. Your first six months or so on the job are provisionary. We don't need much of an excuse to get rid of you. Most degreed technical employees are exempt employees. "Exempt" means that a whole lot of protections that apply to hourly workers are not applicable to exempt employees. Even after that probationary period, we still don't need much of an excuse to get rid of you. Firing an employee oftentimes is very bad for morale, both fellow employees and employers. Most employers do not like to fire people.

On the other hand not firing a worthless employee can also bad for company morale, mostly on the part of fellow employees. Those coworkers do not like having to repeatedly clean up the mess that that worthless employee creates. Worthless employees are also bad for the bottom line. If they create a big enough mess, they are not just worthless. They are worse than worthless.

 

[Locrian]

Floid was clear not to lie. Choosing language that's both appropriate and puts the work in a positive light is possible. Learning to sell yourself in an interview is an important skill that candidates should work on.

I think D H misrepresented Floid in his response above.

 

[D H]

Floid was clear not to lie.

I disagree. Floid's stretching a weekend programming project into something that it wasn't is a lie. It's just not a fabricated out of nothing kind of lie. There are lots of ways of lying. Just look to the kings and queens of lying, lawyers and politicians. A favored approach is to sprinkle the lie with a bit of truth, then stretch that truth beyond all recognition. They might not have fabricated something out of nothing, but it's still a lie.

I occasionally interview potential employees. Shortly afterwards, management and everyone who was involved get together to discuss the candidate. This meeting includes the people who interviewed the candidate, those who gave demos to the candidate, even those who went out to lunch with the candidate. This post-interview meeting is very typical across many companies, and we do look for potential problems. Lying is a big problem. Suppose even one person detected that that claimed experience in programming and statistics was a merely weekend project to learn how to program and how to do statistics. That's a "Whoa" kind of problem, one that makes everyone involved rethink what they learned of the candidate.You might not look on this excessive stretching of the truth as a lie, but the potential employer does see it as a lie. Don't embellish.

 

[Locrian]

Floid's stretching a weekend programming project into something that it wasn't is a lie.

He never suggested any such thing. You're misrepresenting what he said.

 

[Locrian]

Don't lie, but emphasize the strong points and don't mention the weak points unless they specifically ask.

My emphasis. That's pretty clear.

 

[D H]

My emphasis. That's pretty clear.

Here's how I read what Floid said, this time with my emphasis, comments in parentheses mine:

3.) Spin and hype. Don't lie, but emphasize the strong points and don't mention the weak points unless they specifically ask. You didn't do a weekend programming project, you created a program that performed statistical analysis on a database of historical stock data. And you didn't do it to learn to program, you did because you didn't like the tools available for free on the internet or because you thought you had some novel approach to stock analysis.

In other words, Don't lie (wink, wink) but do stretch the truth beyond the breaking point. That's a lie. You might not see it as such, but a potential employer will. And they will not hire you. 93% of managers do not hire a candidate if they think the candidate lied. http://www.careerbuilder.com/share/...ail.aspx?id=pr330&sd=10/17/2006&ed=12/31/2006.

Everyone embellishes to some extent. This is beyond embellishment. It is a lie. You might not look upon this kind of "spinning and hyping" as being a lie, but potential employers will see it as one. The odds are very much against the company hiring you if the interviewer does see it as a lie. I see the example at hand as a lie, and I have interpreted this kind of ultra-embellishment as a lie with candidates I have interviewed. And we did not hire those candidates.

 

[Floid]

I think the problem is with my use of the term "weekend project" which I was using more as a figure of speech indicating a project you did on your own and not for profit than to denote the actual time investment you had in the project.

If you look at two ideas I gave for sample projects both would actually take weeks of work to produce:

Examples:

Write a program that gets historical stock data from the internet and stores it into a SQL database. Then write a program that pulls it out of the SQL database and performs some kind of basic analysis on it. Make it variable so you can examine stock or group of stocks starting at any date, for any window length, or find any stock whose price or volume deviated more than 1 STD in a certain length of time, etc. ... Throw a GUI on it and plot if if you want GUI or maybe openGL development experience.

or

If you want something more mathematical, write a set of libraries using various numerical techniques to solve ODEs or PDEs. Figure out a way to use them and compare their results, processing efficiency, etc. Even better, compare the results with different compiler options or between different compilers/programming languages.

If someone did a reasonably good job at them then I would say they have at least an entry level understanding of programming and whatever tools they used to do them in. If you think someone who completed those projects is lying if they said they had a entry level understanding of the programming language/tools they used then we have a very different expectation level on what an entry level understanding is...

 

[D H]

If you want something more mathematical, write a set of libraries using various numerical techniques to solve ODEs or PDEs. Figure out a way to use them and compare their results, processing efficiency, etc. Even better, compare the results with different compiler options or between different compilers/programming languages.

The one page resume rule still applies to people fresh out of college, which is the subject of this thread. When you use that much space to describe something you've done, I'm going to poke at it when I interview you. I might even do something unexpected if you really pique my interest (and you have piqued my interest with that little blurb).

What I might do is ask some of the really nasty physics/math/programming questions that I typically reserve for the best candidates. I don't ask those nasty questions because I'm trying to trip you up. Everyone stumbles a bit on these. I want to see how you frame the problem, how you stumble, how you recover, what kinds of questions you ask back at me. If you can't even start framing the problem, now that's a real problem. It means that I completely misgauged you. It might well mean that you have crossed that fatal line that distinguishes embellishment from lying. Now I'm really going to poke at your little writeup.

Every interviewer has a personal concept of truth / embellishment / lie. Even crossing from truth to embellishment is a problem for some interviewers. Crossing from embellishment to lie is a huge problem for all. That you don't think you lied is irrelevant. All that counts is whether the interviewer thinks you did. If your interviewer thinks you lied, you're toast. You will not get the job. Something to keep in mind when you are writing that resume.

 

[TMFKAN64]

In some sense, it doesn't really matter how much spin and hype you apply. As soon as you say "I wrote a program that..." you've identified it as a weekend programming project. Commercial software really isn't written by anyone person any more.

I think you'd be much better off getting involved with any open source programming project. At least I know I'd be much more impressed by an applicant who had submitted code and/or bug fixes to such a project than one who only wrote a few programs on their own. Plus, this solves the problem of code samples, as you can point to the specific submissions you made.

 

[Mistake]

Open source projects are pretty intimidating for me. People who have been coding for years contribute to the project and I'm supposed to do something on their level? I'm just afraid my code won't be up to their standards. Yeah, I know that's all in my mind.

But in any case, where do I find some projects that would be easy to contribute to? Projects can be huge. I'd hate to spend a few weeks learning how the code works just to give up because it's too complicated for me to understand.

 

[TMFKAN64]

Yes, open source projects are big and intimidating and staffed by people who have far more experience than you do. That's exactly why being able to contribute to one would be such good experience!

I don't have any specific recommendations for projects. But generally speaking, I'd suggest to try to find a smaller project that interests you and has a publicly accessible bug database. Look over the open bugs, and try to pick one that you can reproduce at home. Once you've managed to reproduce it, debug it and produce a fix!

When dealing with a large amount of strange code, keep in mind that you don't have to understand *all* of it in order to make a contribution. Don't let the size of it intimidate you.

If you think this is beyond your ability, I'd simply ask you what do you think software development is, anyway?

 

[AlephZero]

But in any case, where do I find some projects that would be easy to contribute to? Projects can be huge. I'd hate to spend a few weeks learning how the code works just to give up because it's too complicated for me to understand.

The projects you can contribute most to are probably the ones that you already use. That way, at least you know what the app is supposed to do, and you probably already have some ideas about how to improve it.

You don't have to jump in at the deep end. On almost any software project, you could start by rewriting the some of the documentation so it makes more sense (or even any sense at all!). To do that, you will have to start reading the code to find out which parts of the documentation are just "spin and hype"...

Making "simple" contributions to open source projects is still useful, because it means the "project gurus" can spend less time doing the simple stuff, and more time being gurus. And once they notice you are contributing SOMETHING regularly, your questions about harder stuff will tend to get more of their attention.

 

[TMFKAN64]

The projects you can contribute most to are probably the ones that you already use. That way, at least you know what the app is supposed to do, and you probably already have some ideas about how to improve it.

You don't have to jump in at the deep end. On almost any software project, you could start by rewriting the some of the documentation so it makes more sense (or even any sense at all!). To do that, you will have to start reading the code to find out which parts of the documentation are just "spin and hype"...

Making "simple" contributions to open source projects is still useful, because it means the "project gurus" can spend less time doing the simple stuff, and more time being gurus. And once they notice you are contributing SOMETHING regularly, your questions about harder stuff will tend to get more of their attention.

This is a much better answer than mine. Documentation is something that *always* needs work and no one really wants to do!

 

[Mistake]

Sounds doable I guess. Only problem is this is something that can take months to do and I'd like a job now. Which is why I don't think software engineering is the right path. This is a pipedream. Hope I find a project I can contribute to, spend X amount of time on it hoping I actually make a worthwhile contribution, then hope potential employers actually care about it enough to interview me.

 

[StatGuy2000]

The one page resume rule still applies to people fresh out of college, which is the subject of this thread. When you use that much space to describe something you've done, I'm going to poke at it when I interview you. I might even do something unexpected if you really pique my interest (and you have piqued my interest with that little blurb).

What I might do is ask some of the really nasty physics/math/programming questions that I typically reserve for the best candidates. I don't ask those nasty questions because I'm trying to trip you up. Everyone stumbles a bit on these. I want to see how you frame the problem, how you stumble, how you recover, what kinds of questions you ask back at me. If you can't even start framing the problem, now that's a real problem. It means that I completely misgauged you. It might well mean that you have crossed that fatal line that distinguishes embellishment from lying. Now I'm really going to poke at your little writeup.

Every interviewer has a personal concept of truth / embellishment / lie. Even crossing from truth to embellishment is a problem for some interviewers. Crossing from embellishment to lie is a huge problem for all. That you don't think you lied is irrelevant. All that counts is whether the interviewer thinks you did. If your interviewer thinks you lied, you're toast. You will not get the job. Something to keep in mind when you are writing that resume.

Let me ask you something then. Suppose I am a proficient programmer with experience in say, MATLAB and C, but do not know how to program in SQL, for example. Now let's suppose that I want to learn to program in SQL because knowing how to do so will open up job opportunities. So I take the opportunity to go through the material online, write up programs, go through all the manuals and books, and I develop some code to do various things. Say, within a few months, I feel like I have a grasp on the basics of SQL.

According to you, should I include "proficient in SQL" in my resume? If not, what should I say about my knowledge in this language?

 

[coalquay404]

Let me ask you something then. Suppose I am a proficient programmer with experience in say, MATLAB and C, but do not know how to program in SQL, for example. Now let's suppose that I want to learn to program in SQL because knowing how to do so will open up job opportunities. So I take the opportunity to go through the material online, write up programs, go through all the manuals and books, and I develop some code to do various things. Say, within a few months, I feel like I have a grasp on the basics of SQL.

According to you, should I include "proficient in SQL" in my resume? If not, what should I say about my knowledge in this language?

D H will have his own take on this but I learned all the SQL I ever needed in the course of a day. That included a run through on relational algebras, projections, and the query language itself.

Unless you're actually designing databases you really don't need to know an awful lot of SQL to be productive.

 

[D H]

According to you, should I include "proficient in SQL" in my resume? If not, what should I say about my knowledge in this language?

I've learned SQL. Nonetheless, that knowledge never, ever, ever, ever goes on my resume. Sometimes a little knowledge is dangerous -- to your career, that is. Claiming knowledge of databases in the world of scientific programming is one of those "dangerous to your career" kinds of knowledge. I've seen what happens, multiple times, to people who claim to be "proficient in SQL". They no longer get to do anything related to scientific programming. Ever. Anything that is technically interesting: They aren't allowed to do that. That database knowledge is too important to waste.

 

[StatGuy2000]

I've learned SQL. Nonetheless, that knowledge never, ever, ever, ever goes on my resume. Sometimes a little knowledge is dangerous -- to your career, that is. Claiming knowledge of databases in the world of scientific programming is one of those "dangerous to your career" kinds of knowledge. I've seen what happens, multiple times, to people who claim to be "proficient in SQL". They no longer get to do anything related to scientific programming. Ever. Anything that is technically interesting: They aren't allowed to do that. That database knowledge is too important to waste.

You misunderstood the nature of my question. I was only using SQL as an example; I could have picked Java, C#, Python, Simula or any other programming language.

The point of my question was if I had studied programming language X on my own (but without any courses in school, certification or practical work experience), should I include my proficiency in the language in my resume or CV (you had argued previously that putting "proficiency in programming language X by developing Y project" would be lying if this amounted to self-study and self-developed project). If so, what should I state in my resume.

 

[twofish-quant]

This is very bad advice. Spinning and hyping a weekend programming project as a significant endeavor is a lie.

One thing that I've found with some interviewees is that *understating* your expertise can be just as bad as overstating it.

Sometimes a weekend project is a significant endeavor. What's really impressive is if someone other that you uses the project, or if the weekend project is part of an general open source routine. If you do some weekend projects writing device drivers for linux that make it into the kernel, that's worth talking about since that means that Linus Torvalds has signed off on your code.

Also, if it's something that people can download from sourceforge, that's also useful. If someone tells me that they are an expert programmer, I have to take their word for it. If I can download their code from sourceforge, I can see for myself.

Never lie on a resume or during an interview, and that includes excessive stretching of the truth. If you are going to lie about something as petty as a weekend programming project, what are you going to lie about when it comes to something significant?

On the other hand, we've hired several people on the basis of weekend projects (including me). The thing about those projects is that the code was available online, and if you want to see my skill as a C++ programmer, I can point you to several websites where you can see for yourself.

 

[twofish-quant]

Suppose even one person detected that that claimed experience in programming and statistics was a merely weekend project to learn how to program and how to do statistics.

On the other had if said candidate was the author of several very complicated bits of mathematics in an open source package, that's impressive. If the author has no formal training in statistics, that's even more impressive.

One thing that makes the type of programming we do amenable to "weekend projects" is that often the type of programming that we do involves one or two day bug fixes to a larger system. If you've debugged and tracked down bugs in the linux kernel, that's the skill set we want.

The other thing is that if you've participated in any large open source project, that means that you can work with other people, which is also a useful skill.

 

[twofish-quant]

Everyone embellishes to some extent. This is beyond embellishment. It is a lie. You might not look upon this kind of "spinning and hyping" as being a lie, but potential employers will see it as one.

Whether it's a lie or not depends the underlying reality of the situation. If you go to a Wall Street interview, and you talk about your stock analysis program, then you are putting a big sign on yourself saying "crush me with questions on stock analysis." At that point you are going to be grilled with questions about sharpe ratios, VaR, transaction costs, no-arbitrage theorems, GARCH models etc. etc. Can you write five lines of code that tests for zero-root processes? Let's talk about market microstructure, can you tell me off the top of your head the margin rules for the NYSE? Tell me how the order book works.

The cool thing is that if you've done your homework, then you may seriously impress the interviewer. Wall Street loves people that are self-taught. If you write a stock analysis program and you can talk about the Markowitz model, then this is great!

As far as spin and hype. Do you best to spin and hype me. We'll see if you are good at it. Spin and hype aren't necessarily bad things. If you don't mention that you've done stock analysis in your resume, then I won't be able to grill you about GARCH models. If you spill and hype me and you have no idea who Markowitz is, then you've just wasted my time and yours.

One thing about spin is that it's a skill. If you know *nothing* about stock markets, but you can convince an expert that you do. If you manage to convince me that you are a C++ expert but you know nothing, then I'll very strongly recommend that you be hired, on the basis of your acting skills.

However, even at "spin and hype" you probably aren't that good, because if you are trying to get a job on Wall Street on the basis of your ability to BS, then we'll bring in our world class BS'er to grill you to see how good you are at that.

 

[D H]

Whether it's a lie or not depends the underlying reality of the situation. If you go to a Wall Street interview, and you talk about your stock analysis program, then you are putting a big sign on yourself saying "crush me with questions on stock analysis."

Exactly. When you boast about something in a resume, be prepared to be grilled about it. If it turns out to be all spin and hype, but nothing's there, no job.

You work in a very small niche of the programming world, twofish, a world that lives and breathes spin and hype. You guys might even relish spin and hype on a resume. Don't take your narrow view of how your small corner of the world works as exemplary of how things work outside of Wall Street. Excessive spin and hype on a resume are not appreciated elsewhere. Almost everyone embellishes their resumes to some extent. There's a line where embellishment becomes a lie, and that line is one that in general should not be crossed. Outside of Wall Street, that is.

 

[twofish-quant]

You guys might even relish spin and hype on a resume. Don't take your narrow view of how your small corner of the world works as exemplary of how things work outside of Wall Street.

Sure, but then this gets to the issue of communications. Different words have different meanings in different places. Where I work "spin" and "hype" are considered *good* things. If you are dishonest, then the spin doesn't work, so that's considered bad spin.

Also this isn't just Wall Street, pretty much every job that involves sales and marketing has this things.

Honesty and integrity are extremely important in finance. The best spill and hype is that which is backed up by facts.

Excessive spin and hype on a resume are not appreciated elsewhere. Almost everyone embellishes their resumes to some extent. There's a line where embellishment becomes a lie, and that line is one that in general should not be crossed. Outside of Wall Street, that is.

In fact, it's a *bad* idea to embellish your resume. Even a little. People forget the purpose of the resume is not to get the job, but to get an interview. If you embellish the resume, and you get an interview for a job that you won't get in the end, this is a *BAD* thing because you are wasting time interviewing for jobs that you won't get.

It's also *bad* to embellish your resume since that focuses the interview on things that you are bad at. For example, if I were to write a resume, I'd like to mention a lot about neutrino diffusion and not on stock analysis. The reason for this is that if they bring out the world expert on radiation hydrodynamics and we talk for an hour on Boltzmann methods, I'll shine. If I mention stock analysis, then they will bring out the world's expert on stock analysis, and I'll get killed. The questions that I was talking about were kindergarten ones.

Finally, one of the biggest problems for physics Ph.D.'s is overqualifications. There are many times in which you want to deliberately *understate* your qualifications, because stating them in full gets you killed.