|
Cicero posted:Here's an actual question taken from a recent interview I did with a big-name software company: shuffle the list
|
# ¿ Dec 28, 2010 06:08 |
|
|
# ¿ Mar 29, 2024 13:44 |
|
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. 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. 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.
|
# ¿ Dec 30, 2010 21:29 |
|
I've seen people who don't know what they are doing being employed, but they normally have experience in working in another job.
|
# ¿ Dec 30, 2010 23:33 |
|
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
|
# ¿ Dec 30, 2010 23:35 |
|
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 tef fucked around with this message at 01:05 on Dec 31, 2010 |
# ¿ Dec 31, 2010 01:02 |
|
I've seen graduate jobs as low as £15k. 30k is a pretty good starting salary.
|
# ¿ Dec 31, 2010 07:40 |
|
Might be things like universal healthcare and different taxation
|
# ¿ Dec 31, 2010 08:19 |
|
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
|
# ¿ Jan 4, 2011 06:29 |
|
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
|
# ¿ Jan 6, 2011 06:10 |
|
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 |
# ¿ Jan 7, 2011 04:32 |
|
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.
|
# ¿ Jan 7, 2011 04:33 |
|
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.
|
# ¿ Jan 7, 2011 09:11 |
|
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)
|
# ¿ Jan 7, 2011 09:45 |
|
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 (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 |
# ¿ Apr 8, 2011 07:13 |
|
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
|
# ¿ Apr 10, 2011 03:23 |
|
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.
|
# ¿ Apr 10, 2011 03:26 |
|
I think your phone screening needs work
|
# ¿ May 11, 2011 06:14 |
|
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.
|
# ¿ May 17, 2011 17:03 |
|
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 What about the other suggestion, pairing in the interview ?
|
# ¿ May 18, 2011 00:55 |
|
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.
|
# ¿ May 18, 2011 00:56 |
|
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 |
# ¿ May 18, 2011 00:59 |
|
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 These things are not mutually exclusive. I'm sorry some people are good at their job and also get to experiment with things
|
# ¿ May 18, 2011 03:01 |
|
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.
|
# ¿ May 18, 2011 03:02 |
|
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".
|
# ¿ May 18, 2011 03:17 |
|
unless you're expected to do a whole slew of client facing work, a dress code is a sign you may be writing middleware.
|
# ¿ May 20, 2011 16:04 |
|
but csammis some people don't have time outside of their job to keep atop of current trends
|
# ¿ May 27, 2011 23:39 |
|
csammis posted:MY FREE TIME you can't ask for this some people are too entrapped within enterprise
|
# ¿ May 27, 2011 23:47 |
|
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
|
# ¿ Aug 22, 2011 08:15 |
|
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.
|
# ¿ Aug 22, 2011 10:37 |
|
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? 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'
|
# ¿ Aug 23, 2011 09:02 |
|
business logic is not really amenable to algorithmic analysis, it shouldn't be that surprising
|
# ¿ Aug 23, 2011 11:20 |
|
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 anyway, I think if we called ourselves software engineers we would have to take responsibility for when software fails
|
# ¿ Aug 24, 2011 02:36 |
|
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?
|
# ¿ Aug 24, 2011 02:55 |
|
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
|
# ¿ Sep 10, 2011 02:01 |
|
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. we seem to only change how we make mistakes rather than learning from them
|
# ¿ Sep 11, 2011 15:08 |
|
necrobobsledder posted:Only through maintaining other people's code can you learn from the mistakes of others and learn to never repeat their mistakes. 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 |
# ¿ Sep 12, 2011 01:09 |
|
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 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.
|
# ¿ Sep 12, 2011 11:44 |
|
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.
|
# ¿ Sep 13, 2011 11:43 |
|
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. 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.
|
# ¿ Sep 13, 2011 11:45 |
|
|
# ¿ Mar 29, 2024 13:44 |
|
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 |
# ¿ Sep 13, 2011 12:20 |