Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
tef
May 30, 2004

-> some l-system crap ->

Cicero posted:

Here's an actual question taken from a recent interview I did with a big-name software company:

shuffle the list :v:

Adbot
ADBOT LOVES YOU

tef
May 30, 2004

-> some l-system crap ->

Grey_Area posted:

I'm not sure how many people here are based in the UK, but hopefully a few (or at least greater than none) will have useful information.

:britain:

there are quite a few here (and fwiw, a surprising amount in edinburgh)

quote:

I'm nearing the end of a maths PhD and have very little programming experience - just a couple of simple pieces of coursework as an undergrad and an eight week summer job, again while I was an undergrad.

I'd ideally like to work on stuff with a fairly heavy theoretical component as well as pure coding, but mainly I'm looking for UK based employers who:

1. Accept grads for software development jobs who have very little programming experience.
2. Put serious effort into training and development for their grads.

So i'm looking to get started in an industry with very little relevant experience, work, or qualifications. Know anyone who is willing to train me and pay me for it?


quote:

I have good degrees, so I think I'd at least have a shot at competitive/high prestige jobs as long as they don't require previous experience.

It gets you an interview but not much further. Having a phd makes you overqualified for many jobs and many companies (in my experience) are hesitant to hire someone is too smart for the role. For some reason employers think Phds make people very employable, and subsequently you'll be seen as a flight risk.

A phd will only open doors for you, it won't land you a job by default, especially if they would have to train you for the role.

I think you're being naïve - the notion of a 'competitive/high prestige jobs as long as they don't require previous experience' feels like quite an oxymoron.

quote:

Any suggestions of companies to look at or things to do/read before I finish my PhD would be greatly appreciated. Thanks!

Get a portfolio together. Work out what sort of programming you want to do, and work on relevant examples. You won't get anywhere without a targeted approach.

I'd avoid systems and application programming and focus on more niche areas where your heavy maths experience would pay off or at least give you a head start.

For example:

high performance computing
numerical computation/simulation
trades/quant or financial stuff

Here, having some academic background or heavy pure math/analysis is a boon.

tef
May 30, 2004

-> some l-system crap ->
I've seen people who don't know what they are doing being employed, but they normally have experience in working in another job.

tef
May 30, 2004

-> some l-system crap ->

Grey_Area posted:

I got to the last round of interviews so at least had a reasonable shot at getting the job.

A reasonable shot would involve not failing interviews :eng101:

tef
May 30, 2004

-> some l-system crap ->
Luck and networking have frequently more to do with employment success.

I think your idealism is misplaced (you will have to learn more, or get paid less -- pick one) - although in the niches I mentioned above it isn't always the case, but they are few and far between by comparison.

And the example you cling to, actually demonstrates that you can't get these sorts of jobs because you don't have the technical knowledge to get past the interviews :v:

tef fucked around with this message at 01:05 on Dec 31, 2010

tef
May 30, 2004

-> some l-system crap ->
I've seen graduate jobs as low as £15k. 30k is a pretty good starting salary.

tef
May 30, 2004

-> some l-system crap ->
Might be things like universal healthcare and different taxation

tef
May 30, 2004

-> some l-system crap ->
Just going to say: Networking, networking, networking.

Most of the jobs i've got have been through knowing someone at the company, and it has helped opened a lot of doors. Go to local tech meetings and don't be a complete sperg.

Then again i'm a dropout :eng99:

tef
May 30, 2004

-> some l-system crap ->

Enderzero posted:

This is reasonable advice but it almost sounds like you are hiring people who can put up with all the other departments being full of jerks and idiots.

The real world is full of jerks and idiots.

quote:

If they are right, shouldn't you be focusing on the right things? How would placing an emphasis on getting things done help if you're doing the wrong things?

'worse is better' or 'perfect is the enemy of the good'

quote:

Why don't they need to work on their ability to communicate their needs or understand that you usually cannot meet all objectives?

