HN user

malaporte

78 karma
Posts0
Comments31
View on HN
No posts found.

We started doing challenges like this in our hiring process some years ago. Our challenges are open-ended so the time spent on it really is up to the applicant, but you can come up with a good solution in a few hours.

The feedback from candidates (including those we didn't hire) has been extremely good - they much prefer this to puzzles or whiteboard coding sessions.

Note that we give such challenges to candidates after they passed through a phone screen and a first interview with a pair of engineers.

Bad Microsoft 12 years ago

Well, I wasn't thinking of specific skills for a given language/framework, but maybe more how those frameworks help you evolve along with the tech landscape.

I started my career around 15 years ago, working on a complex server system written in C++. The important skills back then were all about managing concurrency using mutexes, RW locks, events, and so forth.

Fast forward to now (with lots going on in between), and I find myself working again on server software, but this time the approach is much different: now for dealing with concurrency I'm relying on immutable state, and using Futures or actor systems to coordinate parallel work. It's been years since I've had problems with a deadlock.

Bottom line, it's true that a good programmer doesn't care about language or framework, since he can pick those up pretty fast anyway. But it's a skill that needs practising, and I've seen people neglect this and then regret it later.

Bad Microsoft 12 years ago

I don't think age as a numerical thing is the issue here. The problem is probably more related to people that stopped learning / being interested in new stuff when they landed a stable job. So they've been using the same skill base for a long time, and suddenly they realize they are obsolete.

Sure they may have grown their skills inside that particular silo, and that is worth something, but maybe outside the whole world has taken a different direction.

Never forget that the cool tech you're learning now will be out of fashion in a few years, and completely obsolete a few years more down the road (replace years by months for any JS framework out here :p).

Bad Microsoft 12 years ago

Hmm I'm not sure I agree with that. From my experience the period where family is most likely to be a problem with a demanding job is when kids are very young. The short nights, demanding daycare schedules, having to clean them, feed them, and provide a mostly continuous watch, etc. It's pretty gruesome. If I look around me this tend to happen around 28-30 years old.

Of course family remains #1 priority afterwards, but there is enough flexibility to go along with a demanding job (provided you like said job).

I've been working remotely for the larger part of may "young father years" so I guess this helped a lot, too.

I've been using a Pi running XBMC for about a year. It's connected to a big hard drive. I can copy stuff there from my laptop (movies, music, etc.) It works pretty well; I don't remember having to "service" it in any way since I plugged it in.

It works fine to stream stuff from YouTube, too. Shows for kids, etc. The XBMC remote on my phone is pretty handy too.

Overall, I'm pretty happy with it.

Seems pretty interesting. And official MS support for running the whole thing on Mono, right now, isn't that pretty big?

Funny how this post made me realize I've often been confronted with people wanting to implement 'agile' by imposing us to follow strict processes. I'd never seen it that way, even if the irony is pretty obvious.

In my experience, Typescript support in IntelliJ/Webstorm has always been sketchy --- so much that I find it quite unfair that they would mention this as a feature of the paying version.

I still use it, but I often get invalid highlighting, etc.. Then I update to the latest EAP because it's supposed to fix this particular issue... and then other appear. Hmm, annoying...

I tried the VS version as well, and there the highlighting and refactoring works very well... but the editor is waaaay slower so I always give up. Funny because it works fine when working with other languages such as C#.

Hmm technically you don't need an IDE to make good use of Typescript. It works very well as a standalone compiler installed using npm, and you get static type checking etc. which is really the point of Typescript IMHO --- if you don't care for static typing you might as well use JS directly.

Sure, once you've got this you might as well want good auto-completion, refactorings, etc, but this also applies to any language that's not bound to one specific IDE (C++, for example, or Java).

Lucene does have competition, mostly in the commercial world. I know, since I work for one of those companies :p

Solr, ElasticSearch, etc. are mostly concerned about the index/search features, and they do quite a good job there. But this still leaves a huge amount of space for commercial offerings, as core search is only a part of the problem. I'm thinking about connectivity with complex enterprise systems, support for the specific security models of those systems, integration in other systems, etc. Believe me, those problems are not easy to solve.

So, even if we have an index that can most probably match Lucene's feature for feature and quite a lot of things beside, we typically won't go after deals where simple search is the only requirement. Instead we focus on larger deals with more complex requirements. And we're doing quite well, thank you :)

Remote worker here, I agree with most things he said.

I work with an on-site team, and I'm the only remote worker in that group. We use a permanent Hangout that I can keep opened in the background, in order to hear what's going on at the office. With the press of a button I can 'upgrade' it to a full two way video chat. I'm using an old battered laptop sitting on a stand, along with a good quality microphone and a webcam I can pan remotely (pretty fun). Here's a picture: http://imgur.com/OD4V9Z4

When it's open it feels a lot like if I'm sitting there. I can take part of informal conversations, etc. It's pretty great... although it does sound creepy when I describe it.

Still my coworkers are totally OK with that, and honestly once you get used to it it's fine. I'd see and hear the same things if I was physically there. And since I'm in a different timezone, I still get to work all morning mostly uninterrupted.

Also, we have similar setups in a few conference rooms, so it's always extra easy go gather people for quick talks.

I'm curious to know if other people are using something similar.

I think they are. I'm a Canadian living in France, and I pretty much hate McDonalds here. Fries are soggy and not salted enough, burgers are completely messed up, and the service is impressively slow. I tried several places, it's all more of the same.

Everytime I go back to a McDonalds in Canada I find the food just tastes better. It's still fast food, but I'm enjoying it so much more.

Coveo, Quebec City, Canada

We're in the enterprise search business. That's Google for BigCorp. Our own search engine. It's hard, and it's fun.

We use many technologies. The top ones are C++, C#, Java, Scala, JavaScript, Python. We have many customers, and we're growing at a very fast pace.

People here are fun & talented. Nice colorful office, and frequent donuts. And Quebec is a very nice city.

http://careers.coveo.com/

A colleague of mine used to be some kind of manager/director at that company (in another country though). He once described his former job as "milking the government".

They hire the lowest quality engineers (e.g. the cheapest), and then bill them outlandish $/hour to work for government agencies. The project plans are packed with useless stuff, and are designed to exceed initial estimations. They get paid by the hour...

I wasn't speaking about the tech, especially the recent one which I find to be pretty nice (well, some of it at least). My point was about perception of MS tools in the larger tech community. At some point you get tired of fighting this fight, and in the context of a startup this can hurt you, or so I think.

Sure, I'd wish the tech community was less prone to those useless battles, Well, unless it's about bashing Java-the-language, of course :p

Another thing to keep in mind is the political aspect of choosing a tech stack, especially for a startup... As you'll surely notice right here in the comments, MS tools are not what you could call fashionable in many tech circles, and that could hamper a startup ability to raise money, or affect it's market value unless it's a smash hit like Stack Overflow.

It's up for debate whether the bad reputation is deserved by Microsoft in 2013 or not, but fairness is not what's important here...

For my part I once used C# in the past for a couple of projects and I have very fond memories of it. It's a well balanced language with very solid tooling, and the Mono stack seems nice as well. In a way, I'd be happy to use it again on a new project... but at the same time I must admit that being rid of the stigma of using MS tech is a pleasant feeling. And it's indeed expensive, although it has never been my job to worry about that.

In a way, for me, MS tools are like that old out-of-fashion shirt that you I still like to wear from time to time even though you know people will think it looks weird.

To my wife, if she reads this: Sorry, I'm not getting rid of the shirt.

Errr, it says Visual Studio will limit the path length for now. Windows already support longer path names, if you use the right APIs.

My understanding is that it's not worth going over all of their code to use the newer APIs since they also rely on third parties that they can't force to update. Those would still break when dealing with longer paths.

Still sucks (the path length limit is indeed problematic, especially when dealing with Java code), but let's not exagerate things shall we?

Maybe we should stop putting all older engineers in the same basket, and same thing goes for the younger ones.

I've known some older engineers (older than me, heh) make crap decisions because they didn't like change.

Then I've seen younger engineers completely mess up good, maintainable code because they think that knowing one language makes them masters of software development.

I try not to hire any of those two persons.

BUT, I've also seen young programmers completely fail because they couldn't adapt to a newer (or older...) technology.

And I know some very much older programmers who are constantly reading up about new stuff, and loving it.

Bottom line, look at who you're hiring, not only how old they are.

Maybe that was the outcome Nokia's board looked for from the start? I mean, they did choose Elop, and it was pretty clear where that would lead them. Nokia was on a downhill slope way before Elop came onboard.