Let's touch base again offline about that next deliverable...
February 28, 2011 7:08 AM Subscribe
I'm a computer science and biochem major about to start a software development internship at a high-frequency trading firm. What are the classic mistakes you see inexperienced geeks make in a professional environment, especially a financial-sector/"business" place, and how can I avoid them? What can I do this summer to impress my supervisors and maybe get my foot in the door for a full-time job after graduation?
Note that I'm not asking for a crash course on finance. This company employs something like half the world's OCaml programmers, financially experienced or not, so I expect my ignorance there will be a familiar and tolerable experience for them.
Note that I'm not asking for a crash course on finance. This company employs something like half the world's OCaml programmers, financially experienced or not, so I expect my ignorance there will be a familiar and tolerable experience for them.
Not specific to financial sector jobs...The biggest mistake I see geeks/devs make when coming into a new workplace is to immediately slag the company's software/dev environment/code/whatever in favor of the way he would do things. I've seen this behavior over and over, even from the lowest-level hires.
posted by Thorzdad at 7:37 AM on February 28, 2011 [6 favorites]
posted by Thorzdad at 7:37 AM on February 28, 2011 [6 favorites]
Dress appropriately.
posted by sonic meat machine at 7:38 AM on February 28, 2011 [2 favorites]
posted by sonic meat machine at 7:38 AM on February 28, 2011 [2 favorites]
WRT to finance sector interns - I've seen lots of them sort of think they know a lot more then they do. Remember you don't know anything with respect to what the firm actually does day to day, and that you aren't expected to. Ask questions (once only though) and work hard. But make sure you know what they expect you to know.
If there is a social aspect to the office, participate but don't do anything that'll make you stand out in a bad way. (i.e. getting very drunk, or being a woman chaser).
Dress appropriately - and this doesn't just mean not dressing too casually, it also means not dressing too nicely/showy.
Show up on time. Short of a death in the family don't take a workday off - although at a smaller firm you might figure out pretty quickly what the path is on that.
And finally don't suggest that HFT is rapidly commoditizing and they should sell their business.
posted by JPD at 7:45 AM on February 28, 2011 [1 favorite]
If there is a social aspect to the office, participate but don't do anything that'll make you stand out in a bad way. (i.e. getting very drunk, or being a woman chaser).
Dress appropriately - and this doesn't just mean not dressing too casually, it also means not dressing too nicely/showy.
Show up on time. Short of a death in the family don't take a workday off - although at a smaller firm you might figure out pretty quickly what the path is on that.
And finally don't suggest that HFT is rapidly commoditizing and they should sell their business.
posted by JPD at 7:45 AM on February 28, 2011 [1 favorite]
The biggest mistake I see geeks/devs make when coming into a new workplace is to immediately slag the company's software/dev environment/code/whatever in favor of the way he would do things. I've seen this behavior over and over, even from the lowest-level hires.
YES. There are very few things you can do as a "new guy" that will irritate and alienate you more quickly than disparaging the existing code base. The devs already know where the crap code is, they don't need you to remind them. Furthermore, suggesting huge, systemic changes ("Let's use Git instead of Subversion!") only serves to make you look like a gigantic fucking idiot that doesn't understand how businesses operate in the real world.
Advice specific to the financial sector: always have a backup plan. You never want to be standing there when the shit hits the fan with no idea what to do and a pained, "Duh" expression on your face.
Oh, and Log like a friggin' lumberjack.
posted by Civil_Disobedient at 8:20 AM on February 28, 2011
YES. There are very few things you can do as a "new guy" that will irritate and alienate you more quickly than disparaging the existing code base. The devs already know where the crap code is, they don't need you to remind them. Furthermore, suggesting huge, systemic changes ("Let's use Git instead of Subversion!") only serves to make you look like a gigantic fucking idiot that doesn't understand how businesses operate in the real world.
Advice specific to the financial sector: always have a backup plan. You never want to be standing there when the shit hits the fan with no idea what to do and a pained, "Duh" expression on your face.
Oh, and Log like a friggin' lumberjack.
posted by Civil_Disobedient at 8:20 AM on February 28, 2011
Thinking that proper logic and the sheer luminance of your ideas will win over your superiors. Thinking that you are spotting inefficiencies and wanting to establish yourself by "shaking up how things are done."
You may or may not be totally right, but regardless of that fact, there are layers upon crusty layers of long-established political and power dynamics that result in the current status quo. You won't be able to move that status quo an inch until you understand the dynamics that have originated it, and that understanding, and then the ability to act on it, take years to develop. These dynamics are rarely technical in nature, so your technical abilities won't help you.
I hate offices....
posted by tempythethird at 8:27 AM on February 28, 2011 [1 favorite]
You may or may not be totally right, but regardless of that fact, there are layers upon crusty layers of long-established political and power dynamics that result in the current status quo. You won't be able to move that status quo an inch until you understand the dynamics that have originated it, and that understanding, and then the ability to act on it, take years to develop. These dynamics are rarely technical in nature, so your technical abilities won't help you.
I hate offices....
posted by tempythethird at 8:27 AM on February 28, 2011 [1 favorite]
What are the classic mistakes you see inexperienced geeks make in a professional environment, especially a financial-sector/"business" place, and how can I avoid them?
Don't complain about your job online.
Note that I'm not asking for a crash course on finance. This company employs something like half the world's OCaml programmers...
...Especially after all-but identifying it to anyone that knows HFT.
posted by atrazine at 8:36 AM on February 28, 2011 [1 favorite]
Don't complain about your job online.
Note that I'm not asking for a crash course on finance. This company employs something like half the world's OCaml programmers...
...Especially after all-but identifying it to anyone that knows HFT.
posted by atrazine at 8:36 AM on February 28, 2011 [1 favorite]
Lots of good advice upthread.
Keep in mind that your work will hand you a book of official rules that you will be expected to follow, but there will be another set of expectations determined by the bosses/workplace culture that are just as important. I'd always err on the side of caution when it comes to judgment calls on rules/etiquette, especially in your first year. The "new guy" is under a lot more scrutiny.
I'd like to add to the piece about slagging the boss, or the companies projects... Don't expect "private communications' to remain private. Face-to-face, email, telephone, and chats over drinks can all feed a gossip mill.
Aside from slagging code, I'd also be wary of slagging any vendor or service provider too - quite often those guys will be big clients or other important stakeholders in ways you don't realize.
Actually don't slag at all. Offer constructive feedback or observations, and ask questions.
posted by Deep Dish at 8:46 AM on February 28, 2011
Keep in mind that your work will hand you a book of official rules that you will be expected to follow, but there will be another set of expectations determined by the bosses/workplace culture that are just as important. I'd always err on the side of caution when it comes to judgment calls on rules/etiquette, especially in your first year. The "new guy" is under a lot more scrutiny.
I'd like to add to the piece about slagging the boss, or the companies projects... Don't expect "private communications' to remain private. Face-to-face, email, telephone, and chats over drinks can all feed a gossip mill.
Aside from slagging code, I'd also be wary of slagging any vendor or service provider too - quite often those guys will be big clients or other important stakeholders in ways you don't realize.
Actually don't slag at all. Offer constructive feedback or observations, and ask questions.
posted by Deep Dish at 8:46 AM on February 28, 2011
Dress appropriately. Do not give in to the office banter and rumors . Try to be friendly with your boss without being Friends with him. The nicer you are to your boss the nicer he will be to you .
Also this works wonders. Always get to work early. Dont start early but get there early. Eat breakfast or take a walk . This helps wondersd and will cut down on your stress. It helps me a lot . MY boss always asks me why i am here so early but he really appreciates it when something goes wrong and he can ask me to clock in early (i do get paid when i clock in unlike a lot of salaried jobs).
posted by majortom1981 at 8:49 AM on February 28, 2011
Also this works wonders. Always get to work early. Dont start early but get there early. Eat breakfast or take a walk . This helps wondersd and will cut down on your stress. It helps me a lot . MY boss always asks me why i am here so early but he really appreciates it when something goes wrong and he can ask me to clock in early (i do get paid when i clock in unlike a lot of salaried jobs).
posted by majortom1981 at 8:49 AM on February 28, 2011
I second the point that you shouldn't be focusing on correcting other people's code, especially if that code has already been proven to work. Not only will you be wasting time rewriting code, but you will have to spend time bug-testing your changes, plus you will have to explain the changes to your co-workers since they are unfamiliar with your changes. Also, you will not appear as a team player if you go around trying to fix every else's stuff just because it's not to your standards.
However, if you really have some strong suggestions or a beef with someone else's code, take it up with the original developer, or even your boss. Your boss or team lead will probably also be opinionated on the subject since they might want you to spend your time on more critical task items.
Also, don't spend too much time fine-tuning your software. If the software does what the customer wants, don't waste your time (and your company's money) trying to make it better. There is no such thing as perfect code or a perfect program, so a good skill is to know when to stop programming. One team at my company just got a bunch of flack from the division head for missing their project due date by a whole month because they spent too much time fine-tuning their project to make it multi-purpose when they didn't need that capability.
Lastly, it's a good idea to become very good at estimating the time it takes to complete a programming feature. So, if the customer asks for a time estimate or a completion date, you will need to be as truthful and as accurate as possible, otherwise you will get some very disappointed people in the end. Remember, when estimating your development time, you need to account for the time it takes to code the feature, bug test the feature, and verify the feature using real data. This may not be as straight-forward as it sounds because your time at work isn't going to be spent on only programming. You will also need to account for time spent at meetings, training, overhead, unforeseen events, and any other other miscellaneous, non-programming tasks. If you're in the middle of development and you hit a huge snag that's going to delay your development and possibly affect the due date, let the customer know ASAP. It's better if they know right away rather than on last day of development.
posted by nikkorizz at 9:08 AM on February 28, 2011
However, if you really have some strong suggestions or a beef with someone else's code, take it up with the original developer, or even your boss. Your boss or team lead will probably also be opinionated on the subject since they might want you to spend your time on more critical task items.
Also, don't spend too much time fine-tuning your software. If the software does what the customer wants, don't waste your time (and your company's money) trying to make it better. There is no such thing as perfect code or a perfect program, so a good skill is to know when to stop programming. One team at my company just got a bunch of flack from the division head for missing their project due date by a whole month because they spent too much time fine-tuning their project to make it multi-purpose when they didn't need that capability.
Lastly, it's a good idea to become very good at estimating the time it takes to complete a programming feature. So, if the customer asks for a time estimate or a completion date, you will need to be as truthful and as accurate as possible, otherwise you will get some very disappointed people in the end. Remember, when estimating your development time, you need to account for the time it takes to code the feature, bug test the feature, and verify the feature using real data. This may not be as straight-forward as it sounds because your time at work isn't going to be spent on only programming. You will also need to account for time spent at meetings, training, overhead, unforeseen events, and any other other miscellaneous, non-programming tasks. If you're in the middle of development and you hit a huge snag that's going to delay your development and possibly affect the due date, let the customer know ASAP. It's better if they know right away rather than on last day of development.
posted by nikkorizz at 9:08 AM on February 28, 2011
Remember that first and foremost you are there to learn. You are there to learn about their business, their sector, their style, their management. You are not there to make things better and you are not there to make friends (though if you do along the way, good for you) so the most important rule is keep your mouth shut and do your work. Do not try to solve problems that no one has asked you to solve and do not participate in gossip or rumors.
The highest praise that our managers had for programming interns was, "he just gets the work done." As the HR person looking over the reviews that meant hire him.
posted by magnetsphere at 9:28 AM on February 28, 2011
The highest praise that our managers had for programming interns was, "he just gets the work done." As the HR person looking over the reviews that meant hire him.
posted by magnetsphere at 9:28 AM on February 28, 2011
Be friendly. Have your eyes open and be open to opportunities. If coworkers want to grab lunch and invite you along, go. If they are more the introvert types, don't push them into hanging out if that's not their style. Assess personalities. Don't take things personally. If you make a mistake, don't sweat it as you are an intern and they realize that things happen. Work hard, but be humble (nthing to not suggest how to do things "better"). This is your opportunity to realize how different a real world job setting and environment is compared to the academic life. Be a sponge and just relax and learn.
posted by xtine at 11:59 AM on February 28, 2011
posted by xtine at 11:59 AM on February 28, 2011
Response by poster: So it sounds like the main ideas are
0. don't repeat any one question, but feel free to ask questions, especially about my supervisor's expectations regarding reporting, when to bring questions to him, etc.
1. learn and adopt local practices/codebase/etc. without offering my own opinion
2. don't gossip, offer unsolicited criticism, speak poorly of anyone, or discuss previous experience
3. show up on time or earlier in "appropriate" clothes
4. do the work assigned, do it well, and do nothing more (do not exceed spec, do not rewrite provided code, etc.)
5. feel free to ask questions, but don't repeat the same question
6. learn to give time estimates
Two questions:
How would I go about asking this sort of question of employees at the company? For example, if I asked a more senior developer to pick his brains over lunch, would that be seen as inconvenient or brown-nosing, etc?
Civil_Disobedient: "always have a backup plan. You never want to be standing there when the shit hits the fan with no idea what to do and a pained, "Duh" expression on your face."
Could you give an example of what that looks like for a very low-level worker? I expect, considering my domain ignorance, that I'll mostly be asked to implement other people's specifications.
posted by d. z. wang at 12:01 PM on February 28, 2011
0. don't repeat any one question, but feel free to ask questions, especially about my supervisor's expectations regarding reporting, when to bring questions to him, etc.
1. learn and adopt local practices/codebase/etc. without offering my own opinion
2. don't gossip, offer unsolicited criticism, speak poorly of anyone, or discuss previous experience
3. show up on time or earlier in "appropriate" clothes
4. do the work assigned, do it well, and do nothing more (do not exceed spec, do not rewrite provided code, etc.)
5. feel free to ask questions, but don't repeat the same question
6. learn to give time estimates
Two questions:
How would I go about asking this sort of question of employees at the company? For example, if I asked a more senior developer to pick his brains over lunch, would that be seen as inconvenient or brown-nosing, etc?
Civil_Disobedient: "always have a backup plan. You never want to be standing there when the shit hits the fan with no idea what to do and a pained, "Duh" expression on your face."
Could you give an example of what that looks like for a very low-level worker? I expect, considering my domain ignorance, that I'll mostly be asked to implement other people's specifications.
posted by d. z. wang at 12:01 PM on February 28, 2011
Your 6 behaviors are all different facets of the #1 rules for tech folks: relationships are more important than how smart you are. In fact, relationships are more important than everything, but results run a close second.
The most important thing you can do is learn the name of your boss's partners, kids, dogs, and goldfish, and the same goes for your coworkers. Ask about those people. Talk about things other than work. Treat people like people. Then start working on technically kicking ass. You're an intern. It's more important that you be remembered as the person that fit in rather than the arrogant jackass that got all the technical stuff right but was a bear to work with.
If you want to pick someone's brains at lunch, buy lunch. Talk about the person's spouse before yammering about work. Accept "no" as an answer. Motivated interns are a good thing.
posted by bfranklin at 12:46 PM on February 28, 2011
The most important thing you can do is learn the name of your boss's partners, kids, dogs, and goldfish, and the same goes for your coworkers. Ask about those people. Talk about things other than work. Treat people like people. Then start working on technically kicking ass. You're an intern. It's more important that you be remembered as the person that fit in rather than the arrogant jackass that got all the technical stuff right but was a bear to work with.
If you want to pick someone's brains at lunch, buy lunch. Talk about the person's spouse before yammering about work. Accept "no" as an answer. Motivated interns are a good thing.
posted by bfranklin at 12:46 PM on February 28, 2011
I'd say a very common "mistake" is to not say "I dont know". Its much better to understand completely what is going on rather then pretend and waste time doing the wrong thing.
posted by H. Roark at 1:02 PM on February 28, 2011
posted by H. Roark at 1:02 PM on February 28, 2011
Don't complain about your job online...Especially after all-but identifying it to anyone that knows HFT.
Heck, anyone who has any contact with the academic functional programming community at all probably knows someone that's gone to work for this bunch. I certainly do.
posted by pharm at 1:55 PM on February 28, 2011
Heck, anyone who has any contact with the academic functional programming community at all probably knows someone that's gone to work for this bunch. I certainly do.
posted by pharm at 1:55 PM on February 28, 2011
In my interactions as a 'business user' with developers at the bank where I work, here are my biggest gripes:
If you weren't able to deliver a result and it technically isn't your fault, then don't go into the boring technical specifics of X, Y, and Z to explain why it wasn't your fault - unless an important decision about the X, Y, and Z needs to be made by the business. Just tell them when you'll be able to deliver what they asked for.
Don't take personal offense or argue when users point out shortcomings or mistakes in your work - just tell them when you can correct it. Don't be pedantic and claim that the users weren't specific enough in their requirements (even if they really weren't) - again, just tell them how long it will take to make the change.
posted by pravit at 3:55 PM on February 28, 2011
If you weren't able to deliver a result and it technically isn't your fault, then don't go into the boring technical specifics of X, Y, and Z to explain why it wasn't your fault - unless an important decision about the X, Y, and Z needs to be made by the business. Just tell them when you'll be able to deliver what they asked for.
Don't take personal offense or argue when users point out shortcomings or mistakes in your work - just tell them when you can correct it. Don't be pedantic and claim that the users weren't specific enough in their requirements (even if they really weren't) - again, just tell them how long it will take to make the change.
posted by pravit at 3:55 PM on February 28, 2011
You're just an intern. Don't stress too much about this. I can't speak for the place you're going, but for most interns I've seen the requirements for success have been simply an ability to execute on the assigned work, and a personality that doesn't drive everyone else crazy. Don't wait too long to ask questions if you're not sure how to do something, but do try to solve problems on your own first.
And don't get too hung up about asking the same question. You need to learn how to ask a question until you understand the answer. Full-time employees are not necessarily masters of communication, and frequently I find myself repeating questions in different ways to get a real answer out of people. I recommend practicing repeating the answer you heard back to them in your own words so you're sure you understand. It's worse to ask a question, pretend like you understand the answer, waste a few days of work and then come back with something that doesn't do the work requested than to just spend the time to make sure you really understand.
posted by ch1x0r at 11:15 AM on March 1, 2011
And don't get too hung up about asking the same question. You need to learn how to ask a question until you understand the answer. Full-time employees are not necessarily masters of communication, and frequently I find myself repeating questions in different ways to get a real answer out of people. I recommend practicing repeating the answer you heard back to them in your own words so you're sure you understand. It's worse to ask a question, pretend like you understand the answer, waste a few days of work and then come back with something that doesn't do the work requested than to just spend the time to make sure you really understand.
posted by ch1x0r at 11:15 AM on March 1, 2011
I'd say a very common "mistake" is to not say "I dont know". Its much better to understand completely what is going on rather then pretend and waste time doing the wrong thing.
"I don't know" is way better than BSing and wasting everyone's time, but even better is to say "I don't know" and then immediately make your best inference, or at least a guess.
posted by rxrfrx at 2:29 PM on March 1, 2011
"I don't know" is way better than BSing and wasting everyone's time, but even better is to say "I don't know" and then immediately make your best inference, or at least a guess.
posted by rxrfrx at 2:29 PM on March 1, 2011
Could you give an example of what that looks like
One example of having a backup plan is the literal one: keep backups. So… you deleted something? No problem, you don't have to reinvent the wheel. I write software for a living, we use something called source control which is another way of saying fancy backup. But if the computer that's on shits the bed? No problem, because all the data on that system is being backed up daily to a storage area network. But… one of the hard drives in your storage network just died! No problem, because all those drives are in a RAID configuration so you just have to swap in a new hard drive and you're done. Etc., etc., etc.
posted by Civil_Disobedient at 6:32 PM on March 1, 2011
One example of having a backup plan is the literal one: keep backups. So… you deleted something? No problem, you don't have to reinvent the wheel. I write software for a living, we use something called source control which is another way of saying fancy backup. But if the computer that's on shits the bed? No problem, because all the data on that system is being backed up daily to a storage area network. But… one of the hard drives in your storage network just died! No problem, because all those drives are in a RAID configuration so you just have to swap in a new hard drive and you're done. Etc., etc., etc.
posted by Civil_Disobedient at 6:32 PM on March 1, 2011
This thread is closed to new comments.
When asked for information, make sure your answer is scoped appropriately - don't go into great detail about the mechanics of xyz if they only want the results - unless there's something specific about the background that explains awonky answer - even then, just summarize and let them indicate if they want details.
posted by canine epigram at 7:25 AM on February 28, 2011 [1 favorite]