Because they're hiring you. Also, if you think about it a little, if it has been asked of you, it would have been asked of others, some of whom may work at the company.


quote:

So to sum up: you're a glorified factory worker here for one task, please be passionate about the limited area we have slotted you into until we outsource the technical side because it's a commodity

I AM A SNOWFLAKE :qq:

tef
May 30, 2004

-> some l-system crap ->

Enderzero posted:

Exactly, so why the emphasis on keeping them out of the IT department. If IT workers can handle jerks and idiots, so can everyone else.

not sure where this comment came from beyond ignorance. there was no emphasis.

quote:

Either way the situation is too abstract to argue over it much.

nah it is called 'dealing with it', life is imperfect, stop sperging so much.

quote:

That's funny, because every single organization I have ever heard of is full of people who can't describe what they want and refuse to learn anything about other domains.

given how much you've jumped the gun here I am wondering how much of your experience is observational bias and how much you just bring upon yourself.


quote:

Corporate wants to have it both ways. They want you to be a predictable button presser, but they also want you to be creative and passionate. I can deal with not being special. But I'm not going to defend or cleave to contradictory expectations and I don't know why you would rather attack me than corporations on this point.


actually, I found your attack on unixbeard mostly lacking substance/knowledge.

to finish: 'real artists ship'

tef fucked around with this message at 04:34 on Jan 7, 2011

tef
May 30, 2004

-> some l-system crap ->

Spime Wrangler posted:

the interview should be as much about gauging whether or not the company is the right fit for you as it is convincing the company you're the right fit for it.

this is good advice.

tef
May 30, 2004

-> some l-system crap ->
For comparison:

I applied to my current job on the 11th of October. They got back to me the next day with a programming exercise (write a single threaded wget in python). I got back to them on the 17th with my example, and they arranged a technical interview over skype. We chatted on the 21st, it went well. They got back to me in a few hours and I had a second interview with the founders of the company (on the customer side).

They chased up my references, and I had an offer by the 27th, and had a final interview on the 19th of november to confirm everything. Starting in December.

I felt this went pretty fast-and could have possibly gone faster if I wanted an earlier start date. Overall I was impressed at the quick responses and fast turnaround.

(Additionally, I was signed off from my current job with burnout when the interviews happened, they knew about it and could sympathise with me. I'm on a six month probationary period as a result, but that's cool.)

It was one of the smoothest interview processes i've ever had, and unsurprisingly, this has been the most fun place i've worked at *by far and wide*.

Moral: If they waste your time at the interview you can be sure they will continue to do so more when they're paying you.

tef
May 30, 2004

-> some l-system crap ->

Cicero posted:

What sort of questions do you feel are good for figuring this out? I mean if you ask them, "How do you like working here?", the response basically always amounts to, "Oh it's awesome in seven different ways". How do you get a real feel for what the company is like?

Same way they get a feel for you. Ask questions and hope for the best.

It sounds vapid/trite but I've had some success by looking at what tools and programs they use. (My list of things I will never touch again - exchange; eclipse)

If I were mean, I'd ask them how many deadlines they hit recently, the state of the codebase, but I imagine you won't get very honest answers, or answers they think are true. If I were exceptionally mean i'd ask why the last guy left.

You might have more success with: How many people you'll be reporting too. How features get developed or planned. Average length of a development/release cycle. Longest day they've worked there? Most annoying bug they've had to fix in the codebase?

Really, I just see if I can get along with the people i'm interviewing with -- I aim for small companies, so often you meet every employee, if only for a moment, during the interview process.

If I put some effort into it I could write one of those 'what we say and what we mean things' (tongue firmly in cheek)

We're customer focused -> We make no long term plans at all
We're agile -> We're cowboys
We're a tdd shop -> We write boring software that is easy to test
We have a roadmap -> We have three priorities - needs doing yesterday, done right now, and on the roadmap. Guess which one we'll never get to.
We're results driven -> Look like you're working and do what I say and you'll go far
We like to get developer buy in -> We value your opinions. We value ours more.
We quality driven -> We'd like the most quality you can get by the ship date.
We're in a growing market -> We have no traction
Rockstars wanted -> Groupies for existing petulant developers sought.

