Wanna be a developer? Your coworkers want to learn Go and like to watch, er, Friends and Big Bang Theory Google's Go programming language, all but disallowed by the web giant's own Fuchsia team for its excessive memory consumption, tops developers' to-do lists. That's according to a survey by tech talent platform HackerEarth. At the end of last week, the biz released data gathered from 16,000 programmers, more than 20 per cent of …
My team actually did have an interview question: "What's your favorite Seinfeld episode?"
We used it as an ice-breaker rather than to eliminate anyone, but we all agreed that the correct answer was either bemused indifference or "I don't watch Seinfeld."
Careful with that. I realise you mentioned your intention was "to break the ice".
But if you were to ask that question during an interview in Germany you would probably be told very firmly not to waste the interviewee's time with matters that are not related to the vacancy at hand.
SQL is a progamming language
In pure SQL you need to do all sorts of hacks and work arounds for anything more complex than a unit operation.
If you're chaining statements, you need PL/SQL, procedures or sessions with state so you're no longer in the realm of the standard and every DBMS manages it differently.
> SQL is a programming language.
I suppose it depends on your definition of programming language. SQL is not Turing complete so I would hesitate to call it a programming language. It is more a language that you use during programming. Originally it was intended that you would embed bits of SQL within your C program and pass the lot through a preprocessor that would convert the SQL into whatever instructions your database system required.
Its name also gives you a clue as to its intended use. And of course, if you are an adherent to C.J. Date's point of view on the matter you would argue that it is not even adequate as a relational query language.
SQL is not Turing complete
I thought more recent revisions of it were? Not that I'd like to try and write anything like that with it…
SQL within your C program and pass the lot through a preprocessor that would convert the SQL into whatever instructions your database system required.
Converting to relational algebra would have been good. Instead the various vendors retrofitted some of their dafter ideas in SQL making it even more unwieldy but also unavaoidable.
Maybe they're too exhausted to feel unhappy? I remember when I was doing those kind of hours (well, a bit more) and weekends (or just sundays) were mostly to sleep it off...
About that pony, I guess I still have some space on the balcony :)
Well, at least those happy workers working forever. However, I generally prefer a job that is not paid by the hour over one that is assuming that I know how much time I'll be putting into both. The reason is that those jobs I've had that are paid by the hour have always involved an annoying filling in of timesheets with pointless levels of detail about when I came in, when I went out, what I did for every five minute section of the day, etc. Filling those out involved a healthy amount of trying to remember what I was doing several hours and ten intensive debuggings ago, then putting in some generalities and going home. Meanwhile, non-hourly jobs frequently just care whether the job got done, and if I work weirder hours or do one long and one short day instead of two normal-length days, they don't care and I don't even have to tell them.
What would make me a happier programmer? That would be intricately tied to those who "manage" me.
1) You are allowed to tell me what you want me to write, just not how to write it. Micro managing is ugly and doesn't suit you
2) I expect you to organise/prioritise and schedule my workstreams as per business requirements. I shouldn't be expected to do that, that's your job. It's called managing.
3) I don't expect you to understand (i.e) 3rd normal form. I do however, expect you to be able think logically
4) dozens of other gripes but, I'm worn out telling you and I need a beer
I'm decades into a career with C#, Node, Python, Ruby, and PHP. So I have a good level of exposure and experience to do a comparison.
I've been doing Go in my own time for around 5 years now and love it.
That said, I took three months to do Go at a startup using microservices, queues, etcetera. Go excels at infrastructure, but the way the codebase worked everything at every level of the application felt like infrastructure. A vague statement, but it's difficult to explain further. Oh, and absent generics there was an awful lot of boilerplate duplication (they're incoming though, so things should improve).
I'd love to try Go again as a career choice, but I'd probably be a bit more cautious where.
This post has been deleted by its author
Go looks really nice in the Golang evangelist demos. When it came to writing complex apps, it felt like the worst limitations of C and Java combined. I can't think of any programming task where it would be my choice to use it. I'd group it down there with Perl and Objective-C.
I was asked the "favorite TV show" question, not in the interview, but via an email from someone at corporate for a blurb on new employees in an internal newsletter. I do watch TV, but can't say I have a favorite show. There were about a half-dozen similar questions that the colored pencil set would eat up but for those of us who have personalities that...well let's just say people assume I'm really good at blackjack...not so much fun for us.
I ignored the first request. A week later a Skype message popped up asking that I get my answers in, so I completed the basic bio stuff, figuring they'd just leave out the fluff. That was answered by an email asking to please fill out the whole thing "it's supposed to be fun!". As a subtle hint, my boss was CCed on the email. Boss wasn't overly concerned with my performance on answering newsletter questions, so I left it alone. Bio ran with blanks for those questions.
I suppose I could have gotten silly with the answers (fav TV show: the emergency broadcast test on the first Wed of the month) or been direct: "this is a stupid question and a waste of your time and mine". Or literal: "person, alive or dead, to have dinner with? Alive, cause eating dinner with a dead person would be creepy".
"The happiest developers turned out to be those working the longest hours. Some 70 per cent of those working less than 40 hours per week were unhappy and unhappiness declined with more demanding jobs. Fourteen per cent of workers putting in 40-50 hours reported unhappiness; thirteen percent of those working 50-60 hours were unhappy. And only three per cent of those working more than 60 hours a week were unhappy"
And you just *know* someone in HR is going to go "let's increase the amount of hours they need to work - that'll make them happy". No, you resource-counting morons, it's the other way around: they work longer hours because they are happy in their job.
I was quite surprised not to see C in the list. Sure, it's painful to write many types of programs in it. But surely people took courses in it at least? Maybe it's just that I took mostly systems courses, so nearly everything was at least partially taught in C, but someone's got to write operating systems, embedded code, drivers, programming language interpreters, ... Did the survey people just skip over all those people?
We once started a round of interviews by assuring candidates that we wouldn't ask them which vegetable they were. Which if course meant that they laughed and told us.
The really strange part was that three of them said "zucchini."
To this day I still ponder what on earth that was supposed to tell us.
One thing I did finally learn is that after a certain point your efficiency and attention to detail drop significantly. Anyone who thinks that there's a point to working fifty, sixty or seventy hour weeks is fooling themselves. That was summed up a long time ago when I was working trade-show set-up, and the Lead Hand stopped us at 1 am to say "It's late, and we're all really tired, and that means that we're all really stupid. Just slow down and think twice before doing anything."
Do you want to render the Mandelbrot set or solve Sudoku? Use SQL[ite]!
Yes, the examples are ‘outlandish’ and typical SQL usage looks a bit different. But shell is undeniably a programming language – even if most of the time we use it to run simple commands.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