(I am a bitter developer)

tef
May 30, 2004

-> some l-system crap ->
fwiw i'd seriously consider hiring someone who has got to programming late in life, it normally means you have to do less unlearning when you hire them :q:


(literally any fresh grad has to normally be repeatedly hit with a stick until they stop writing so much code)


and I would suggest working on open source projects to gain some valuable experience

tef fucked around with this message at 07:17 on Apr 8, 2011

tef
May 30, 2004

-> some l-system crap ->

kes posted:

can you elaborate?

in glibness:

you ain't gonna need it.


in reality:

everyone takes on the simple problems they get assigned and assume a sysiphean task. and they write multiple levels of abstraction.

just look at the 'classic' 'satire' evolution of a programmer, it is not far off

tef
May 30, 2004

-> some l-system crap ->
basically newbie programmers in a team take on trivial problems

and assume they are mountains to be conquered

an appropriate time to bring in design patterns

and some encapsulation

and abstraction


in reality


getting it done and reasonably maintainable is the goal

because the feature developed is worthless.





write code as if you're going to throw it away tomorrow.


by that I mean, don't write crappy code but code that is easy to replace.

tef
May 30, 2004

-> some l-system crap ->
I think your phone screening needs work

tef
May 30, 2004

-> some l-system crap ->

Ithaqua posted:

I've seen so many people fail to code FizzBuzz correctly that it almost makes me wonder if it's a valid test. What do you guys think?

Many people who apply for programming jobs are unable to program. Many, many people.
If you interview people and find out the basics are missing, it means your phone screening needs work.

I have heard of a simple interviewing process:

Ask them for their github/bitbucket repo, with example code in it.
If it looks ok, ask them to pair in the interview and write some code together.

tef
May 30, 2004

-> some l-system crap ->

csammis posted:

I could see this being a good gauge for college grads but not for developers with families and full-time jobs already under their belt. I put in eight hours at work, get my fill of fulfilling work, and then want nothing to do with the computer machine when I come home (save for some volunteer work for my wife's library).

Orzo posted:

This is a terrible idea because it filters out lots of really good developers. Why not just ask some basic programming questions on the phone? Works for us.

Things that filter out lots of good developers aren't necessarily that bad, if they filter out a significant chunk of bad developers. Really, If you've ever had to write a sample bit of code, you can stick it on github.

I *rarely* hack stuff on the side, but you can get one or two tiny hacks in the years you've been sitting infront of the computer. The last time I was asked to write some code for an interview, I put it on github. So can you.


Then again I guess if you're hiring people to write enterprise middleware, github isn't a good indicator. However i'm one of these people who ends up working in a startup, and people with more enthusiasm than sense tend to congregate in these jobs :v:


What about the other suggestion, pairing in the interview ?

tef
May 30, 2004

-> some l-system crap ->

csammis posted:

I put in eight hours at work, get my fill of fulfilling work, and then want nothing to do with the computer machine when I come home (save for some volunteer work for my wife's library).

that's a real shaim.

tef
May 30, 2004

-> some l-system crap ->

Orzo posted:

This is a terrible idea because it filters out lots of really good developers. Why not just ask some basic programming questions on the phone? Works for us.

to extrapolate on this, i'm not saying* don't hire people who don't have any code in public, but you should ask them for any repositories that *are* available. that and having some code online they can peruse will work in your advantage and allow you to stand out.

* infact I was copy-pasting some advice I had heard.


edit: I mean, no-one has time to work on side projects

at the end of the day I would rather hire someone who has done a neat hack over someone who hasn't made time to mess around with the computer.
I value people who take time to experiment with new technology and tools.

tef fucked around with this message at 01:01 on May 18, 2011

tef
May 30, 2004

-> some l-system crap ->

Orzo posted:

I'm sure they can write hacks and scripts and little programs that do neat things, but that's not what we want, and it's not what a lot of companies want. Then again, there are places that thrive on stuff like that, so yeah, different skill sets, different jobs.

And people say i'm an arrogant git on the forums :v: These things are not mutually exclusive. I'm sorry some people are good at their job and also get to experiment with things :3:

tef
May 30, 2004

-> some l-system crap ->

csammis posted:

ALL THAT SAID, spending four years hacking on shaim did wonders for my resume at the time. Whenever I interviewed the developers loved hearing that I worked on it for as long as I did. It was time well spent.

The moral people are missing here: Having code or a product people can play with does wonders for the interviewing process. Asking candidates for code or a product you can use gives you more insight than a phone screen alone.

tef
May 30, 2004

-> some l-system crap ->
I guess I was reading the mutually exclusive bit from where you said "we've interviewed a slew of people who have dabbled in this and that, [....] but when it comes down to it they can't actually write multiple classes that interact with each other".

tef
May 30, 2004

-> some l-system crap ->
unless you're expected to do a whole slew of client facing work, a dress code is a sign you may be writing middleware.

tef
May 30, 2004

-> some l-system crap ->
but csammis some people don't have time outside of their job to keep atop of current trends

tef
May 30, 2004

-> some l-system crap ->

csammis posted:

MY FREE TIME :qq:

you can't ask for this some people are too entrapped within enterprise

tef
May 30, 2004

-> some l-system crap ->
on engineering quicksort: http://pauillac.inria.fr/~maranget/X/421/09/bentley93engineering.pdf

i'd also like to mention dual-pivot quicksort here http://gdtoolbox.com/DualPivotQuicksort.pdf

tef
May 30, 2004

-> some l-system crap ->
the biggie is that generally quicksort is unstable and in place and that mergesort is stable and uses temporary memory

thing is i'd ask them what they are looking for - just start giving detail about what you know and if it is too much they will stop you.

tef
May 30, 2004

-> some l-system crap ->

iam posted:

Cheers for the feedback - on that basis, what sort of job titles would I be looking at for the former? And am I ever likely to get a job in IBM/Google/MS/'interesting' big corporate doing the more high-level stuff as I described? :ohdear:

goog tend to hammer people about algorithms in the hiring process.

if you want to avoid learning about algorithms, try applying for jobs of 'middleware developer' :q:

tef
May 30, 2004

-> some l-system crap ->
business logic is not really amenable to algorithmic analysis, it shouldn't be that surprising

tef
May 30, 2004

-> some l-system crap ->

Orzo posted:

Sources? This sounds like something you just made up.

It is ok; because even if they did have qualifications they would likely be worthless :v:


anyway, I think if we called ourselves software engineers we would have to take responsibility for when software fails

tef
May 30, 2004

-> some l-system crap ->

Dransparency posted:

Beyond that, I'm not yet sure I agree with your classification of CS as "not science." Pure computer science is most closely related to mathematics, which is frequently classified as a science (at least by the dictionary definition). Maybe you disagree with this assessment?

After reading what you linked to, yes I am inclined to disagree. In the same way *pure* mathematics is distinguished from *applied* mathematics, there is a distinction within cs.

*pure* computer science is *pure* mathematics, and more accurately a branch of philosophy; a discipline of thought. (i.e lambda calculus, type systems, proofs etc). Meanwhile science is more applicative; a rational method for evaluating your ideas and approach. (i.e analysis - evaluation, experiments, testing and hypothesis).



The thing is, the reason we have 'software engineering' and 'computer science' is nothing to do with that.

The reality is that the names came from how academia embraced computing. In some schools, computing came under the EE dept and so was named software engineering; in others computing came under the mathematics department and so was christened 'computer science'.

So the distinction between 'cs' and 'se' varies wildly between universities.




Really you have to look no further to understand the relative immaturity of computing as we have yet to establish a common vernacular - even words like 'strong typing' are continually redefined, so why would 'computer science' have a meaning?

tef
May 30, 2004

-> some l-system crap ->

kes posted:

or maybe they haven't spent enough time programming in a terminal to care one way or another? you can write code for unix with visual studio (and even compile it within the ide!), so i don't see any reason why you'd demand familiarity with a unix editor.

heee :3: :allears:

tef
May 30, 2004

-> some l-system crap ->

hieronymus posted:

Write understandable code. Use simple designs. It's always the clever, over-thought solutions to problems that lead to problems.

Readability suffers both from over and under abstraction. You tend to get the extremes a lot where people over engineer due to lack of knowledge or expert knowledge. I tend to find code written by beginners has excessive duplication of code, a complete lack of structure and piles and piles of if statements.

On the other end, code written by PHDs seems to have been tempered by working for four years on a project to demonstrate novelty within research. Everything is a class. Every feature is decomposed into an elegant and towering hierarchy. Use all the features!

It isn't as so simple as knowing enough to be dangerous. It's hard to get things just right, and programmers still seem to err on the side of 'too much abstraction'.

I think there was something said along the lines of 'some people have ten years experience of coding and some people have one year ten times'. Most of education is focused on churning out code and very little attention is paid to operational or maintenance requirements. We still have this pyramid building mentality of software - grand towering achievements to last forever. We focus on writing and constructing new code over learning how to maintain and make code more maintainable.

:smith:

we seem to only change how we make mistakes rather than learning from them

tef
May 30, 2004

-> some l-system crap ->

necrobobsledder posted:

Only through maintaining other people's code can you learn from the mistakes of others and learn to never repeat their mistakes.

:swoon: yes I am in total agreement here

edit: although when I wake up tomorrow I have a few points

tef fucked around with this message at 01:14 on Sep 12, 2011

tef
May 30, 2004

-> some l-system crap ->

necrobobsledder posted:

Business logic problems can oftentimes be handled most efficiently (even measured on a financial basis - the Law of business) via algorithmic analysis.

Very rarely for me. Most business logic I have encountered is simply dictating the model, rather than anything amenable to things like analysis or operations research.



quote:

That's gotten in the way of proving this for me for years has been rather simple - politics.

It's a social problem, quick! Let's write a technical solution.


quote:

On the other hand, I've certainly met some drat smart guys still in enterprise software. The other hypothesis I have is that the resulting software from these cultures is due to the chilling implications of the Milgram experiment.

When you build a project towards sales criteria instead of designing it, it is easier to sell. Once software had been adopted by the enterprise it is almost a guarantee that it will stagnate. People would rather use broken software they've learned how to use over trying software that works

quote:

Only through maintaining other people's code can you learn from the mistakes of others and learn to never repeat their mistakes. Coworkers have told me how easy my code is to understand and maintain, and that's enough for me to call myself a professional software engineer - you don't learn these practices through any means but pure hell experience. But through having to dumb down your code for years, you face the cruel reality that you are probably dumbing yourself down in the process.

There is often a misguided notion that we have to make newer programmers suffer as we did when we learned. It normally arises in the form of nostalgia - if only they learned on woefully inadequate machines then they'd understand todays computers more.

There is something to be said for exposing younger programmers to larger code bases, as well as more analysis and review of code -- but we shouldn't be inflicting our mistakes upon them in the hope that they learn from them. It isn't going to be as easy to teach them by putting them through hell.

I learned a lot from going through hell, but I don't think it is effective or the right way, but at the moment it seems like the only option available for getting programmers to understand maintainability.

tef
May 30, 2004

-> some l-system crap ->

Sab669 posted:

I've never done a phone interview before, though. Obviously every interview is different, but I was just hoping some goons might be able to offer some insight! I feel pretty confident right now, but I'm sure when my phone rings and it's a number I don't recognize my stomach will turn into a ball of knots.

Stay calm, ask questions when you get stumped. For an internship especially, they are looking for someone who can fit within the company and pick up the skills they need. Attitude counts for a lot more than experience in an internship.

tef
May 30, 2004

-> some l-system crap ->

necrobobsledder posted:

These problems are not solvable through technical means because the problems are constantly shifting, too - you're trying to code against a moving target. So the best you can do is determine where the target could land and make sure it can at least function then.

That consultant does not want to have to maintain that code he had little wiggle room for design, he wants it to work well enough, document it, and make sure it becomes someone else's problem.

I'll just summarize the state of enterprise software with a single image. If you think there's a technical means to change this state of idiocy, you're loving delusional.

As someone in a small company writing the product, I can happily testify to the brutal truths within your post. I have to focus on being able to change targets more than delivering on them.

Adbot
ADBOT LOVES YOU

tef
May 30, 2004

-> some l-system crap ->

lazarenth posted:

I just got my first actual job in software after graduation about 3 or 4 weeks ago. In the next couple of weeks I will be helping my manager interview for our first intern. I am cool with this, the only problem I have is I have no idea what to ask.

here is how an application with me normally proceeds:

code sample:

After we get an application, we ask the candidate to either provide a code sample or write one for us. We're looking for something that is fairly short to write and reasonably complete in less than an afternoon. Once we get the sample back, we look at it and decide if we want to move it forward to an interview.

note: you want to pick a code sample question relevant to your work if possible, and when in doubt asking them to implement simplified versions of command line tools can work too (wget, grep, curl, etc)

we tend to ask people to write a single threaded example and then expand on it within the interview to hear about the approach they'd take to making it multi-threaded.


interview:
if we do decide to interview, we usually have a long phone interview with one or two engineers. we introduce ourselves and give them a brief outline of the interview process, and then leap straight into the code sample.

interview - code sample:
we ask them to explain how it works and the design choices they made
we talk about features they omitted and how they might implement them, in particular we like to touch upon concurrency here. we ask about threading, locks, stm, actors and any other styles the candidate has familiarity with.

interview - experience:
we then move back to the resume, and work through the candidates experiences with tools and projects, asking harder and harder questions until the candidate is stumped or the interviewer is stumped. we're trying to measure the depth of expertise as well as the breadth.

for example:
c/c++ - start with stack vs heap, move onto things like volatile, virtual, raii, exceptions/destructors
also looking for experience with large frameworks (e.g. qt)

web development -- questions about cross site scripting and sql injections

java - asking about enums, generics, and ask them to explain any item in java.util.concurrent

python - asking about the gil, unicode

really you want to ask about known pain points, gotchas and other language warts to see how much they've used it in practice.

interview - domain knowledge:
for us, we use http and unix /heavily/ so we tend to focus on these areas in particular

for unix we get them to talk about command line tools they find useful, and ask them about how they would do some basic sundry commands

my favourite question to ask is: 'can you explain from start to finish how a web browser fetches a page on the internet' and ask them to go into as much depth as they are comfortable with. bonus points for knowledge of http bits like caching/redirects, as well as tcp and dns mechanics.

interview - frameworks/toolkits
we like to talk about the experience they have with larger and more established toolkits. this is where we focus on how much code the candidate has read, rather than written.

interview - company specific bits:
you'll excuse me for not sharing these bits as they aren't relevant, beyond this is where we explain the company in a little more detail, evaluate how well they've grasped our industry and talk about some of the bigger challenges that lie ahead.


i've tried to avoid giving you a question/answer sheet -- a lot of the questions I ask in the interview are based upon my own experience and knowledge and that isn't so easily transferred. most of the canned questions in interviews tend to fall into the style of the 'terrible lateral thinking puzzle' - ones in which there is a trick to answering and so I abhor them.

if I want to know if a candidate knows about hash tables I will just ask them directly

tef fucked around with this message at 12:23 on Sep 13, 2011

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply